Credential classes
| Credential class | Created by | Secret lifetime | Where to manage it |
|---|---|---|---|
| Manual API key | A team member creates a key in Sendmux. | Long-lived until you rotate or revoke it. | API Keys with the Manual keys filter. |
| Connected app | You authorise an app through OAuth, such as Product MCP. | 15-minute access tokens with rotating refresh tokens. | API Keys with the Connected apps filter. |
Key types
| Key type | Use it for | Secret prefix |
|---|---|---|
| Infrastructure key | Team automation, providers, routing, billing, logs, domains, mailboxes, and webhooks. | smx_root_ |
| Sending key | Sending mail through the Sending API, SMTP, CLI tools, MCP clients, or agents. | smx_mbx_ |
| Mailbox key | API, IMAP, and SMTP access for one mailbox. | smx_mbx_ |
smx_mbx_ prefix. Their permissions and sending scope decide what each key can do.
Each team starts with 100 active credentials across manual API keys and
connected apps. See Team limits.
Connected apps
Connected apps let tools such as Product MCP act with the product lines you authorise. During authorisation, you can choose Management, Mailbox, Sending, or a combination. If you choose Mailbox, you also choose the mailbox set the app can use. Sendmux then issues a short-lived access token for the app and a refresh token that rotates when used. When a connected app asks for Management access, permissions are grouped by area, including Analytics, Billing, Domains, Email, Keys, Logs, Mailboxes, Providers, Routing, Team, and Webhooks. Each group can be set to None, Read, Full, or Customise, so you can review broad access quickly and open individual scopes only when needed. Connected apps do not createsmx_root_ or smx_mbx_ secrets. They are listed separately from manual API keys so you can see which app is connected, which product lines it can use, which mailbox set is selected, who authorised it, when it was last used, and how many requests it has made.
To manage connected apps:
Re-authorising the same app updates the existing connection instead of creating unused manual API keys. If you choose fewer product lines or mailboxes during re-authorisation, removed tools and mailbox targets stop being available to that app.
Create a key
Choose the key type
Select Create API Key, then choose the key type. Sending keys can route
through all providers, selected providers, or delivery groups.
Scopes and presets
Infrastructure keys use role presets such as Full Access, Read Only, Provider Admin, Billing Admin, and Webhook Admin. Sending and mailbox keys use mailbox permissions:| Permission | Allows |
|---|---|
email.send | Send email through HTTP or SMTP. |
email.receive | Receive email through mailbox access. |
mailbox.read | Read mailbox folders and messages. |
mailbox.settings.update | Update mailbox identity and settings. |
Rotate a key
Use rotation when a key may have leaked, when a team member leaves, or as part of regular credential hygiene.- Select the rotate action beside the key.
- Copy the new secret when it appears.
- Deploy the new secret to every system that uses it.
- Revoke the old key once all callers have moved.
Revoke a key
Revocation is immediate. Any system still using the key loses access. Create and test a replacement before revoking a production key. Mailbox keys also stop working while their mailbox is suspended, and work again after the mailbox is resumed.Related guides
Send by HTTP
Use a sending key to queue messages through the API.
Delivery groups
Route sending keys through selected provider groups.
Mailboxes
Create mailbox keys and per-integration passwords.
API errors
Handle authentication, permission, and rate-limit errors.