skills/authorizing-api-requests/SKILL.md
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.
npx skillsauth add mailtrap/mailtrap-skills authorizing-api-requestsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Every Mailtrap API request needs two things:
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.
account_id for an account-scoped endpoint401 Unauthorized / 403 Forbidden responsesCreate tokens at Settings > API Tokens with the smallest scope that works:
send.api.mailtrap.io and bulk.api.mailtrap.io. Scope per stream (transactional, bulk) when possible.sandbox.api.mailtrap.io). Always separate from live sending tokens.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.
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.
.env file that is in .gitignore. Load with direnv, dotenv, or the framework's built-in mechanism.Hard rules:
ps, and CI logs.$VAR_NAME shell-var placeholders in all examples so generated code reaches for the env var, not the literal.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.
account_id automaticallyaccount_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 owner100 — Admin10 — 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.
# 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 '{ ... }'
| 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 |
development
Use when creating or sending Mailtrap-hosted email templates, Handlebars personalization, template UUID in API payloads, or debugging variables and preview. Use when separating email design from application code for transactional or bulk sends.
development
Use when capturing outbound email in development or staging without delivering to real recipients, inspecting HTML or headers, running spam or structure checks, or automating tests against a fake inbox. Use when testing outgoing mail from an app without committing to a production ESP yet. Use when using Mailtrap Email Sandbox, Sandbox API, or sandbox-mode sending.
tools
Use when adding or verifying a Mailtrap sending domain, DNS propagation issues, registrar or DNS provider steps, compliance after verification, or click tracking. Domain must be verified before sending from it.
development
Use when integrating, configuring, or troubleshooting Mailtrap live email sending (Email API or SMTP). Use when wiring outbound mail from an application or choosing how to send.