Skip to main content
The sandbox serves a limited part of the Talent API contract. It never involves real talent or paid model calls. Use your own rk_test_ key. Objects carry livemode: false; signed test receipts are not evidence of consent from a real person. Recorded live production acceptance covers your account and license reads. The source also supports an initial live image implementation when configured; its deployment and signing activation are not established by this sandbox journey. Start with the working quickstart: check → inline PNG → generation → receipt → JSON verification. The API reference marks every operation Test mode available or Planned contract. An operation’s description names unsupported input forms even when its endpoint is served.

Availability

The current implementation serves 21 /v1 operations and two discovery routes, out of 83 operations in the reference. The remaining 60 are planned contract definitions, not callable sandbox operations. There is one OpenAPI document; each operation carries x-reflections-availability for tools that need this distinction. Files, licensed material, license requests/drafts/mandates, connections, sessions/streams, usage/settlement, webhook delivery/events, revocation changes, Talent API OAuth and Talent API MCP are planned. No hosted conformance runner is available. The broader integration guides describe that target contract; they do not claim those services are deployed. A check naming an unknown real person can return allow with talent: []. That is not clearance: this sandbox recognizes only its fictional fixtures.

Request and verification limits

  • Generation inline media: 7 MiB (7,340,032 decoded bytes), with matching SHA-256 and media type.
  • Entire generation request: 10 MiB (10,485,760 bytes), including base64 and JSON overhead.
  • Other JSON requests: 1 MiB (1,048,576 bytes).
  • Stored test objects: at most 2,000 new objects or 16 MiB per account per 24 hours; a logical check or generation can create several objects. Individual stored objects are capped at 256 KiB. These are storage limits, separate from transient inline media.
  • Verification: JSON only. Multipart files, C2PA manifests, remote URLs and fingerprints are refused.
  • Async generations settle when retrieved after their delay; poll no faster than once every five seconds.
  • Rate limits are per account per server process, not a shared fleet quota; see rate limits.
Test signing uses a unique rfl-test- key ID and retains earlier public keys after rotation. The first sandbox launch and immediate rotations do not establish the Standard’s 30-day key prepublication requirement. This sandbox is not a claim of full TLP implementation conformance.

Sandbox talent

Every test account holds these fixtures. Use their names in prompts or their IDs in talent. Their facets, licenses and revisions are real test objects. Read them with GET /v1/talent/{talent_id} and GET /v1/licenses.

Inputs that force an outcome

Put one of these strings anywhere in a text input of a check, or in the transcript of a generation. They work only in test mode. A check with on_escalate: "deny" turns any forced escalation into deny with review_required, in the sandbox.

Resolve an escalation

Use the actual escalation.id from your check or held generation. An unrestricted test key can allow, deny or expire it. Keep the resolution key for retries of this same decision:
The response is the resolved check or generation. Retrieve it and require decision: "allow" before continuing. The sandbox sends no webhook. Signing, accepting and revoking licenses through test helpers, talent-side mandates and dashboard data reset are not implemented.

Production status

The production conformance page describes the remaining launch work and target acceptance cases. Create a live key in the dashboard to read your account and the licenses it holds as licensee. Completing this sandbox journey does not enable live checks, output submission or receipts. The implemented live image path requires newly signed consent, protected signing activation, qualified retention and supplier processing, and independent live acceptance. The live qualification section separates those gates from source support.