A purchase entitles a subscriber to a manual perk, so the creator has something to do by hand.
When this fires
A subscription becomes active (or a pass window opens) on a plan that includes a manual resource: a perk no connector can give, which the creator hands over themselves. The access ledger records a creator_task grant in state pending and opens a task naming the member and the perk; this event carries that task. One event per manual resource the purchase entitles the member to. Nothing is sent to the member by a bot for a manual perk; the portal shows the perk as arranged by the organiser.
Caveats
- A task is opened once per purchase, resource and window; a retry of the granting job does not open a second one.
- A purchase that ends before the task is done revokes the grant; the task then drops out of the open list without a creator_task.completed.
Related events
- creator_task.completed: the task is done and the grant issued.
- member.resource_added: raised for the same grant_id 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.