Authentication & API keys

Every Send API request authenticates with a bearer key:

Authorization: Bearer mw_live_…    # production — accepted only on api.mailway.net
Authorization: Bearer mw_test_…    # sandbox — drives api.mailway.dev

Minting a key

In the console, open API keys and create one. Keys are per-project — the key is the project selection, so there’s no project field in any request. The full key is shown once at mint time; Mailway stores only a SHA-256 hash, so a key can never be read back — not by you, not by us.

Live vs test

The prefix tells you (and Mailway) what a key can do:

	`mw_live_…`	`mw_test_…`
Works on	`api.mailway.net` only	`api.mailway.dev`
Messages	relay to your providers	stored, never auto-forwarded (sandbox)
Quotas	counted	not counted

The host binding is enforced server-side: a live key presented to the sandbox host (or anywhere else) is rejected with 401. Pasting the wrong key into the wrong environment fails loudly instead of silently sending.

Handling keys well

Environment variables, never source control. The usual rule, worth repeating because email keys are a favorite exfiltration target.
One key per app or environment. Keys are free; revoking one surgically beats rotating a shared one under pressure.
Revoke from the console the moment a key might have leaked, then mint a replacement. Revocation is immediate.
Keys never work against the console API — and console sessions never work against the Send API. A leaked dashboard cookie can’t send mail, and a leaked send key can’t read your archive.

Errors

Status	Meaning
`401` `authentication_error`	Missing/malformed header, unknown or revoked key, or a `mw_live_…` key used off `api.mailway.net`.

Unauthenticated requests are also rate-limited harder (per-IP) than authenticated ones — see Limits.