project.resource.status_changed
A channel or group enters or exits a degraded state: banned, deleted, or the bot lost its rights.
When this fires
A channel or group linked to a project transitions into or out of a degraded state. The degraded reasons are:
reason | What the platform told us | Recovery |
|---|---|---|
chat_not_found | The chat no longer exists: deleted, or banned by the platform. | Replace the chat (a channel recovery). |
bot_removed | Our bot was removed from the chat, so it can no longer admit or remove members. | Re-add the bot as an administrator, or replace the chat. |
bot_not_administrator | The bot is still in the chat but lost its administrator role. | Promote it again with the invite and restrict rights. |
bot_missing_rights | The bot is an administrator without the invite users or restrict members right. | Grant both rights again. |
connector_api_error | The platform refused the probe for a reason we could not classify. | Re-check; replace the chat if it persists. |
The healthy event carries reason: null and fires when a probe finds the resource answering again, or when a recovery re-points it at a new chat.
A chat_not_found or bot_removed transition also opens a recovery incident on the creator's Disaster Recovery page, alerts them by email and on their connected account, and, on Growth, with automatic failover switched on, swaps the resource for its standby without anyone signed in.
It does not fire when:
- A probe finds the same state as last time. Only transitions are announced.
- A probe cannot reach the platform at all. A transport failure keeps the previous state.
- The resource is a manual perk. Only channels and groups are probed.
Fires on a transition, not on a schedule. Subscriby probes every linked channel and group hourly, every five minutes while a pass window is open or imminent, and immediately when real work fails (an invite link cannot be minted, a join request cannot be approved). You get one event when the resource breaks and one when it recovers, never an event per probe.
Related events
connector.status_changed: the same idea for the project's installation.project.resource.updated: fires withchanges.space_idwhen a recovery re-points the resource at a replacement place.
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.
How is this guide?
Last updated on