> ## 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.

# Changelog

> Dated API versions, protocol versions and notable changes.

This page separates the deployed test sandbox from the broader protocol contract. Endpoint
availability is recorded in the [API reference](/api-reference/introduction).

<Update label="2026-10-19" description="Live keys and live image source" tags={["API", "Sandbox"]}>
  * **Live:** live keys read the account and the licenses it holds as licensee.
  * **Published:** the live verification key is in the [JWKS](/api-reference/formats/discovery). A
    published key does not mean live signing is active.
  * **Built, not activated:** live image checks, output submission and signed receipts. Until
    activation, a live `POST /v1/checks` or `POST /v1/generations` returns `403`
    [`live_not_activated`](/api-reference/errors#live_not_activated), which must not be retried.
    Before this change, the same state returned a retryable `503`.
  * An unmatched path now names the cause in `detail`: an ID that is not valid for the path, or a
    `/.well-known/` route requested under `/v1`.
  * **Talent reads:** a live key reads the licenses its account issued as talent with
    `GET /v1/licenses?role=issuer`, and `GET /v1/licenses/{license_id}` returns them.
    `GET /v1/generations?license=…` lists the outputs submitted under a license the account holds
    or issued, as `generation_summary` objects: status, decision, receipt and release status, with
    no prompt, reference, bytes or metadata. `release_status=awaiting_release` lists only the
    finals waiting for the talent's release. In test mode, `role=issuer` returns an empty list.
  * **Checks:** a live check still evaluating returns `202` with `status: "checking"`,
    `decision: null` and `Retry-After`, where it returned `409 idempotency_key_in_use`. A retrieve
    returns the same `checking` object.
  * **C2PA binding:** `POST /v1/generations` accepts `c2pa_signer`, the SHA-256 thumbprint of the
    certificate that will sign the output's C2PA claim, and the receipt signs it as
    `tlp.c2pa_signer`. A verifier that checks the manifest can reject the assertion in a manifest
    another certificate signed ([TLP-RCP-16](/standard/receipts#binding-to-a-c2pa-claim-signer)). Receipts without it are
    unbound. Manifest verification remains planned.
  * **Scope:** `revocations:read` reads the [revocation feed](/api-reference/revocations/list-revocations).
    `revocations:write` still covers it.
</Update>

<Update label="2026-10-17" description="Test sandbox" tags={["Sandbox"]}>
  Checks, inline generations, signed receipts, JSON receipt verification, fixture catalog and
  escalation resolution are implemented in test mode. There are no paid model calls or real talent.
  [Run the quickstart](/quickstart) and read the [supported forms](/sandbox).
</Update>

<Update label="2026-10-15" description="API version 2026-10-15" tags={["API", "Standard"]}>
  ## API version 2026-10-15

  The target contract for API version `2026-10-15`. The list below is the protocol scope,
  **not a list of deployed capabilities**. Planned endpoints are labeled in the reference.

  * Checks, generations and sessions with the `allow`, `deny` and `escalate` decisions.
  * Typed obligations, signed authorization tokens and signed receipts.
  * The `ai.reflections.license` C2PA assertion, and verification by receipt, manifest, digest,
    fingerprint or watermark.
  * Licenses, signed revisions with `terms_digest`, license requests and connections.
  * Revocations with acknowledgements, and the revocation feed.
  * Usage records, statements and payment records.
  * The talent side for representatives: mandates, the escalation queue, license drafts signed
    by a person on a hosted page, suspension, revocation, and confirming or disputing statements.
  * 33 webhook event types, signed with the Standard Webhooks scheme.
  * The session stream over WebSocket.
  * The MCP server for agents.
  * Test mode with sandbox talent and test helpers.

  ## Talent License Protocol 1.0

  The [Standard](/standard/overview) tab publishes version 1.0 of the protocol: roles,
  decision semantics, token and receipt formats, the obligations registry, revocation deadlines,
  discovery, and mappings to RSL 1.0, the Human Consent Standard, C2PA and ODRL.
</Update>


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