๐Ÿงฐ Handy ยท Updated October 8, 2026 ยท 8 min read

Temp Email for QA and App Testing: API, Limits, Pitfalls

Messy inbox Clean tests โš™๏ธ

A temp email inbox is a quick way to exercise the mail-driven parts of a product during testing: sign-up confirmation, verification digits, password reset, magic links and team invitations. GrabCast's Temporary Email tool can be driven by hand in a browser or through a small REST API with no key, which makes it handy for manual QA and light scripted checks. It also has hard limits, a shared public domain, 24-hour retention, no attachments and per-IP rate caps, that make it the wrong choice for load tests or anything involving real customer data. Here is the practical playbook, with the exact numbers from the backend.

๐Ÿ“ฉ Try the Temporary Email tool now โ€” freeOpen โ†’
Whole Temporary Email tool panel in its finished state: opened staging email 'Invitation to QA-Team' with an Accept invite button
The finished result with every setting visible in one view.
๐Ÿ’ก Why testers keep needing fresh mailboxes

Most registration systems reject a second account on the same address, so every test run needs a new one. Gmail plus-tags help, but they pile hundreds of test messages into a personal mailbox and leak a real address into staging databases. A disposable mailbox per run keeps test data isolated, lets a teammate reproduce your exact case, and cleans itself up.

Manual QA with the temp email page

For exploratory testing, open the tool in one tab and your staging build in another. Copy the generated name, register, and watch the message arrive; the page checks every 12 seconds while visible. Open it to inspect the subject line, sender name, plain-text part and HTML rendering. HTML is shown in a sandboxed frame with scripts blocked, which is close to how webmail clients treat it, and a Copy all button grabs the plain text for bug reports.

The automatic digit detector is a useful test in itself. It looks for a 4 to 8 character token after words like code, verification or OTP, then falls back to the first standalone six-digit number. If it highlights the wrong value, real users skimming on a phone may make the same mistake, so consider putting the one-time number on its own line with a clear label.

Scripted checks with the REST API

The same backend exposes plain JSON endpoints at grabcast-api.onrender.com with no authentication. POST /api/tmpmail/new returns a random address plus its retention in hours. GET /api/tmpmail/{address} lists up to 50 messages, newest first, each with id, sender, subject, a 140-character snippet, a read flag and a UTC timestamp. GET /api/tmpmail/{address}/{id} returns the full text and HTML bodies and marks the message read. DELETE on either path removes one message or empties the mailbox.

A typical end-to-end check creates an address, submits your sign-up form with it, polls the list until a message whose subject matches arrives or 90 seconds pass, fetches the body, extracts the link or digits with your own regex, and completes the flow. Give each run a random label; a predictable one like qa-run-7 on a public domain can be read by anyone who guesses it.

API responses arrive as JSON, and the JSON Formatter makes them easy to read. Need unique IDs for test records? The UUID Generator makes them in bulk.

Limits that shape your test plan

Know what this setup cannot tell you before you rely on it. Messages are deleted about 24 hours after arrival, and each mailbox keeps only its 50 newest. More than 30 messages to one mailbox within a minute are dropped as a flood. Attachments are stripped, so invoice PDFs or calendar invites sent as files cannot be verified here. Bodies are trimmed at roughly 100,000 characters of text and 300,000 of HTML. There is no sending, so reply-to handling cannot be exercised.

Test data hygiene and better options at scale

Treat every message as public. Never send production tokens, real customer names, addresses or payment details to a shared throwaway; seed staging with fake data. If your team needs privacy and more headroom, GrabCast supports connecting your own domain through Cloudflare Email Routing and a small Worker, after which that domain's mailboxes are not shared with other visitors, keep messages about 72 hours and hold up to 300 per mailbox.

For continuous integration, a local SMTP catcher is usually the stronger fit. Mailpit, the actively maintained successor to the older MailHog, runs in a container, accepts everything your staging server sends, keeps attachments and offers its own API, all without leaving your network. Hosted sandboxes from email platforms do the same with team features. Use the public throwaway for quick manual checks and demos, and the catcher for anything automated.

Step-by-step

1234
1Open the Temporary Email tool or call POST /api/tmpmail/new to get a random address on the shared domain for this run.
Custom address qa-run-0417@tempinbox.example for a staging test run, with Copy, Custom and Protect buttons and an empty inbox
Take a throwaway address for this run, or call the API for one.
2Submit the sign-up, verification, reset or invite form in your staging build using that address and only fake test data.
3Poll GET /api/tmpmail/{address} every 10 to 15 seconds for up to about 90 seconds, then fetch the message by id to read its text and HTML.
Inbox counter at 3 listing staging mails: Verify your email, Reset your password and an invitation to QA-Team
The sign-up, reset and invite mails all arrive in one inbox.
4Extract the link or digits, finish the flow, assert the result, and DELETE the mailbox so nothing lingers for the rest of the 24 hours.
Opened staging email 'Verify your email' with detected Verification code 739214 and a Copy code button
Pull the digits out of the message to finish the flow under test.

Common mistakes to avoid

โš ๏ธHammering the list endpoint in a loop and tripping the 120 requests per minute per IP limit mid-run.
โš ๏ธUsing predictable labels such as test1 on a public domain, so anyone can read your staging links.
โš ๏ธTrying to verify PDF invoices or calendar attachments, which are stripped before storage.
โš ๏ธPointing load or volume tests at a shared throwaway domain instead of a local SMTP catcher.

Pro tips

โœ“Log the generated address in your test report so a teammate can open the same mailbox within the day.
โœ“Match messages by subject and timestamp, not position, because several may arrive during one run.
โœ“Whitelist the throwaway domain only in staging configuration, never in production validation rules.
โœ“Keep one-time digits on their own labeled line in your templates; it helps both detectors and humans.
โœ“Move to your own connected domain or a local catcher once scripted runs exceed a few dozen a day.

Frequently asked questions

Does the temp email API need a key?

No. The endpoints need no sign-up; instead they are rate-limited per IP instead: 20 new addresses a minute and 120 a day, 120 reads a minute and 60 deletes a minute.

Can I receive attachments during testing?

No. The backend stores the text and HTML parts and drops attachments, so test file delivery with a local SMTP catcher.

How long can a test mailbox be used?

The address works indefinitely, but each message is removed about 24 hours after arrival and only the 50 newest are kept.

Can I test outgoing replies?

No. The service is receive-only and has no sending capability.

Is it safe for staging credentials?

Only for throwaway test data. The shared domain is public by name, so never send production secrets or real customer information to it.

๐Ÿ“Œ Bottom line

A shared throwaway domain is a fast, keyless way to click through mail-driven flows by hand or in light scripts, within 24-hour retention, 50-message and per-IP limits; keep real data out of it, and move automated suites to your own domain or a local catcher like Mailpit.

Open the Temporary Email tool โ†’

Related guides

Browse more: all all guides ยท the Temporary Email tool