API keys
Create, scope, and revoke API keys. Keys start with mb_, carry a full_access or sending_access permission, and are shown in full exactly once.
Every API request authenticates with an API key sent as a Bearer token (see Authentication). Keys are created in the dashboard under API Keys, or via the API.
A key is returned once at creation — the full mb_... token is shown a single time, and only its hash and prefix are stored afterward. If you lose it, create a new one.
Permissions
Each key has a permission level that controls what it can do:
| Permission | Can do |
|---|---|
full_access | Send email and manage resources — domains, audiences, contacts, campaigns, webhooks, and other API keys. |
sending_access | Send email only. Cannot create or delete domains, audiences, campaigns, or other keys. |
Prefer a sending_access key for any server that only needs to send email — it limits the blast radius if the key leaks. Note that a key can only mint or revoke other keys if it has full_access.
You can create multiple keys to isolate different applications or environments. Scoping each integration to its own key lets you track its usage independently, spot abuse, and revoke just that key if it leaks — without disrupting your other services.
Tracking usage
Each key records when it was last used. List your keys with `GET /api-keys` — each entry carries a last_used_at timestamp (null if the key has never been used) alongside its name and created_at. The dashboard surfaces the same signal so you can scan which keys are active and which are dormant.
Rotation and revocation
Keys do not expire on their own. To rotate, create a new key, deploy it, then delete the old one — deletion is immediate and irreversible. A revoked key returns 403 invalid_api_key on its next use.
- Create a key: `POST /api-keys`.
- List keys (metadata only — never the token): `GET /api-keys`.
- Revoke a key: `DELETE /api-keys/:id`.