Limits for agents

An API key held by an autonomous agent is a different risk from one held by a deploy pipeline. These controls sit on the key rather than the workspace and are checked on every send: a workspace quota only trips once the agent has already mailed thousands of people.

Daily send cap

A hard ceiling per key per UTC day, counted in recipients rather than calls: every address in to, cc and bcc that will actually be mailed, after suppressed, opted-out and undeliverable addresses are dropped. A send that would take the key past it returns 429 daily_limit. That is a stop, not a retry: an agent looping on it will simply burn its remaining budget against a closed door.

A scheduled send and a send held for approval count when they are asked for, not when they go out, so a rejected draft has still spent its share.

Recipient allowlist

Restrict a key to specific addresses or domains: ops@acme.com, or @acme.com (or acme.com) for the whole domain. An address outside the list, in to, cc or bcc, returns 403 recipient_not_allowed and nothing is sent. Lookalike domains do not match: acme.com.evil.com is not @acme.com, and neither is a subdomain such as mail.acme.com.

The allowlist is checked before the daily cap, so a misdirected send gets a clear reason instead of an ambiguous quota error.

Automations

Enrolling someone in an automation, with POST /v1/automations/{id}/enroll or POST /v1/events, is a promise to send them mail later, so the key's guardrails apply at enrolment. An address outside the key's allowlist returns 403 recipient_not_allowed, and a key that requires approval cannot enrol anyone at all (403 forbidden), because the steps go out later with nobody reviewing them. The daily cap does not apply: the steps are sent by the workspace's sequence, not by the key, and do not count against it.

Campaigns

A campaign follows the guardrails of the key that sends it. A key that requires approval, or one with a recipient allowlist, cannot send, schedule, reschedule or resume a campaign, or decide an A/B test's winner: each answers 403 forbidden. A campaign cannot wait in the approvals queue, and an audience cannot be held to an allowlist without quietly becoming a different audience. A key with a daily cap can send or schedule a draft only when the campaign's recipients, counted as GET /v1/broadcasts/{id}/preview counts them, fit what is left of the cap today; otherwise it answers 429 daily_limit and the campaign stays a draft. Once accepted, those recipients count against the cap. A guarded key can still create, edit and preview a campaign, and a person can send it from the dashboard. See Keys with guardrails.

Human approval

A key marked as requiring approval drafts instead of sending. The response comes back with status: "pending_approval" and an approval_id; a person releases it from the approvals queue.

That status is not an error and there is nothing to retry. An agent that treats it as a failure and sends again will queue a second draft. The key cannot approve its own drafts, no key with a guardrail of its own (an approval hold, a recipient allowlist or a daily cap) can approve anyone's, and neither can an OAuth access token: POST /v1/approvals/{id} answers 403 forbidden. Approvals are decided by a person in the dashboard or by an API key without guardrails.

MCP

The MCP server exposes this API as 55 tools, including reading a thread as a transcript and replying in place. Point an MCP client at it with an API key and the same scopes and limits apply. Signing in through the OAuth flow instead grants scopes but none of these limits, which belong to a key someone configured. An OAuth token cannot decide approvals, though, so a signed-in client cannot release drafts that a held key made. See MCP server for install and the three behaviours worth knowing.