Pause and Resume Sending

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.

Anyone can pause, an agent included. Lifting the pause is a person's decision (see Resuming).

Pause and resume from anywhere

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.

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

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"}'

{ "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). 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. Watch for it with molted incidents list or the event stream.

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.

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. 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:

{
  "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. 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.

Related reading

• Mailboxes: pause one mailbox
• Errors & policy blocks: tenant_paused and the other send reasons
• Loosening a control: what agents may tighten and what needs a person