# Pause and Resume Sending

Source: https://molted.email/docs/account-pause

Stop all outgoing email for the whole workspace from the portal, the phone app, the API or the CLI, and how a pause is lifted.

An account pause stops every send in your workspace at once, across all mailboxes. Use it when you want everything to stop first and look second: an agent is misbehaving, a bounce rate is climbing, or you are about to change something big. To stop one mailbox only, see [Pausing and resuming a mailbox](https://molted.email/docs/mailboxes.md#pausing-and-resuming).

Anyone can pause, an agent included. Lifting the pause is a person's decision (see [Resuming](#resuming-is-a-human-decision)).

## Pause and resume from anywhere

| Where | Pause | Resume |
| - | - | - |
| Portal | The status pill in the top bar, then **Pause everything**. Or press `⌘K`, type `pause` and pick **Pause everything**. | The same pill reads **Paused**; open it and choose **Resume everything**. Or `⌘K`, type `resume`. |
| Phone app | **Pause all sending**, in Settings and as a quick action on the Needs you screen. | **Resume all sending**. |
| API, signed-in person | `POST /v1/me/sending/pause` with an optional `{ "reason": "..." }` (up to 500 characters). | `POST /v1/me/sending/resume` |
| API key or CLI | `POST /v1/ops/pause` with an optional `{ "reason": "..." }`, or `molted pause --reason "..."`. | `POST /v1/ops/resume`, or `molted resume`. Needs a person, see below. |

The two `/v1/me/sending/*` routes belong to the portal and the phone app: they use a person's session, never an API key. Both answer with the updated sending state, `{ "sending": { "state": "paused", "accountPaused": true, "pausedMailboxIds": [] } }`. The `state` is `sending`, `partial` (some mailboxes paused) or `paused`.

```bash title="CLI"
molted pause --reason "investigating a bounce spike"
molted incidents list --status open
molted resume    # usually needs a person, see below
```

```bash title="curl"
curl -X POST https://mailbox.molted.email/v1/ops/pause \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"reason": "investigating a bounce spike"}'
```

```json title="Response"
{ "incidentId": "7c1f0e52-8f0a-4b8e-9d3a-52b0a1c1d9e4", "paused": true }
```

An agent pausing needs no particular scope: any valid key works, including a key limited to one mailbox. The reason is stored on the incident. Without one, the API records `Manual pause`.

## What a pause blocks

- **Every send.** A send request is answered `blocked` with the reason `tenant_paused` (see [Errors](https://molted.email/docs/errors.md#policy-engine)). That covers `molted send`, replies, batches and the dry runs, which report `isTenantPaused` in their `policyContext`.
- **Journey steps and scheduled follow-ups wait.** They are retried every 15 minutes while the account is paused and go out once it is resumed. After 72 hours of waiting they give up with `paused_timeout`: the journey run fails and the follow-up is cancelled.

A pause does not stop receiving mail, classifying it, or reading threads. Your agents can keep reading.

A pause is not an alert: it does not notify your [alert destinations](https://molted.email/docs/alerts.md). Watch for it with `molted incidents list` or the [event stream](https://molted.email/docs/events.md).

## Incidents

Pausing opens an incident, and the incident is the pause. Sending stays blocked for as long as an incident of type `manual_pause` or `auto_pause` is `open` or `acknowledged`.

| Type | What it is |
| - | - |
| `manual_pause` | A pause made on purpose, from any surface in the table above. |
| `auto_pause` | A pause Molted opens by itself. The send gate and every resume path already honour it, but nothing opens one today: a mailbox that is paused for its reputation is a [mailbox pause](https://molted.email/docs/mailboxes.md#reputation-pauses), not an account pause. |

| Status | Meaning |
| - | - |
| `open` | The pause is in force. |
| `acknowledged` | Someone has seen it. The pause is still in force. |
| `resolved` | The pause is lifted. |

```bash title="CLI"
molted incidents list
molted incidents list --status open
molted incidents ack INCIDENT_ID        # I have seen this; sending stays paused
molted incidents resolve INCIDENT_ID    # lifts the pause, same rule as resume
```

`GET /v1/ops/incidents` returns up to 100 incidents, newest first, optionally filtered with `?status=open`. Each row has `id`, `type`, `reason`, `status`, `created_at`, `acknowledged_at`, `resolved_at`, `resolved_by` and `metadata`. `PATCH /v1/ops/incidents/:id` takes `{ "status": "acknowledged" }` or `{ "status": "resolved" }` (and an optional `resolvedBy` label when resolving) and answers `{ "updated": true }`. An unknown incident, or one from another workspace, is a `404 incident_not_found`. Changing an incident needs a key that reaches every mailbox with `manage` or `admin` scope.

Today the only incidents Molted opens are pauses.

## Resuming is a human decision

Pausing is always open to agents; resuming is not. A person signed in to the portal or the phone app can resume at any time.

**From the portal.** **Resume everything** resolves every open or acknowledged pause incident, manual and automatic.

**From an agent key.** `POST /v1/ops/resume` (and resolving an open pause incident with `PATCH /v1/ops/incidents/:id`) is a [loosening](https://molted.email/docs/errors.md#loosening-a-control). While the account is paused, the default `enforce` human gate answers `403 human_decision_required` with `kind: "account-resume"`, `loosens: ["account pause"]` and a `decisionUrl` to hand to a person. In `warn` mode the call goes through with a `Molted-Deprecation: human-gate` header, and in `off` mode it simply works. Acknowledging an incident is never gated, and it does not resume anything. The key needs `manage` or `admin` scope across every mailbox.

If the account is not paused, a resume succeeds and changes nothing. The response lists the incidents it resolved, with the status each had before, so a resume can be undone:

```json title="Response"
{
  "resumed": true,
  "resolved": [
    { "id": "7c1f0e52-8f0a-4b8e-9d3a-52b0a1c1d9e4", "type": "manual_pause", "previousStatus": "open" }
  ]
}
```

**From the phone app.** The phone resumes a pause that a person or an agent made, but not an automatic one. While an `auto_pause` incident is open, the phone's resume answers `403` with `auto_pause_web_only`, and the pause stays: review it and resume from the portal. The same rule holds for a mailbox that was paused for its reputation. A phone's resume lifts manual pauses only.

## Pausing twice

`POST /v1/ops/pause` is not idempotent. Every call opens a new incident, even when the account is already paused, so two calls leave two open incidents. A single resume resolves all of them, but your incident list fills with duplicates. `molted pause` avoids this: it reads the open incidents first and, when the account is already paused, answers `alreadyPaused: true` without opening another. If that read fails, it pauses anyway, because pausing is the safe direction.

The portal and phone routes never stack: pausing an account that is already paused changes nothing.

## Who did it

Every pause and resume is recorded with the person or key behind it, and shows up in the workspace's activity on Home and in the [audit log](https://molted.email/docs/privacy.md#decision-trace). A person can put back an agent's account pause or resume, along with everything else that key changed, from **Settings > Access**: see [Undo what an agent changed](https://molted.email/docs/undo-agent-changes.md).

## Related reading

- [Mailboxes](https://molted.email/docs/mailboxes.md#pausing-and-resuming): pause one mailbox
- [Errors & policy blocks](https://molted.email/docs/errors.md): `tenant_paused` and the other send reasons
- [Loosening a control](https://molted.email/docs/errors.md#loosening-a-control): what agents may tighten and what needs a person