> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Suspend, reactivate, and recover a subaccount

> Pause a subaccount safely, restore service, understand deletion, and verify billing, queues, keys, and inbound handling through the lifecycle.

# Suspend, reactivate, and recover a subaccount

Suspend a subaccount when you need to stop its traffic without deleting its tenant data. This guide covers the dashboard action and the equivalent API calls, including what stays in place while the subaccount is suspended.

Before you begin, open **Settings → Subaccounts** in the parent organization. Only the parent organization's **owner** or **admin** can manage a child. For the organization model and visibility rules, see [The subaccount organization model](/concepts/subaccount-organization-model).

## What happens when you click Suspend

Open the child subaccount's action menu, choose **Suspend**, and read the confirmation before continuing. The dashboard displays this warning:

> All scheduled and in-flight sends will be paused. API keys belonging to this subaccount will return 403 until you reactivate.

After you confirm, Orbit changes the child to `suspended` and pauses its operational traffic:

* **Scheduled sends pause.** Work waiting for its scheduled time remains held rather than being sent.
* **In-flight sends pause.** Active outbound work is stopped by the subaccount's suspended state. Do not assume a message or call completed just because it was accepted before the suspension.
* **All API keys return `403`.** This includes keys that already existed; creating or retrying a request with a key does not bypass the suspension.
* **Webhooks stop delivering.** Outbound webhook delivery for the suspended organization is held while the organization cannot process traffic. Review the delivery backlog after reactivation.
* **Inbound traffic handling is paused.** Inbound messages and other channel traffic are not handed to the suspended child while the suspension is active. Verify the affected number and webhook state before announcing that service has resumed.

The action is recorded against the parent organization. Suspending a child does not suspend the parent or its sibling subaccounts.

You can also suspend through the API:

```bash theme={null}
curl -X POST https://orbit.devotel.io/api/v1/subaccounts/sub_abc123/suspend \
  -H "X-API-Key: dv_live_sk_your_parent_key"
```

The response identifies the child and returns `status: "suspended"`. See [White-label subaccounts](/guides/subaccounts-reseller) for the API lifecycle and the complete [Subaccounts API](/api-reference/subaccounts).

## What Suspend does not do

Suspension is not deletion and does not reset the child. While the child is suspended:

* **No data is deleted.** The subaccount's configuration, API keys, contacts, messages, campaigns, numbers, and audit history remain associated with it.
* **Configuration is retained.** Branding, domains, pricing, connection settings, webhook configuration, and limits remain ready for the next active period.
* **Standing billing continues.** Suspension does not cancel the subscription or erase standing charges. Review the applicable plan and rate model before suspending for a contract or payment issue.
* **Credits do not move.** The child's credit balance stays where it is. A suspension does not transfer credits back to the parent.
* **Contacts and message rows persist.** Existing records remain available to authorized parent operators and are not re-created when the child is reactivated.

To remove a child, use **Delete** only after confirming that the customer no longer needs its data or numbers. Deletion is a separate destructive operation; it is not a longer form of suspension.

## Role gating

The subaccounts console gates lifecycle actions to the parent organization's **owner** and **admin** roles. A developer or member cannot operate a child from the console: the action is hidden or disabled for that role, and direct API calls are rejected by the same authorization boundary.

The owner/admin restriction applies to both dashboard actions and lifecycle API calls. It does not grant a subaccount administrator access to sibling children or to the parent organization.

## Reactivate a suspended subaccount

When a child is suspended, its action menu replaces **Suspend** with **Reactivate**. Confirm the child's billing state and the reason for the suspension first, then select **Reactivate**.

```bash theme={null}
curl -X POST https://orbit.devotel.io/api/v1/subaccounts/sub_abc123/reactivate \
  -H "X-API-Key: dv_live_sk_your_parent_key"
```

Reactivation changes the child back to `active` and reverses the suspension gate:

* Its API keys can authenticate again and should stop returning `403`.
* Held scheduled and in-flight queue items can resume sending.
* Webhook delivery and inbound handling can resume for the child.
* The child keeps the same data, keys, configuration, contacts, messages, credits, and billing state it had before suspension.

Reactivation does not guarantee that every item in a backlog is delivered. Queue ordering, expiry, deduplication, provider responses, and the original scheduled time still apply. Treat the held work as a backlog to inspect, not as a promise of replay.

### Verify service after reactivation

1. Confirm the console shows **Active**.
2. Send a harmless authenticated request with a child API key and confirm it returns `200`, not `403`.
3. Inspect the scheduled-send queue and delivery logs. Confirm that eligible paused work resumes and that expired or failed items are handled according to their normal retry policy.
4. Check webhook delivery attempts and the child endpoint's response codes before increasing traffic.
5. Test one inbound message or other representative inbound event and verify that it reaches the child's configured handler.
6. Review the child's usage and billing view for the reactivation period.

If reactivation succeeds but requests still return `403`, refresh the child list, wait for the status to show `active`, and retry with a key issued to the child rather than the parent. If the problem persists, check the API response error and the audit log.

## Pending setup and recovery

A child created by the wizard with `pending_setup: true` is different from a suspended child. It stays in **Pending setup** until the wizard's final **Launch** step completes. It cannot serve traffic yet.

For a pending child, the list and detail page provide two recovery actions:

* **Resume setup** reopens the wizard and lets you continue the saved draft.
* **Complete setup** calls `POST /api/v1/subaccounts/{id}/finalize` and activates the child without reopening every step. Finalize is idempotent, so retrying it is safe while the child is pending.

There is no delete-recovery grace period documented or exposed for a deletion request. A pending setup can be recovered with the actions above; a confirmed **Delete** is destructive and should be treated as permanent after the deletion cascade completes. Export anything you need before deleting, and use **Suspend** instead when you may need to restore the child.

For the full creation and pending-state walkthrough, see [New subaccount wizard: step-by-step](/guides/subaccount-create-wizard).

## Billing and credits during suspension

Suspension changes service access, not the wallet ledger:

* The child's credit balance remains in place.
* Usage rollups and statement line items continue to show the child's existing history. New usage should stop while the child is suspended, so the usage portion of the rollup should stop growing apart from delayed or already-recorded events.
* Standing plan charges continue to accrue according to the active rate model. Suspending is not a cancellation or a billing hold.
* Credit transfers are parent operations. A suspended child should not be used as a source of service while you decide whether to fund it; verify the current status and balance before attempting a transfer. If a transfer is rejected, reactivate only after resolving the billing or contract issue, then retry from the parent billing view.

Use the [reseller guide](/guides/subaccounts-reseller) for funding, spend caps, pricing, `POST /api/v1/subaccounts/{id}/transfer-credits`, and the usage-rollup endpoints.

## When to suspend

Use suspension as a reversible operational control when:

* **A child API key may be compromised.** Suspend first to stop requests, then rotate or revoke the affected key and review audit and delivery logs before reactivation.
* **A contract or service term has lapsed.** Suspend traffic while you resolve the account relationship; do not delete the child until the retention and number-ownership decision is complete.
* **A chargeback or payment restriction requires a service pause.** Suspend the child, review standing charges and credits with your billing owner, and reactivate only after the account is cleared.
* **An incident requires containment.** Pause the child while you inspect scheduled sends, in-flight work, webhooks, inbound routes, and credentials.

For a permanent offboarding, read the deletion warning in the console and follow the retirement guidance in [White-label subaccounts](/guides/subaccounts-reseller#retire-a-subaccount). For the data-boundary implications of keeping a child under a parent, see [The subaccount organization model](/concepts/subaccount-organization-model).

## See also

* [White-label subaccounts](/guides/subaccounts-reseller) — provision, fund, operate, suspend, reactivate, and retire through the API.
* [The subaccount organization model](/concepts/subaccount-organization-model) — understand ownership, visibility, and resource attribution.
* [New subaccount wizard: step-by-step](/guides/subaccount-create-wizard) — complete or resume a pending setup.
* [Subaccounts API](/api-reference/subaccounts) — endpoint schemas and responses.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.