Skip to main content
Planned protocol reference. The current Talent API sandbox does not register webhook endpoints or deliver events. Use polling and the test escalation helper for supported sandbox transitions. Start with the runnable quickstart and sandbox support matrix.
The planned webhook service sends an event to your endpoints when something happens that you must act on: an escalation is decided, a held output is released, a license is revoked. Events are signed with the Standard Webhooks scheme, so any library that implements it can verify them.

Create an endpoint

Endpoints created with a test key receive only test events, and endpoints created with a live key only live events.

The event

Each delivery is a POST with one event as its JSON body:

Verify the signature

Every delivery carries three headers: The signature is HMAC-SHA256 over <webhook-id>.<webhook-timestamp>.<body>, keyed with your secret: the base64 part after whsec_, decoded to bytes. To verify a delivery:
  1. Reject it if webhook-timestamp is more than 5 minutes from your clock.
  2. Compute the HMAC over the raw body, exactly as received. Do not parse and re-serialize it first.
  3. Accept it if any v1 entry in webhook-signature matches, using a constant-time comparison.
To rotate a secret, call POST /v1/webhook_endpoints/{endpoint_id}/rotate_secret. For 24 hours, deliveries carry signatures from both the old and the new secret, so the function above accepts either while you deploy the new one.

Respond and retry

Return any 2xx status within 10 seconds. Anything else, including a timeout or a redirect, is a failure and the delivery is retried. Respond first and do the work afterwards, from a queue. Delivery is at least once: the same event can arrive more than once. Record each webhook-id you process and ignore repeats. An endpoint that fails every delivery for 5 days is disabled. Reflections sends webhook_endpoint.disabled to your other endpoints and an email to your account’s address. Fix the endpoint, re-enable it with POST /v1/webhook_endpoints/{endpoint_id} and "status": "enabled", then replay what you missed.

Ordering

Events can arrive in any order. Each event’s sequence increases by one with each event about the same object. Keep the highest sequence you processed for each object ID, and ignore an event whose sequence is lower. To act on an object’s current state rather than the state in the event, retrieve the object.

Replay missed events

Events are kept for 30 days. To catch up after an outage, read the events list with after set to the last event you processed; events come oldest first. Filter with type, such as type=revocation.*.
To deliver one event again, call POST /v1/events/{event_id}/resend, with endpoint to send it to one endpoint only. A resent event has the same id, so your duplicate check still applies.
A missed revocation.created still binds you. If your endpoint was down, read the revocation feed as well as the events list before you generate again.

Connected-account events

A platform that acts for licensees needs their events: a revocation of Ridgeline’s license affects the checks Northlight runs for Ridgeline. Create the endpoint with connected: true. Events about a connected licensee’s objects then carry the licensee’s ID in account. Events about your own objects carry account: null.

Talent-side events

A representative receives events about the talents it represents, as their mandates allow: escalation.created with review_outputs, license_request.created with issue_licenses, and the license.*, revocation.* and statement.* events of those talents’ licenses. These events carry account: null. The talent is data.object.talent, or data.object.targets.talent on a revocation. See Talent representatives.

Event types

Handle escalations

check.resolved, generation.released and polling.

Handle revocations

The feed, purges, provider copies and acknowledgements.

Security

Key handling, token verification and webhook signing.

Sandbox

Current operations and supported test transitions.