> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reflections.ai/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> The OpenAPI document at /api-reference/openapi.yaml defines the target contract. Its x-reflections-availability field and each operation's availability notice identify supported test and live forms. Do not infer implementation from a schema or code sample. Live keys support account details, reads of the licenses the calling account holds as licensee or issued as talent (GET /v1/licenses?role=issuer), and GET /v1/generations?license=… for the state of outputs under such a license (summaries only: no prompt, reference, bytes or metadata). Live image checks, submissions and receipts are built but not activated: until activation, a live POST /v1/checks or /v1/generations returns 403 live_not_activated, which must not be retried. Discovery and JWKS are at the origin root (https://app.reflections.ai/.well-known/...), not under /v1.
> Three rules hold everywhere: a decision is never an error (deny and escalate are 200 responses, and a live check still evaluating is a 202 with status checking); generate nothing for a named talent without an allow; deliver nothing until the generation is allow.
> The sandbox accepts personal rk_test_ keys. Persist a separate Idempotency-Key and body for each logical /v1 POST; retry an unknown outcome with the same key and body. OAuth and Talent API MCP remain planned.

# Sandbox

> The supported test API, fictional talent and inputs that force each decision.

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](/api-reference/introduction#test-and-live-mode). The source also
supports an [initial live image implementation](/api-reference/introduction#initial-live-image-implementation)
when configured; its deployment and signing activation are not established by this sandbox journey.

Start with the [working quickstart](/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.

| Available in test mode | Limits |
| - | - |
| Account, talent, facets, licenses and revisions | Fictional fixtures only; no material download or name index |
| Create, list, retrieve and cancel checks | Text and fixture decisions; no real identity or media evaluation |
| Create, list, retrieve and withdraw generations | Inline bytes or SHA-256 attestation; no file IDs or URL fetching |
| Retrieve receipts | Public JSON at `https://app.reflections.ai/v1/receipts/{receipt_id}` |
| Verify receipts | JSON receipt ID, receipt JWS or SHA-256; a test receipt needs a test key, and any other key returns `not_found` |
| Resolve an escalation with a test helper | Your checks and held generations; unrestricted test key required |
| Read the revocation feed | Always empty; revocation lifecycle is not implemented |
| Discovery and JWKS | Supported endpoints and public verification keys; a published live key alone does not enable signing |

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](/api-reference/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`.

| Talent | ID | License | What happens |
| - | - | - | - |
| Maya Okafor | `tal_9t0wxyhk5zba2q8v1m3n7p4r6s` | `lic_97bb8qgh1b9zk81anbjkmprxh4`; voice platform license `lic_fmva0q8p2ymbhdy60snaphp4gt` | Your account holds a license for images, video and speech, social and web, US and CA. Outputs are allowed after checks. Her voice also has a fixture platform license for personal use; sessions are not implemented. |
| Jonah Reyes | `tal_4n6p8r0t2v4x6z8b0d2f4h6j8k` | `lic_31x87g772xdcz1n1za29601rbt` | Your account holds a license that requires the talent to release each output. Generations return `escalate` and stay `held`. |
| Iris Calder | `tal_7q9s1v3w5y7a9c1e3g5h7k9m1n` | None | Posture `license_required`, and you hold no license. Checks return `deny` with `no_license` and a `license_request` remedy. |
| Dev Marlow | `tal_2b4d6f8h0j2k4m6n8p0q2r4s6t` | None | Posture `prohibited` for every commercial use. Checks return `deny` with `talent_prohibits` and no remedy. |

Their facets, licenses and revisions are real test objects. Read them with
[`GET /v1/talent/{talent_id}`](/api-reference/talent/retrieve-a-talent) and
[`GET /v1/licenses`](/api-reference/licenses/list-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.

| String | Where | Result |
| - | - | - |
| `rfl_test_escalate` | Check | `escalate`, `escalation.reason: judgment` |
| `rfl_test_unverifiable` | Check | `escalate`, `escalation.reason: unverifiable` |
| `rfl_test_unavailable` | Check | `escalate` with `evaluation_unavailable` |
| `rfl_test_rule_violated` | Generation | `deny` with `prohibited_custom_term` |
| `rfl_test_identity_changed` | Generation | `deny` with `identity_not_preserved` |
| `rfl_test_unchecked` | Generation | `allow`, with the talent's rule in `unchecked_terms` |
| `rfl_test_async` | Generation | `status: checking`; retrieve the generation after 10 seconds to settle it |

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:

```bash theme={null}
export ESCALATION_ID="esc_…"
export RESOLUTION_KEY="$(node -e 'console.log(require("node:crypto").randomUUID())')"
```

```bash theme={null}
curl -sS --fail-with-body "${REFLECTIONS_ORIGIN:-https://app.reflections.ai}/v1/test_helpers/escalations/$ESCALATION_ID/resolve" \
  -H "Authorization: Bearer $REFLECTIONS_KEY" \
  -H "Reflections-Version: 2026-10-15" \
  -H "Idempotency-Key: $RESOLUTION_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "decision": "allow", "note": "Approved in the sandbox." }'
```

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](/production/conformance) describes the remaining launch work and
target acceptance cases. Create a live key in the [dashboard](https://app.reflections.ai/developers/keys)
to read your account and the licenses it holds or issued. 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](/production/conformance#initial-live-image-implementation)
separates those gates from source support.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.