A recovery finished and its changes stand; when it can be undone, the window is open from now.
When this fires
When the recovery's changes are in place: the creator signs in with the new account, the project's bot answers under the new token, the resource points at its replacement and re-admission has been queued. For a channel recovery this fires once, when the first swap completes; later swaps absorbed into the same operation fire recovery.resource_replaced only.
Caveats
- Completion means the changes stand, not that every member is back in. Read the roll call at the roll call endpoint for that.
- The creator also receives the recovery report by email a few minutes later, once the first re-admissions have landed.
Related events
- recovery.operation_reverted: the creator undid it inside the window.
- recovery.resource_failed_over, recovery.resource_replaced, recovery.identity_relinked: what the recovery did.
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.