Temp Mail API: What to Use

The mail.tm API

mail.tm documents its API at docs.mail.tm. There is no key and no sign-up. You create an inbox, swap its address and password for a token, then read messages with that token.

• Base URL: https://api.mail.tm
• Main calls: GET /domains, POST /accounts, POST /token, GET /messages and GET /messages/{id}. Messages come 30 to a page.
• Limit: 8 requests a second per IP address. Go over it and you get HTTP 429.
• New mail without polling: a server-sent events feed tells you when a message arrives.
• Receive only: there is no endpoint for sending. mail.tm's FAQ says messages are kept for 7 days.

const API = "https://api.mail.tm";
const json = { "Content-Type": "application/json" };

// 1. Pick a domain and create an inbox.
const domains = await (await fetch(`${API}/domains`)).json();
const address = `test-${Date.now()}@${domains["hydra:member"][0].domain}`;
const password = crypto.randomUUID();
await fetch(`${API}/accounts`, { method: "POST", headers: json, body: JSON.stringify({ address, password }) });

// 2. Get a token for it.
const { token } = await (await fetch(`${API}/token`, {
  method: "POST", headers: json, body: JSON.stringify({ address, password }),
})).json();

// 3. Check for mail. Stay well under 8 requests a second.
const inbox = await (await fetch(`${API}/messages`, {
  headers: { Authorization: `Bearer ${token}` },
})).json();
console.log(inbox["hydra:member"].map((m) => m.subject));

mail.tm's rules

The docs list four: no illegal use, no paid product that simply wraps the API, no mirroring or proxying it under another domain, and a visible link back to mail.tm from anything that uses it. Read them before you build on it. A free service can also change or stop without notice, so don't make it a hard dependency of anything important.

Other temp mail APIs

Guerrilla Mail has a public JSON API, dated 2011, which it describes as open to all. It may be rate limited, and the limits aren't published. Each call has to pass your IP address and user agent and keep a session going, so it is clumsier to script.

Testing your own sign-up emails

If you are testing an app you build, a public temp mail inbox is the wrong tool for automated runs. Its domains change, it can be slow or down, it rate-limits you, and your own sign-up form may block it if you use a disposable-domain list. These tools are built for the job:

Prices as listed on each pricing page in October 2026.

A setup that needs no service at all

1. Locally, catch mail instead of sending it. Point your app's SMTP settings at a local catcher such as Mailpit, which shows every message in a web page and has its own API for tests.
2. Against staging, use plus addressing on a domain you own. qa+run-4812@yourcompany.com gives each test run a unique address that still lands in one mailbox, which your test can read over IMAP.
3. Keep test domains off your own blocklist. If your sign-up form refuses disposable domains, allow the domain your tests use, or the tests will fail for the wrong reason.

For a quick manual check, opening a temp mail inbox in another tab is fine. Our developer testing guide goes into more detail, and the disposable email checker shows whether a domain is on the public blocklist.

Questions