Skip to main content
Protocol integration design. The current sandbox issues test authorization tokens only. Production enforcement, the name index and revocation feed described below are not available through the Talent API sandbox. Start with the runnable quickstart and sandbox support matrix.
Platforms that call your inference API send an authorization token with every request for a named talent. The token is Reflections’ signed allow for exactly that use: which talent, which license revision, which model, how many generations and until when. Verify it before your model runs. Verification is local: a signature check against a cached key set and a few comparisons, with no call to Reflections on the request path.

Where the token comes from

The platform runs a check, receives allow with authorization.token, and passes the token to you with the job. Document where your API accepts it, such as a talent_authorization field or header. Require it whenever a request names a protected talent: customers can mark those requests, and with a Reflections account you can also match prompts against the signed name index and require a token on a match. Authorization token lists every claim.

Map each customer to a Reflections account

A token names its platform in aud, so you need to know which Reflections account each of your customers is. Ask each customer for its account ID when it sets up access; it reads it from GET /v1/account. Accept a token only when aud is the account of the customer making the request. A token issued to a different platform then fails, even if it was copied from a valid request.

Verify before you run

Reject the request when any of these fails: A job that returns four images uses four generations. Reserve them before the job starts, with an atomic increment in a store shared by every instance of your API, and keep the counter until 60 seconds after exp.
When you reject, return an error in your API’s own format that names the failed check: expired, wrong audience, model mismatch, count reached or invalid signature. The platform’s fix is the same in every case: run a new check. Never substitute another model for the one the token names.

Caching

Cache the key set, not decisions.
  • Cache the JWKS for its Cache-Control max-age. When a token names a kid you do not have, refetch at most once per max-age, so forged kid values cannot make you fetch on every request. A new live key is published 30 days before it signs anything, retired keys stay published, and a kid is never reused. Sandbox rfl-test- keys can rotate without that notice.
  • If the refetch fails or the kid is still unknown, reject. A token you cannot verify is not an allow.
  • Never cache a deny as an allow. A missing token, a rejected token or a failed key fetch is never stored as a pass for a later request, and an earlier valid token from the same customer says nothing about the next one.
  • A verified token is good only for itself, until its exp, within its count.
Because verification needs no network call once the JWKS is cached, a Reflections outage does not stop you from verifying tokens already issued. It does stop new tokens, and a request for a named talent without one is rejected.

Test tokens

Tokens issued in test mode are signed with test keys, whose kid starts with rfl-test-, such as rfl-test-2026-10-docs3. Accept them only in your own test environment for integration tests, and reject them in production. The conformance plan describes proposed cases; no hosted suite is available.

Session tokens

Realtime models receive a session token instead: typ tlp-session+jwt, the same iss, aud and sub, a jti that is the session ID, and an exp 5 minutes after issue. The platform renews it every 60 seconds and sends you the new one. Verify each token the same way, without the count, check that tlp.session is the session you are running, and stop generating speech for the session when its current token expires without a replacement. See Session token.

Copies you hold

When a talent’s voice, adapter or persona exists on your service, its facet lists you in provider_bindings, with your external_id and kind (voice, adapter or persona). Bindings are shown to you and to licensees with material access. When a talent withdraws the facet or revokes a license, the platform that created the copy is told to delete it and asks you to. Delete it, and give the platform the deletion time; it reports it to Reflections in the revocation acknowledgement. If you hold a Reflections account, subscribe to facet.updated to see binding changes.

What can go wrong

Tokens

Token formats and verification rules in the Standard.

Agent builders

The same verification inside an agent’s tool.

Security

Key handling, token verification and webhook signing.

Discovery

The discovery document and the JWKS.