Authentication
Every request to the Figur API is authenticated with a Bearer API key.
There are no cookies or sessions — each call carries the key in the
Authorization header.
Authorization: Bearer sk_live_...The key is advertised in the API reference as the sk_*
security scheme (type: http, scheme: bearer), so it applies uniformly to all
endpoints.
Key shapes
Section titled “Key shapes”| Prefix | Environment | Hits |
|---|---|---|
sk_live_* | Production | live tenant data |
sk_test_* | Test | the isolated test schema |
The prefix selects the data schema, so the same code path works against test or live data just by swapping the key. Keep keys server-side — they are secret credentials and must never ship in browser or mobile client bundles.
Capabilities
Section titled “Capabilities”A key carries one or more capabilities that gate what it can do on the unified job surface:
| Capability | Grants |
|---|---|
jobs:create | Dispatch any workflow (POST /v1/try-on, POST /v1/model-generator, …, all eleven peers) and upload assets via POST /v1/uploads. |
jobs:read | Read the job surface: GET /v1/jobs, GET /v1/jobs/{id}, GET /v1/jobs/{id}/events, the renders gallery (GET /v1/renders*), and the catalog / garment-category reads. |
A 403 is returned when a key lacks the capability a route requires; the body
uses the standard error envelope. These
engine-neutral names supersede the earlier ctm:create / ctm:read names,
which remain interchangeable at the gate during the transition.
Where keys come from
Section titled “Where keys come from”Keys are issued per tenant and provisioned out-of-band (today, seeded onto a tenant’s credential by the platform’s CLI; plan-driven self-serve issuance is on the roadmap). Treat a key as the tenant’s identity: it scopes every read and write to that tenant’s data and bills credits to that tenant’s balance. See Errors and credits for how credits are charged and refunded.