For developers

Build with the StyleProfile API

Two ways in. The widget is the fast one: a script tag and a mount point, or an app install on Shopify. The API is the flexible one: request a render, get an image and a size recommendation back, and put them wherever you like.

Sandbox access includes the versioned API reference

A calm desk with an open laptop showing an abstract interface of pale panels and thin blue lines, a notebook, a pen and a folded cream shirt beside it. — Two ways in, one engine behind both.

Two integration paths

Pick the one that matches your constraint

They are not tiers. The widget and the API run against the same engine — the difference is who owns the interface the shopper sees.

Path one

The no-code widget

A script tag and a mount point on your product template. On Shopify it is an app install and a theme block, so nobody has to touch code at all.

Choose this when

A standard storefront where try-on belongs on the product page.
You want it live this week rather than this quarter.
Your team would rather not own another integration.

Shopify integration

Path two

The REST API

Direct calls to the render engine, with the output wherever you want it. You own the interface; we return the image and the size recommendation.

Choose this when

Try-on has to live somewhere the widget cannot reach — a native app, a styling tool, a seller console.
You need renders inside your own pipeline rather than in a browser.
You are a platform offering try-on to your own merchants.

How rendering works

The widget

How the widget embeds

One script and one mount point. The script is loaded asynchronously and renders into the element you mark, so it never blocks your product page.

On Shopify you do not write this by hand — the app adds a theme block you position in the editor. The snippet is what that block resolves to.

<script async src="https://cdn.styleprofile.io/widget.js" data-store="your-store-id"></script>

<!-- Mount point, anywhere in your product template -->
<div data-styleprofile-tryon data-product="PRODUCT_ID"></div>

Representative embed — your store id ships with onboarding.

One engine

The widget is the API with a UI on top

There is no cut-down engine behind the no-code route. Both paths hit the same renderer and get the same image back.

The API

What the API covers

Four capabilities, described in plain terms. The exact parameters live in the versioned reference rather than on a marketing page, because that is the document we keep accurate.

Catalogue sync

Push products, images, variants and size data — or let us pull them. A product is renderable once it has a category and one usable image.

Render requests

A shopper reference plus the garment ids you want composed. You get back a hosted render and the ids it was built from.

Size recommendation

A recommended size for a shopper and a garment, with or without a render. Sharper when you supply per-garment measurements.

Webhooks

Render completion, sync results and failures — pushed, not polled. Every event carries the references you sent.

One request, one response

A render request names a shopper reference and the garments to compose. The response is a hosted image plus the size recommendation for the pieces it could size.

POST /v1/renders
Authorization: Bearer sp_live_xxxxxxxxxxxx
Content-Type: application/json

{
  "shopper_ref": "sess_8f2c41",
  "garments": ["sku_top_114", "sku_trouser_207", "sku_shoe_063"],
  "body": { "model": "preset_b", "size_hint": "M" }
}

200 OK

{
  "id": "rnd_9c31a7",
  "status": "ready",
  "render_url": "https://cdn.styleprofile.io/r/9c31a7.webp",
  "garments": ["sku_top_114", "sku_trouser_207", "sku_shoe_063"],
  "size_recommendation": { "sku_top_114": "M", "sku_trouser_207": "M" }
}

Illustrative shape — the versioned reference ships with sandbox access.

Authentication and keys

Keys are issued in the dashboard, one pair per environment, so a sandbox experiment never spends live volume. Server keys are secrets and belong on your server; the widget authenticates with a public store id instead, which is why the embed snippet can sit in a theme file without exposing anything. Rotate a key whenever you need to — old and new stay valid together for a short overlap so nothing drops mid-deploy.

Sandbox

Request sandbox access

Sandbox keys come with the versioned API reference and a sample catalogue, so you can make a real render request before you commit to anything.

Tell us roughly what you are building and we will send back keys, the reference and a direct contact rather than a support queue.

Or book a walkthrough instead

FAQ

What developers ask first

Not yet. The versioned reference — endpoints, request and response schemas, error codes — goes out with your sandbox invite. We would rather send you the real document than publish a partial one that is wrong within a month.

They are published alongside the reference rather than guessed at here. The engine is built for product-detail-page traffic, so sustained throughput and burst behaviour are the numbers we hold ourselves to. If you have a specific peak in mind, put it in the sandbox request and we will confirm it before you build.

A JavaScript snippet today. Server-side SDKs are on the roadmap. Until they land the API is plain REST over HTTPS with JSON bodies, which is a few lines in any language and no dependency to keep current.

Next step

See the whole look on your own catalogue

See the rendered output before you write any code — run the live demo, or bring us three of your own products.

Try it live Get a demo

Cancel anytime · No long-term contract · Live on your store in minutes