The creator marked a manual perk as handed over; the grant is issued.
When this fires
The creator (or a teammate, an integration or an agent on their behalf) marks a creator task done: on the members page, through the complete endpoint or the MCP tool complete_creator_task. The access ledger row moves from pending to granted, this event says who did it, and member.resource_added follows for the same grant_id with mode creator_task.
Caveats
- Completing a task is not idempotent over the API: a second call for a completed task answers 422 VALIDATION_FAILED.
- The member is not messaged by a bot on completion; tell them yourself, or let the portal show the perk as delivered.
Related events
- creator_task.opened: the task being done.
- member.resource_added: raised for the same grant on completion.
Headers
t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.
The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Payload
Response
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
Changes
Webhooks have no change history: a webhook is keyed by its event name rather than a path and method, so no recorded change can name it.