Temporary Email for Developers: Testing Email Flows Without the Mess

Why Developers Need This

If you've ever maintained a signup flow, you've solved the same problem twice: where do verification emails land during testing? Personal inboxes get polluted with QA mail. +tag aliases get noisy. Internal mail servers don't always receive from production senders. A disposable email service solves it cleanly: you generate addresses on demand, receive into a real internet-facing inbox, and the addresses self-destruct.

Pattern 1: Manual QA

For interactive testing of signup flows: open the temp-mail homepage, copy the address, paste into your signup form, watch the verification email land in the temp inbox. No setup needed. The 10-minute timer aligns with how long a typical signup test takes.

Pattern 2: Programmatic via the Developer API

For automated tests, use the Developer API. The pattern:

1. Get an API key from your developer dashboard.
2. Call POST /api/v1/generate_new_email with X-API-Key header. Receive an address.
3. Trigger the signup flow under test against that address.
4. Poll GET /api/v1/get_emails?address=... until the verification message arrives (or timeout).
5. Extract the verification code/link from the message body and complete the flow.
6. Delete the address with POST /api/v1/delete_address/<id>.

Free-tier API keys allow modest throughput; paid tiers raise the per-minute and per-hour ceilings.

Pattern 3: Cypress / Playwright Integration

In your test framework, wrap the API calls in a helper:

const addr = await tempMail.generate();
await page.fill('#email', addr);
await page.click('#signup');
const code = await tempMail.waitForCode(addr, /\d{6}/);
await page.fill('#otp', code);

Polling cadence: 1 second is usually fine; emails typically land within 2–3 seconds. Implement a 30-second timeout to fail tests fast when the email pipeline is broken.

Pattern 4: Smoke-Testing Production Email Delivery

Schedule a job that generates a disposable address every 15 minutes, sends a test email to it from your production sender, and asserts it arrives within 60 seconds. Page the on-call if it doesn't. This is your end-to-end production email canary.

Patterns to Avoid

• Don't share API keys across CI jobs. One leaked key means the whole org's rate limit is yours to fight over. Issue per-job or per-project keys.
• Don't hammer the polling endpoint. 1 request per second per address is plenty; faster doesn't make the email arrive faster.
• Don't use the same disposable address across two tests. Flakes from stale state are the worst kind.
• Don't forget to delete addresses you're done with. Even though they auto-expire, deleting frees up your active-address quota faster on paid tiers.

Rate Limits

API rate limits are documented at /developer/api/docs and enforced per-key. The defaults are tuned for typical CI workloads (a few hundred address generations per hour, a few thousand polls). If your suite needs more, the Enterprise tier has substantially higher ceilings.

Related Guides

See also: Temporary email for developers blog post and the Developer API reference.