Authorizing Mailtrap API requests
Overview
Every Mailtrap API request needs two things:
- An API token in an auth header — proves identity and carries the scope.
- For account-scoped endpoints (most of them outside of the send hosts), an
account_id in the URL path.
This skill is the single source of truth for both. Other skills (sending-emails, testing-with-sandbox, using-email-templates, managing-contacts, setting-up-sending-domain) reference these conventions instead of duplicating them.
When to use
- Before writing any Mailtrap API call from code, scripts, CI, IaC, or an AI agent
- Picking which token scope and stream to provision
- Deciding where to store a token (env, secret manager, CI)
- Resolving the
account_id for an account-scoped endpoint
- Debugging
401 Unauthorized / 403 Forbidden responses
API tokens
Create tokens at Settings > API Tokens with the smallest scope that works:
- Email Sending API — for
send.api.mailtrap.io and bulk.api.mailtrap.io. Scope per stream (transactional, bulk) when possible.
- Email Testing API — for the Sandbox (
sandbox.api.mailtrap.io). Always separate from live sending tokens.
- Account-level API — for Contacts, Templates, Sending Domains, Suppressions, and other endpoints under
https://mailtrap.io/api/accounts/{account_id}/....
A single token can cover several scopes if the user has the right plan; prefer narrower tokens (one stream / one project / one product surface) so a leak has limited blast radius. Reference: API tokens documentation.
Auth headers (two equivalent forms)
Mailtrap accepts either header. Use Bearer in examples — it's the more common HTTP convention and matches most generated SDK code.
| Form |
Header |
When to use |
| Bearer (preferred) |
Authorization: Bearer $MAILTRAP_API_TOKEN |
Default for new code, SDKs, curl examples |
| Api-Token (legacy) |
Api-Token: $MAILTRAP_API_TOKEN |
Older clients or where Bearer is awkward |
Do not send both at the same time. The same value goes in either header.
Where to put tokens
- Local dev: environment variable, or
.env file that is in .gitignore. Load with direnv, dotenv, or the framework's built-in mechanism.
- CI / build: the CI provider's encrypted secret store (GitHub Actions secrets, GitLab CI variables, CircleCI contexts). Inject as env vars only.
- Production / staging: a real secret manager (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, Doppler, 1Password, etc.). Rotate on a schedule.
- Agent / LLM workflows: the host agent's secret store. Never paste a token into chat or a prompt.
Hard rules:
- Never hardcode a token in source, config, or notebooks.
- Never commit a token. If one lands in git, rotate it; history retention is forever.
- Never pass a token on the command line as a flag — it leaks into shell history,
ps, and CI logs.
- Never let an LLM echo a literal token back into generated code. Use
$VAR_NAME shell-var placeholders in all examples so generated code reaches for the env var, not the literal.
- Never mix sandbox and live tokens. A leaked sandbox key must not be able to send real mail.
Recommended env var names
These names are used consistently across every other skill in this repo and across the example snippets below.
| Variable |
Used for |
MAILTRAP_API_TOKEN |
General API: Email Send (transactional and bulk), Templates, Contacts, Sending Domains, Suppressions |
MAILTRAP_SANDBOX_API_TOKEN |
Sandbox / Email Testing (separate scope) |
MAILTRAP_ACCOUNT_ID |
Path parameter for account-scoped endpoints |
If your environment uses different names, alias them once at startup so the examples in other skills work unchanged.
Resolving account_id automatically
account_id is the integer prefix on every https://mailtrap.io/api/accounts/{account_id}/... endpoint. Do not hardcode it. It changes between environments, is different per organization, and is silently wrong when you copy a script to a teammate's account.
Resolve it once per session from the Accounts endpoint, which lists every account the token can access:
curl -s https://mailtrap.io/api/accounts \
-H "Authorization: Bearer $MAILTRAP_API_TOKEN"
Response shape (array):
[
{"id": 12345, "name": "My Company", "access_levels": [1000]},
{"id": 67890, "name": "Client Account", "access_levels": [100]}
]
access_levels values:
1000 — Account owner
100 — Admin
10 — Viewer (read-only on most endpoints)
One-liner to cache as an env var (pick the right account if the token can see more than one):
export MAILTRAP_ACCOUNT_ID=$(curl -s https://mailtrap.io/api/accounts \
-H "Authorization: Bearer $MAILTRAP_API_TOKEN" | jq '.[0].id')
Reference: Accounts API.
Quick reference
# Live sending (no account_id in path)
curl -X POST https://send.api.mailtrap.io/api/send \
-H "Authorization: Bearer $MAILTRAP_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{ ... }'
# Account-scoped endpoint
curl "https://mailtrap.io/api/accounts/$MAILTRAP_ACCOUNT_ID/contacts/lists" \
-H "Authorization: Bearer $MAILTRAP_API_TOKEN"
# Sandbox / Testing
curl -X POST "https://sandbox.api.mailtrap.io/api/send/$MAILTRAP_INBOX_ID" \
-H "Authorization: Bearer $MAILTRAP_SANDBOX_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{ ... }'
Common mistakes
| Mistake |
Fix |
| Hardcoding the token in code, config, or a notebook |
Load from $MAILTRAP_API_TOKEN (env, .env, CI secret, secret manager); rotate the token if it ever leaked |
Passing the token as a CLI flag (--token=...) |
Use env vars; CLI flags leak to shell history, ps, and CI logs |
| Committing a token, then deleting it in a later commit |
History keeps the value forever — rotate the token immediately, do not just remove the file |
| Pasting a token into chat / prompt / issue |
Treat chat as public; rotate if it happened |
Using the live MAILTRAP_API_TOKEN against the sandbox host |
Sandbox uses its own scope and MAILTRAP_SANDBOX_API_TOKEN; mixing them either fails or sends real mail by accident |
Hardcoding account_id |
Resolve via GET https://mailtrap.io/api/accounts once per run and pass through $MAILTRAP_ACCOUNT_ID |
| Picking the wrong account when the token can see several |
Filter the GET /api/accounts response by name or access_levels (1000 = owner) instead of .[0] |
Sending both Authorization and Api-Token headers |
Pick one (Bearer for new code); duplicating them is unnecessary and confuses some intermediaries |
| Using a viewer-scoped token for writes |
Check access_levels; writes need 100 (admin) or 1000 (owner) for the relevant account |
1---2name: authorizing-api-requests3description: Use when authenticating or authorizing requests to any Mailtrap API (Email Send, Email Testing/Sandbox, Templates, Contacts, Sending Domains, Suppressions). Use when picking the auth header, choosing token scope, storing tokens safely, or resolving the Mailtrap account_id. Use before writing or generating any Mailtrap API call.4---5
6# Authorizing Mailtrap API requests
7
8## Overview
9
10Every Mailtrap API request needs **two things**:
11
121. An **API token** in an auth header — proves identity and carries the scope.
132. For account-scoped endpoints (most of them outside of the send hosts), an **`account_id`** in the URL path.
14
15This skill is the single source of truth for both. Other skills (`sending-emails`, `testing-with-sandbox`, `using-email-templates`, `managing-contacts`, `setting-up-sending-domain`) reference these conventions instead of duplicating them.
16
17## When to use
18
19- Before writing any Mailtrap API call from code, scripts, CI, IaC, or an AI agent
20- Picking which token scope and stream to provision
21- Deciding where to store a token (env, secret manager, CI)
22- Resolving the `account_id` for an account-scoped endpoint
23- Debugging `401 Unauthorized` / `403 Forbidden` responses
24
25## API tokens
26
27Create tokens at **Settings** > [API Tokens](https://mailtrap.io/api-tokens) with the **smallest scope** that works:
28
29- **Email Sending API** — for `send.api.mailtrap.io` and `bulk.api.mailtrap.io`. Scope per stream (transactional, bulk) when possible.
30- **Email Testing API** — for the Sandbox (`sandbox.api.mailtrap.io`). Always separate from live sending tokens.
31- **Account-level API** — for Contacts, Templates, Sending Domains, Suppressions, and other endpoints under `https://mailtrap.io/api/accounts/{account_id}/...`.
32
33A single token can cover several scopes if the user has the right plan; prefer narrower tokens (one stream / one project / one product surface) so a leak has limited blast radius. Reference: [API tokens documentation](https://docs.mailtrap.io/email-api-smtp/setup/api-tokens.md).
34
35## Auth headers (two equivalent forms)
36
37Mailtrap accepts either header. Use Bearer in examples — it's the more common HTTP convention and matches most generated SDK code.
38
39| Form | Header | When to use |
40| ------------------- | -------------------------------------------- | -------------------------------------------- |
41| Bearer (preferred) | `Authorization: Bearer $MAILTRAP_API_TOKEN` | Default for new code, SDKs, curl examples |
42| Api-Token (legacy) | `Api-Token: $MAILTRAP_API_TOKEN` | Older clients or where Bearer is awkward |
43
44Do not send both at the same time. The same value goes in either header.
45
46## Where to put tokens
47
48- **Local dev:** environment variable, or `.env` file that is in `.gitignore`. Load with `direnv`, `dotenv`, or the framework's built-in mechanism.
49- **CI / build:** the CI provider's encrypted secret store (GitHub Actions secrets, GitLab CI variables, CircleCI contexts). Inject as env vars only.
50- **Production / staging:** a real secret manager (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, Doppler, 1Password, etc.). Rotate on a schedule.
51- **Agent / LLM workflows:** the host agent's secret store. Never paste a token into chat or a prompt.
52
53Hard rules:
54
55- **Never** hardcode a token in source, config, or notebooks.
56- **Never** commit a token. If one lands in git, rotate it; history retention is forever.
57- **Never** pass a token on the command line as a flag — it leaks into shell history, `ps`, and CI logs.
58- **Never** let an LLM echo a literal token back into generated code. Use `$VAR_NAME` shell-var placeholders in all examples so generated code reaches for the env var, not the literal.
59- **Never** mix sandbox and live tokens. A leaked sandbox key must not be able to send real mail.
60
61## Recommended env var names
62
63These names are used consistently across every other skill in this repo and across the example snippets below.
64
65| Variable | Used for |
66| ---------------------------- | -------------------------------------------------------------------------------------- |
67| `MAILTRAP_API_TOKEN` | General API: Email Send (transactional and bulk), Templates, Contacts, Sending Domains, Suppressions |
68| `MAILTRAP_SANDBOX_API_TOKEN` | Sandbox / Email Testing (separate scope) |
69| `MAILTRAP_ACCOUNT_ID` | Path parameter for account-scoped endpoints |
70
71If your environment uses different names, alias them once at startup so the examples in other skills work unchanged.
72
73## Resolving `account_id` automatically
74
75`account_id` is the integer prefix on every `https://mailtrap.io/api/accounts/{account_id}/...` endpoint. **Do not hardcode it.** It changes between environments, is different per organization, and is silently wrong when you copy a script to a teammate's account.
76
77Resolve it once per session from the Accounts endpoint, which lists every account the token can access:
78
79```bash
80curl -s https://mailtrap.io/api/accounts \
81 -H "Authorization: Bearer $MAILTRAP_API_TOKEN"
82```
83
84Response shape (array):
85
86```json
87[
88 {"id": 12345, "name": "My Company", "access_levels": [1000]},
89 {"id": 67890, "name": "Client Account", "access_levels": [100]}
90]
91```
92
93`access_levels` values:
94
95- `1000` — Account owner
96- `100` — Admin
97- `10` — Viewer (read-only on most endpoints)
98
99One-liner to cache as an env var (pick the right account if the token can see more than one):
100
101```bash
102export MAILTRAP_ACCOUNT_ID=$(curl -s https://mailtrap.io/api/accounts \
103 -H "Authorization: Bearer $MAILTRAP_API_TOKEN" | jq '.[0].id')
104```
105
106Reference: [Accounts API](https://docs.mailtrap.io/developers/account-management/accounts).
107
108## Quick reference
109
110```bash
111# Live sending (no account_id in path)
112curl -X POST https://send.api.mailtrap.io/api/send \
113 -H "Authorization: Bearer $MAILTRAP_API_TOKEN" \
114 -H "Content-Type: application/json" \
115 -d '{ ... }'
116
117# Account-scoped endpoint
118curl "https://mailtrap.io/api/accounts/$MAILTRAP_ACCOUNT_ID/contacts/lists" \
119 -H "Authorization: Bearer $MAILTRAP_API_TOKEN"
120
121# Sandbox / Testing
122curl -X POST "https://sandbox.api.mailtrap.io/api/send/$MAILTRAP_INBOX_ID" \
123 -H "Authorization: Bearer $MAILTRAP_SANDBOX_API_TOKEN" \
124 -H "Content-Type: application/json" \
125 -d '{ ... }'
126```
127
128## Common mistakes
129
130| Mistake | Fix |
131| ------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
132| Hardcoding the token in code, config, or a notebook | Load from `$MAILTRAP_API_TOKEN` (env, `.env`, CI secret, secret manager); rotate the token if it ever leaked |
133| Passing the token as a CLI flag (`--token=...`) | Use env vars; CLI flags leak to shell history, `ps`, and CI logs |
134| Committing a token, then deleting it in a later commit | History keeps the value forever — rotate the token immediately, do not just remove the file |
135| Pasting a token into chat / prompt / issue | Treat chat as public; rotate if it happened |
136| Using the live `MAILTRAP_API_TOKEN` against the sandbox host | Sandbox uses its own scope and `MAILTRAP_SANDBOX_API_TOKEN`; mixing them either fails or sends real mail by accident |
137| Hardcoding `account_id` | Resolve via `GET https://mailtrap.io/api/accounts` once per run and pass through `$MAILTRAP_ACCOUNT_ID` |
138| Picking the wrong account when the token can see several | Filter the `GET /api/accounts` response by `name` or `access_levels` (1000 = owner) instead of `.[0]` |
139| Sending both `Authorization` and `Api-Token` headers | Pick one (Bearer for new code); duplicating them is unnecessary and confuses some intermediaries |
140| Using a viewer-scoped token for writes | Check `access_levels`; writes need 100 (admin) or 1000 (owner) for the relevant account |