Planned protocol reference. The revocation feed, webhook delivery, acknowledgements and
license lifecycle mutations below are not served by the current Talent API sandbox.
Start with the runnable quickstart and sandbox support matrix.
What a revocation contains
scope says what
narrowed:
At
effective_at, Reflections has already denied pending checks with license_revoked, denied held
outputs with license_revoked (each one sends
generation.denied, and can never be released), and
terminated live sessions. affected counts what it cut.
Authorizations already issued expire within 15 minutes and session tokens within 5. Do not use
them in the meantime: stop_generation covers them.
Receive the webhook
revocation.created is the fast path, sent within 5
seconds (p95) of effective_at. Verify its signature, record its ID, queue the work and return a
2xx within 10 seconds. Do the work outside the request.
Deliveries are signed with the Standard Webhooks scheme: an
HMAC-SHA256, keyed with your endpoint secret (the base64 after whsec_), over
webhook-id.webhook-timestamp.body. Each v1,<base64> entry in webhook-signature is a
candidate; more than one appears while a secret rotates.
seen, markSeen and queue stand for your own storage. Webhooks arrive at least once and in no
guaranteed order: deduplicate on the event id (equal to webhook-id), and ignore an event whose
sequence is lower than one you already processed for the same object. Any Standard Webhooks
library verifies these signatures too.
Read the feed
The webhook is the fast path. The feed,GET /v1/revocations,
is the source of truth. If you cache decisions, read it at least every 60 seconds, and on every
revocation.created. Pass after with the last revocation ID you finished to read everything
since, oldest first.
status=pending_acknowledgement and status=overdue with cursor and apply each one; an overdue
revocation still needs its actions and acknowledgement. Then store that ID as your cursor. From
then on, read with after, which lists oldest first. Store the cursor durably, and advance it only
after a revocation is fully applied.
Apply the required actions
Do every action inrequired_actions for everything under targets:
post_revocation.policy says what happens to outputs you already released:
Withdraw a released output you took down with
POST /v1/generations/{generation_id}/withdraw,
so its record shows it is no longer in use.
Acknowledge
Attest what you did withPOST /v1/revocations/{revocation_id}/acknowledgements,
in one call or two:
- By
acknowledge_by, 24 hours aftereffective_at, acknowledge every action inrequired_actionsexceptwithdraw_outputs, and every provider copy you deleted. Do not wait for withdrawals to finish before you send it. - If
required_actionsincludeswithdraw_outputs, acknowledge it in a later call, once the outputs are down, bypost_revocation.withdraw_by.
Idempotency-Key, because its body differs, and adds an entry to
acknowledgements. The revocation stays pending_acknowledgement until every required action is
acknowledged, then becomes acknowledged. Acknowledgements are shown on the talent’s record.
If either deadline passes first, acknowledge_by for the first call or withdraw_by for
withdraw_outputs, the revocation becomes overdue, you receive
revocation.overdue, and it is shown as overdue on the
talent’s record and to your account contact.
What can go wrong
Planned test coverage
The proposed license-revocation helper would exercise revocation, suspension, resumption and withdrawal. That helper, its events and stream messages are not served by the current sandbox. Test your handler with local fixtures until these operations are listed as available in the sandbox.Related
Revocation
What revocation stops, what it leaves, and how fast.
Webhooks
Signing, retries, ordering and replay.
Caching and outages
What you may cache, and for how long.
Revocation in the Standard
The deadlines a conformant platform meets.