Skip to main content
The Sendmux Mailbox API is for mailbox-scoped access. Use it when a client should act as a mailbox, or as one mailbox from a connected-app mailbox set, without managing team-wide resources. Team-wide mailbox provisioning stays in the Management API. High-volume provider-routed sending stays in the Sending API.

Base URL

All Mailbox API requests should be made to:

Authentication

Authenticate with a mailbox credential, connected-app access token, or agent access token from Sendmux. Pass it as a Bearer token in the Authorization header.
Manual mailbox credentials are scoped to one mailbox. The same credential is also accepted as the mailbox password for SMTP submission and IMAP retrieval. Connected-app tokens can be granted one or more mailboxes, and each mailbox request is limited to that granted set. Agent access tokens use the smx_agent_ prefix and are limited by their granted scopes. Root API keys are rejected on Mailbox API endpoints.

Current endpoints

Import the Mailbox API Postman collection when you want ready-made requests.

Mailbox targeting for connected apps

Manual mailbox credentials always target their single mailbox. Omit mailbox_id when you use a manual smx_mbx_ credential. Connected-app tokens can grant a set of mailboxes. Use GET /mailbox/mailboxes to list or search the granted set, then pass the selected mailbox’s id as mailbox_id on Mailbox API requests. Self-registered agent tokens target their assigned mailbox. Omit mailbox_id when you use a pre-claim smx_agent_ token. Pre-claim tokens can read and receive mail, but they cannot send. After owner approval, an app-resource smx_agent_ token with email.send can send from the assigned mailbox.
If a connected app has exactly one granted mailbox, Mailbox API requests use that mailbox by default. If several mailboxes are granted and you omit mailbox_id, Sendmux returns 400 missing_parameter. If you pass a mailbox outside the grant, Sendmux returns 403 insufficient_permissions.

Capability discovery

Use GET /mailbox/session before planning a mailbox workflow. It returns the selected mailbox, supported Mailbox API features, current state tokens, request limits, and gated features. A gated feature is intentionally unavailable through the Mailbox API.
gated fields are true when a feature is intentionally unavailable.

Operational resources

Operational endpoints expose what an agent needs to send safely and monitor mailbox health without adding mutation authority.

Sender identities

Use GET /mailbox/identity to read the mailbox’s default sender name and signatures. Use PATCH /mailbox/identity to update name, text_signature, and html_signature. Mailbox API sends use this sender name by default and append the matching plain text or HTML signature when the send body includes that format.
GET /mailbox/identities lists all sender identities available to the authenticated mailbox.

Send submissions

Use submissions to inspect queued, sent, failed, or cancelled send lifecycle records separately from the messages/send request that created them.
Useful filters: Read one submission with GET /mailbox/submissions/{submission_id}. Poll GET /mailbox/submissions/changes?since_state=... to sync submission object changes.

Quotas and usage

Use quotas for detailed limits and usage for a compact health view.
Quota filters: Poll GET /mailbox/quotas/changes?since_state=... to sync quota changes.

Thread APIs

Use thread endpoints when you need conversation-level context without fetching every body.

List threads

Thread list filters:

Read a thread

The response includes the same thread metadata as the list endpoint plus message_ids in chronological order. Use GET /mailbox/threads/{thread_id}/messages for paginated message summaries, or GET /mailbox/threads/{thread_id}/content when you need cleaned bodies.

Retrieval precision APIs

Use exact retrieval and count endpoints when you already know what you need. This keeps client payloads small and avoids fetching message bodies just to answer count or search-preview questions.

Rich message filters

GET /mailbox/messages and GET /mailbox/messages/count support these filters. GET /mailbox/messages/search-snippets and GET /mailbox/messages/query-changes support the same filters except thread_id; pass message_ids when you already know the exact messages to snippet.
thread_id uses the thread’s message order and cannot be combined with other message filters. Use the thread content endpoint when you need cleaned bodies for one conversation.

Count messages

Use the count endpoint when you only need the number of matches.

Search snippets

Use snippets to decide which matching messages deserve a full fetch. Snippets may include <mark> tags around matched terms.
Pass message_ids as a comma-separated list when you already have exact messages:

Batch get messages

Use batch get when you have exact IDs and want one request instead of one call per message.
Batch body modes:

Batch update messages

Use batch update to set allowed flags and keywords on up to 100 messages in one state-safe request. keywords is a map where true sets a keyword and false clears it. Keyword names are normalised to lowercase. Lifecycle keywords such as $draft are read-only.

Batch delete messages

Use batch delete to move up to 100 messages to Trash. Set permanent=true only when the messages should be permanently removed.
Batch update and delete accept if_in_state for stale-write protection. Use the latest message state from message lists, detail reads, batch reads, or change endpoints.

Message body APIs

Use the raw body endpoint when you need the message body exactly as available from the mailbox.
Use the clean content endpoint when you want deterministic body cleaning and structured metadata.
Clean content controls:
Body endpoints do not parse attachment contents. Attachments are returned as metadata or downloaded separately. PDF, CSV, Office document, and OCR parsing are not part of these APIs.

Attachments

Use POST /mailbox/attachments:upload for binary files up to 7.5 MB. Send the raw bytes in the request body, then pass the returned blob_id to POST /mailbox/messages/send. Final outbound messages, including bodies, headers, and encoded attachments, must fit inside the 25 MB raw message limit.
Then send the uploaded attachment by ID:
Small inline base64 attachments are still supported on messages/send, but the upload endpoint avoids large JSON request bodies. Message metadata can include a short-lived download_url for clients that need a no-header download link. Fetch it promptly without an Authorization header. If it expires, re-read message or attachment metadata to receive a fresh URL. MCP clients should prefer mailbox_read_attachment for text-like inbound attachments and use the returned link only for binary or oversized files. Attachment downloads support byte ranges:

Sync APIs

Use sync endpoints to poll for changes with state tokens returned by earlier responses, or open an event stream when a client needs live updates.

Event stream

GET /mailbox/events streams mailbox events as Server-Sent Events. Use it for agents, CLIs, MCP servers, and SDKs that need to react when inbound mail arrives. Use webhooks instead when a backend service should receive signed event POSTs without keeping a live connection open.
Each received-message event includes subject, participants, preview, attachment metadata, and a capped body snapshot. Use the message and attachment endpoints when you need full content or attachment bytes. To resume after a disconnect, pass the last SSE id as the Last-Event-ID header or the last_event_id query parameter. If the stream sends sync_required, call GET /mailbox/changes before reopening the stream. Optional query parameters:

Message query changes

GET /mailbox/messages/query-changes tracks how a filtered message list has changed since a prior query_state. Omit since_query_state to get the current query state for a filter without a change list.

Folder changes

GET /mailbox/folders/changes tracks folder object changes. Omit since_state to get the current folder state without a change list.

Folder query changes

GET /mailbox/folders/query-changes tracks folder-list ordering changes. Omit since_query_state to get the current folder query state.

Typed mailbox changes

GET /mailbox/changes keeps the legacy message-only response when types is omitted. Pass a comma-separated types list to receive a typed state map.
Supported types values are messages, folders, threads, submissions, identities, and quotas.

Response format

The Mailbox API uses the same envelope as the Management API.

Success

Error

Every response includes an X-Request-Id header matching meta.request_id. Include that value when contacting support.

Rate limiting

Mailbox API keys are rate-limited to 1800 requests per minute. Rate limit headers are included on responses:
When the limit is exceeded, the API returns 429 rate_limit_exceeded with a Retry-After header.

Conventions

  • snake_case fields in JSON request and response bodies
  • UTC ISO 8601 timestamps in RFC 3339 format: 2026-03-19T10:30:00Z
  • Opaque IDs only for mailbox, message, folder, and attachment resources
  • Cache-Control: no-store on authenticated responses
  • Weak ETag headers on single-resource GETs where supported
  • Header-based idempotency for retriable POST requests where supported

OpenAPI specification

Mailbox API endpoints are included in the app API specification: