Tempx for QA teams
Every non-trivial app gates its critical flows behind email: signup verification, one-time passwords, password resets, export notifications. The usual workarounds — a shared Gmail inbox with filters, or skipping the assertion entirely — leave the most fragile part of the flow untested. Tempx gives each test its own disposable inbox with a free JSON API, so the email step becomes an ordinary assertion.
test submits the form → app sends mail → Tempx inbox receives it → test polls the API → assert on the message
Flows this covers
- Signup verification — assert the mail arrives within your SLA, from the right sender, with a working link or code.
- OTP / 2FA login — extract the 6-digit code from the message preview and feed it back into the UI; the whole loop stays automated.
- Password reset — request a reset for a disposable address, pull the token, complete the flow end to end.
- Notification content — template regressions (wrong name, broken variable, missing localization) are caught by asserting on subject and text.
The shape of a test
Whatever the framework, the pattern is the same three moves. A 45-second timeout and a 2-second poll covers real-world delivery:
// 1. unique inbox for this run
const addr = "qa-" + process.env.CI_JOB_ID + "-signup@tempx.uk";
// 2. drive the UI with the address (Playwright/Selenium/etc.)
// 3. wait for the mail and assert
const msg = await waitForMessage(addr, {
timeoutMs: 45000,
match: (m) => /verify/i.test(m.subject),
});
expect(msg.from).toContain("noreply@example.com");The Playwright, Cypress and Selenium integrations each ship a complete, copy-pasteable version of this — helper included.
Parallel runs and CI hygiene
- One address per test. Derive names from job ID plus test key; parallel jobs can never see each other's mail.
- No credentials in CI. Named-inbox reads need no token, so there is nothing to leak in logs.
- Nothing to tear down. Inboxes and mail delete themselves; the 7-day retention on named inboxes is generous for debugging a failed run's artifacts.
Design around the limits
Two numbers matter when you build the harness. Inbox reads allow 240 requests/minute — a 2-second poll per test is comfortable even with a dozen parallel workers (stagger or share a poller beyond that). And the preview is 140 characters of the text part — enough for codes and most links, but if your verification token sits deep in an HTML template, fetch the full body via MCP or assert on the preview plus subject instead.
Make the email step a real assertion
Pick an address, wire one poll, and your flakiest test step becomes the most deterministic one.
Open an inbox