Disaster Recovery Tools

Answer "can I still run a recovery, or do I need support?". Self-service recovery is allowed once per kind (account, bot, resources) inside a rolling window; beyond that, support reviews the account and may release a grant. Each row carries what the window still allows (self_service_remaining), what support has released and not yet spent (grant_remaining), their sum (remaining), whether a recovery of that kind would be allowed right now (allowed), whether the next one would spend a grant (uses_grant), when the kind was last recovered and when the self-service allowance returns. meta carries the window itself. The rows are the ones GET /v1/recovery/allowances returns.

Answer "how ready is this account for the next ban?". The checklist is the one the Disaster Recovery → Readiness page shows. The account's own lines come first: a second factor and a backup sign-in account. Then each installed connector's lines, worded by that connector and named by connector (Telegram's: a standby bot for every project, a standby for every channel and group, automatic failover, a live mirror). Last the two reminders: a copy of the content kept elsewhere, and a second human administrator in every space. Each line says whether it is in place, whether the plan lacks the feature (locked), the state in words and where the fix lives; the totals say how many verifiable lines are done. The payload is exactly what GET /v1/recovery/readiness returns.

After a channel or group is swapped, every active member is re-admitted through a fresh link, and this is the live tally: how many the swap set out to re-admit (total), how many hold a new link (regranted), how many could not be given one (failed), how many the installation could not message (unreachable) and were told by email instead (emailed), how many have joined (joined), who is still outside (pending), how many reminders went out (nudged), whether the queue has handled everyone (settled), and whether the creator may remind the stragglers right now (can_nudge, with nudge_available_at while the cooldown runs). The payload is exactly what GET /v1/recovery/operations/{operation}/roll-call returns.

A recovery of a kind that re-admits nobody (an account relink, a bot replacement) answers the same shape with every counter at zero.

The switches the Prevention page holds per project. auto_failover_enabled says whether the platform may swap a banned channel for its standby on its own, and auto_failover_email_consented_at when the creator accepted the per-email fee that failover may charge; email_delivery says how members are told after a channel swap the creator ran (self: the creator tells them; platform: Subscriby emails them at the fee); standby_installation_registered whether a spare bot is kept. The payload is exactly what the REST endpoint returns. The REST twin is GET /v1/projects/{project}/recovery/settings.

A standby is a spare channel or group the bot already administers, linked to one resource so a ban can be answered by a swap. This reads it: health_status (with the connector's health_reason code when degraded), mirror_enabled, health_checked_at, last_mirrored_at, linked_at. The standby's own identifier on the platform is deliberately absent. The REST twin is GET /v1/projects/{project}/resources/{resource}/standby.

Answer "is anything of mine banned or broken right now?". An incident is one problem a probe detected and has not yet seen fixed: the creator's sign-in account unreachable (account), a project's installation refused by the platform (bot), or a space the project sells gone or no longer administered (resources). Each row names the connector, the project and resource, the reason as the connector's code and in words, when it was detected and, once healed or fixed, when and by which operation it was resolved. The rows are the ones GET /v1/recovery/incidents returns.

Answer "what has recovery done for me, and can I still undo it?". An operation is one recovery ever run: by the creator, by the platform on their behalf (automatic, the failover you sleep through) or on demand (on_demand, a Swap & Grant of a healthy resource). Each row carries its kind, its state, the connector and project, when it started and finished, the failure reason when it failed, and its undo state: revertible for whether it can be undone right now and revert_window_ends_at for when that closes. The rows are the ones GET /v1/recovery/operations returns.

After a bot replacement, members who only ever talked to the old bot need the new one's link. This emails every member the project can reach by email with the new bot and the portal, at the per-email fee added to the creator's transaction fees, and remembers that it did: a second call answers with the count already sent and sends nothing. It spends money and reaches real people, so confirm with the creator first.

This tool is annotated destructive: a client that supports the annotation asks a human before running it. The REST twin is POST /v1/recovery/operations/{operation}/notify-members.

After a swap, get_recovery_roll_call shows who is still outside (pending) and whether a reminder may go out (can_nudge). This sends it: one message per straggler with a fresh link, recorded on the operation so the cooldown can be enforced. Every reminder reaches a real person, so do not loop it. The REST twin is POST /v1/recovery/operations/{operation}/nudge.

The standby row is forgotten and mirroring into it stops. Automatic failover can no longer swap this resource until a new standby is linked. Only the project owner may do this; a resource with no standby succeeds with nothing to remove.

This tool is annotated destructive: a client that supports the annotation asks a human before running it. The REST twin is DELETE /v1/projects/{project}/resources/{resource}/standby.

The standby is forgotten and withdrawn from the connector; the live installation, members and access stay as they are, and the next bot replacement will need a fresh credential pasted on the dashboard. Registering a standby is not offered to tokens because it takes a credential; removing one is. Only the project owner may do this.

This tool is annotated destructive: a client that supports the annotation asks a human before running it. The REST twin is DELETE /v1/projects/{project}/recovery/standby-installation.

Replacing a chat is a conversation with the creator on the connector: the bot messages them with a picker, and when they choose the resource is re-pointed, old links revoked, every active member re-admitted and a recovery operation recorded. For a degraded resource the swap spends the channel recovery allowance (or joins the recovery already absorbing swaps); for a healthy one it is on demand and free. Take an unanswered request back with withdraw_resource_replacement_request. The REST twin is POST /v1/projects/{project}/resources/{resource}/replacement/request.

Linking a standby is a conversation with the creator on the connector: the bot messages them with a picker, and the standby is linked the moment they choose. The API cannot name the chat directly (that would take a platform identifier), so it starts the conversation. Needs the Growth plan and the project owner. Take an unanswered request back with withdraw_resource_standby_request. The REST twin is POST /v1/projects/{project}/resources/{resource}/standby/request.

A channel recovery is undone one swap at a time: name the resource_id to put back on its old chat, and every active member is re-admitted there again. An account relink is undone whole, moving sign-in back to the previous account, signing the creator out everywhere and opening a disputed-relink incident for support; name no resource_id. A bot replacement cannot be undone. The window is 24 hours from completion by default; revertible on the operation says whether it is still open. Only the creator who ran the recovery may undo it.

This tool is annotated destructive: a client that supports the annotation asks a human before running it. The REST twin is POST /v1/recovery/operations/{operation}/revert.

When on, every post made in the channel is copied into the standby as it is made. Only a channel can be mirrored (a group cannot), the resource must keep a standby, switching on needs the Growth plan, and only the project owner may do it. Returns the standby as it now stands. The REST twin is PATCH /v1/projects/{project}/resources/{resource}/standby.

Drives the two actions the Prevention page drives, so a refusal is the same sentence the dashboard shows. Switching auto_failover on needs accepts_email_fee: true in the same call, because a failover may email the members the bot cannot reach at a per-email fee the creator must agree to, and it needs the Growth plan. email_delivery is self or platform. Only the project owner may change these; a teammate is refused. Returns the settings as they now stand. The REST twin is PATCH /v1/projects/{project}/recovery/settings.

The one-click swap from the Prevention page. The resource points at the standby chat, the old invite links are revoked and every active member is re-admitted into the standby; the standby is consumed. A recovery operation records it: for a healthy resource with no open incident the swap is on demand and spends no allowance, otherwise it spends (or joins) the channel recovery allowance. Undo is offered for 24 hours through revert_recovery_operation. Only the project owner may do this.

This tool is annotated destructive: a client that supports the annotation asks a human before running it. The REST twin is POST /v1/projects/{project}/resources/{resource}/standby/use.

A creator holds one replacement request at a time, whichever resource it was for, so there is nothing to name: the picker the bot sent stops waiting for an answer. When none is open the call changes nothing and still succeeds. Only the account holder may do this. The REST twin is DELETE /v1/projects/{project}/resources/{resource}/replacement/request.

A creator holds one standby request at a time, whichever resource it was for, so there is nothing to name: the picker the bot sent stops waiting for an answer. When none is open the call changes nothing and still succeeds. Only the account holder may do this. The REST twin is DELETE /v1/projects/{project}/resources/{resource}/standby/request.