recovery.* events
The Disaster Recovery ledger as it moves: incidents opening and resolving, recoveries starting, finishing, failing and being undone, standbys kept and consumed, channels swapped and accounts relinked.
The Disaster Recovery ledger as it moves: incidents opening and resolving, recoveries starting, finishing, failing and being undone, standbys kept and consumed, channels swapped and accounts relinked.
Disaster Recovery watches a creator's sign-in account, every project's bot and every channel or group a project sells, and swaps in what it can when a ban lands. Everything it detects and everything it does is a row in the recovery ledger, and every row change is announced here. The events name Subscriby ids and the connector key only; a platform's own identifiers never travel in a webhook.
Every recovery.* event requires project-recovery:view on the subscribing token. Events about a project carry that project's project_id; events about the creator's own account (an account incident, an account relink) carry project_id: null and are delivered to the endpoints of the team the creator owns.
Background
Example payload
{
"id": "evt_01HX...",
"type": "recovery.resource_failed_over",
"created_at": "2026-09-12T03:19:42Z",
"api_version": "2026-05-01",
"project_id": "7f3d1c92-8b45-4e6a-9d21-5c8e0a4b6f13",
"data": {
"operation_id": "9a4d2e71-5b38-4c6f-8e12-3d7c9b0a5f21",
"project_id": "7f3d1c92-8b45-4e6a-9d21-5c8e0a4b6f13",
"resource_id": "b73c5f21-9d80-4a6e-8215-4f70ce13a9d6",
"resource_title": "Lounge",
"connector": "telegram",
"replaced_at": "2026-09-12T03:19:41Z"
}
}Required ability
Tokens subscribing to recovery.* events must carry project-recovery:view.
Events
recovery.incident_openedA health probe found the creator's sign-in account unreachable, a project's bot refused by the platform, or a channel or group gone or no longer administered.recovery.incident_resolvedAn open incident closed: a later probe found the thing healthy again, or a recovery replaced it.recovery.operation_startedA recovery began: run by the creator, by the platform on their behalf, or on demand for a healthy resource.recovery.operation_completedA recovery finished and its changes stand; when it can be undone, the window is open from now.recovery.operation_failedA recovery failed before changing anything; the allowance it spent is given back.recovery.operation_revertedThe creator undid a recovery inside its window: a swapped channel put back, or the previous sign-in account restored.recovery.standby_registeredA spare bot is kept ready for a project, or a spare channel or group is kept ready for one resource.recovery.standby_removedA standby is no longer kept: the creator removed it, registered another in its place, or a recovery consumed it.recovery.installation_failed_overAutomatic failover switched a project onto its standby bot without the creator, because the platform refused the live one: the bot-side twin of `recovery.resource_failed_over`.recovery.resource_failed_overAutomatic failover swapped a banned channel or group for its standby without the creator: the failover you sleep through.recovery.resource_replacedThe creator pointed a resource at a replacement channel or group: in a recovery after a ban, or on demand for a healthy resource.recovery.identity_relinkedThe creator's sign-in account moved to another account on the connector: a newly detected one, or the backup switched in.recovery.readiness_changedA line of the Disaster Recovery readiness checklist changed state, and here is the whole checklist as it stands now.recovery.incident_opened
WEBHOOKA health probe found the creator's sign-in account unreachable, a project's bot refused by the platform, or a channel or group gone or no longer administered.
When this fires
The hourly probes check every bot, every channel and group a project sells, and the creator's own sign-in account. When one comes back banned, deleted, or stripped of the rights the bot needs, an incident opens in the recovery ledger and this event fires, once. A probe that finds the same broken thing on its next run reopens nothing and fires nothing; the incident stays open until it resolves. Undoing an account relink also opens an account incident (reason: relink_disputed) so support reviews the dispute.
Caveats
- One event per incident. The ledger opens one incident per subject and keeps it open, so a subject that stays broken for a week fires this once, not hourly.
- A restriction the platform reports as "still reachable" opens nothing: only a verdict that warrants a replacement counts. See How detection works.
Related events
recovery.incident_resolved: the same incident healing or being fixed.project.resource.status_changed: the health verdict that precedes a resources incident.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
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
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
recovery.incident_resolved
WEBHOOKAn open incident closed: a later probe found the thing healthy again, or a recovery replaced it.
When this fires
An incident resolves in one of two ways: a later probe finds the account, bot or channel healthy again (the creator gave the bot its rights back, the platform lifted a restriction), or a recovery replaced the broken thing, in which case resolved_by_operation_id names it. Either way the incident row is marked resolved and this event fires once.
Caveats
- A bot relink resolves every open bot incident the project had, whichever bot row each named: expect one event per incident.
- Resolution says the ledger no longer sees a problem; it does not say members have been re-admitted. Follow
recovery.operation_completedand the roll call for that.
Related events
recovery.incident_opened: how the incident began.recovery.operation_completed: the recoveryresolved_by_operation_idnames.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
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
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
recovery.operation_started
WEBHOOKA recovery began: run by the creator, by the platform on their behalf, or on demand for a healthy resource.
When this fires
The moment a recovery is opened in the ledger: an account relink or a switch to the backup account, a bot replacement, or a channel swap. The row exists from this moment because it is the quota ledger too: the allowance is spent here, and given back only if the recovery fails before changing anything.
A channel recovery absorbs every swap made inside its grace period into one operation, so a second channel swapped an hour after the first fires no second start; it fires recovery.resource_replaced under the same operation_id.
Caveats
- Once per operation. Swaps absorbed into a running channel recovery fire no second start.
- A recovery refused before the ledger row is written (quota spent, not the owner, plan lacks the feature) fires nothing.
Related events
recovery.operation_completed,recovery.operation_failed: how it ends.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
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
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
recovery.operation_completed
WEBHOOKA 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.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
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
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
recovery.operation_failed
WEBHOOKA recovery failed before changing anything; the allowance it spent is given back.
When this fires
The recovery was opened in the ledger and then could not be carried out: the connector refused the new bot's credentials, the replacement chat could not be bound, the new account could not be linked. Nothing changed, so the operation is marked failed and its use of the rolling allowance is given back. The creator sees the refusal on the page that ran it; this event tells your systems.
Caveats
- A swap that fails while a channel recovery is already absorbing swaps leaves that recovery standing: failing it would erase a swap that did happen. Only a recovery that failed on its first swap fires this.
Related events
recovery.operation_started: how it began.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
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
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
recovery.operation_reverted
WEBHOOKThe creator undid a recovery inside its window: a swapped channel put back, or the previous sign-in account restored.
When this fires
Inside the undo window the creator can put a swapped resource back onto its old chat, or move their sign-in back to the previous account. A channel recovery is undone one swap at a time, so this fires once per resource put back, with resource_id; the operation itself is marked reverted when its last standing swap is undone. An account relink is undone whole, in one event with resource_id: null, and opens an account incident (relink_disputed) so support reviews it.
Caveats
- Undoing a swap re-admits every active member into the old chat again; expect a second round of
member.resource_*events for the same members. - The undo window is 24 hours from completion by default; an attempt after it is refused and fires nothing.
Related events
recovery.operation_completed: the recovery being undone.recovery.incident_opened: the disputed-relink incident an account undo opens.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
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
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
recovery.standby_registered
WEBHOOKA spare bot is kept ready for a project, or a spare channel or group is kept ready for one resource.
When this fires
Active Disaster Prevention keeps two kinds of standby: a standby bot per project (a second token, stored without a webhook and probed like any bot) and a standby chat per resource (a spare channel or group the bot already administers, optionally mirrored). Registering either fires this event. Registering a new standby bot where one already existed also fires recovery.standby_removed with reason: replaced for the old one.
Caveats
- The standby's own identifiers on the platform (the bot's token, the chat's id) are never in the payload.
- Turning the mirror on or off later fires nothing; read the standby's state from the Prevention page.
Related events
recovery.standby_removed: the standby removed, replaced or used.recovery.resource_failed_over: the standby chat doing its job.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
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
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
recovery.standby_removed
WEBHOOKA standby is no longer kept: the creator removed it, registered another in its place, or a recovery consumed it.
When this fires
A standby bot or standby chat leaves the reserve. reason says why: removed when the creator took it away, replaced when a new standby bot took the slot, used when a recovery consumed it (a bot relink from the standby, a one-click Swap & Grant onto the standby chat, or an automatic failover).
Caveats
- A standby consumed by a recovery fires this beside the recovery's own events (
recovery.resource_failed_overorrecovery.resource_replaced, or the bot recovery'srecovery.operation_completed); usereason: usedto tell it from a deliberate removal. - The readiness checklist counts standbys, so a
removedorusedstandby lowers the score until a new one is registered.
Related events
recovery.standby_registered: the standby being kept.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
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
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
Automatic failover switched a project onto its standby bot without the creator, because the platform refused the live one: the bot-side twin of `recovery.resource_failed_over`.
When this fires
A probe finds the platform refusing a project's live installation outright (the token revoked or regenerated, the bot deleted), the project has Automatic Failover switched on, a standby bot is registered and its last probe found it healthy, and the Project Bot allowance permits: the platform writes the standby's credentials into the project's installation, resolves the incident, closes the connector outage as replaced, and emails every member reachable by email their new link on the creator's behalf, at the per-email fee accepted when the switch was armed. This event fires the moment the switch completes; it sits under a recovery whose recovery.operation_started carries automatic: true, and the Project Bot allowance is spent exactly as by a manual relink.
The switch cannot be undone from the dashboard: the refused bot is gone as far as the platform is concerned. The standby slot is empty afterwards, so the creator is asked to register a new standby bot.
Caveats
- Fires only for a platform-caused refusal. A rate limit or a passing API error marks the installation degraded but never triggers a failover.
- When a condition fails (plan lapsed, no healthy standby, allowance spent, or the switch refused), nothing fires here; the creator receives Automatic failover did not run for 's bot by email and on their connected account, and the incident stays open.
Related events
recovery.resource_failed_over: the channel-side twin.recovery.operation_started/recovery.operation_completed: the recovery around the switch.connector.outage_closed: the outage this switch ends asreplaced.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
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
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
Automatic failover swapped a banned channel or group for its standby without the creator: the failover you sleep through.
When this fires
A probe finds a channel gone or the bot removed from it, the project has Automatic Failover switched on, a healthy standby is linked, and the allowance permits: the platform points the resource at its standby, revokes the old links and queues every active member's re-admission, all without the creator. This event fires the moment the resource points at the standby; it sits under a recovery whose recovery.operation_started carries automatic: true.
Members the bot cannot reach. A failover emails the members the bot can no longer message, at a per-email fee the creator accepted when switching failover on. The roll call's
emailedcounter says how many.
Caveats
- The standby that was consumed fires
recovery.standby_removedwithreason: usedbeside this event. project.resource.updatedalso fires for the same resource withchanges.space_id, as it does for any swap.
Related events
recovery.resource_replaced: the same swap made by the creator.recovery.operation_reverted: the creator put the old chat back.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
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
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
recovery.resource_replaced
WEBHOOKThe creator pointed a resource at a replacement channel or group: in a recovery after a ban, or on demand for a healthy resource.
When this fires
The creator swaps a resource onto another chat: a replacement channel after a ban, the standby in one click, or a healthy resource moved to a new supergroup on demand (Swap & Grant, which spends no allowance). The resource is re-pointed, the old links revoked and every active member's re-admission queued. One event per resource swapped, each under the operation_id of the recovery absorbing it.
Caveats
- A swap onto the standby chat also fires
recovery.standby_removedwithreason: used. project.resource.updatedfires for the same resource withchanges.space_id, as it does for any swap.
Related events
recovery.resource_failed_over: the same swap made by the platform.recovery.operation_reverted: the swap put back inside the window.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
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
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
recovery.identity_relinked
WEBHOOKThe creator's sign-in account moved to another account on the connector: a newly detected one, or the backup switched in.
When this fires
After a ban on the creator's own account, recovery moves their Subscriby identity to another account on the connector: one they prove control of through a handshake, or the backup account they registered ahead of time (from_backup: true). Sign-in and alerts follow the new account at once; the previous one becomes the backup when a backup was switched in. This is an account-level event: project_id is null and it reaches the endpoints of the team the creator owns.
Caveats
- The platform's own account identifiers (numeric ids, usernames) are deliberately absent;
identity_idis the neutral id the rest of the API uses. - Every browser session of the creator is signed out by the relink. The undo, inside 24 hours, fires
recovery.operation_revertedand opens arelink_disputedincident.
Related events
recovery.operation_completed: the same recovery, as an operation.recovery.operation_reverted: the relink undone.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
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
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
recovery.readiness_changed
WEBHOOKA line of the Disaster Recovery readiness checklist changed state, and here is the whole checklist as it stands now.
When this fires
The readiness checklist is what a creator has in place before anything happens: a second factor on the account, a backup sign-in account, and, per connector, the standbys, mirrors and automatic failover the platform can verify. Subscriby records the checklist's state after every event that could move a line (a standby registered or removed, a resource failed over or replaced, an account relinked, a connector installed, connected, disconnected or uninstalled) and once a night for the things that fire no event (a second factor, a passkey, a plan change). When the state differs from the last one recorded, this event fires with the checklist as it stands. Recording the same state twice fires nothing. Readiness is the creator's, not one project's, so the envelope project_id is null.
Caveats
- The first checklist ever recorded for a creator fires nothing: there is no earlier state to differ from.
- Reminders (a copy of the content elsewhere, a second human administrator) never appear here; they cannot be verified.
- The labels, descriptions and fix links of each line are not in the payload; read them from the readiness endpoint.
Related events
recovery.standby_registered: one of the changes that leads here.recovery.standby_removed: another.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
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
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
Related
How is this guide?