KC02 · Use case 02 · Developer workbench
Temporary email for developers: give every manual test a clean receiving edge.
Your application says it sent the email. The queue says the job ran. The template looks fine in preview. None of that proves the user journey works. Sometimes you need a fresh address on the other side and a human watching what actually arrives.
$ test email-flow --manual
recipient = fresh_inbox()
trigger = signup()
message = wait_for_mail()
action = use_code_or_link(message)
assert(final_state == expected)
Use it for manual QA
Fresh signup, verification, OTP, magic-link, reset and onboarding checks where a developer or tester is actually reading the inbox.
Do not pretend it is a CI API
MailOnce's current browser workflow is not presented here as a public programmatic mailbox API. Automated suites need tooling built for deterministic provisioning and retrieval.
Test the boundary you care about
A temporary inbox is useful when you want the real receiving boundary, not when a unit test or local mail capture already answers the question.
The workbench question
What are you trying to prove?
“Test email” is too broad. Choose the receiving boundary only after you know the failure you want the test to expose.
Start with application logs, queue state or a local capture tool when internet delivery is irrelevant.
A temporary inbox becomes useful: new address, real receiving path, visible user-facing message.
Exercise the public action, then assert the resulting account or session state.
Use an email-testing API or controlled test infrastructure rather than automating a browser inbox that exposes no supported API contract.
Manual email-testing loop
Six moves. One attributable message.
Provision
Create one fresh recipient for the scenario you are about to run.
Trigger
Perform one known action: signup, resend, magic-link request, OTP request or password reset.
Observe
Match the message to this recipient and this attempt before trusting its code or link.
Exercise
Use the same OTP, link or action a real user would receive.
Assert
Check the application state after the email action. Arrival alone is not the finish line.
Discard
Do not let unrelated future tests inherit ambiguous mail or identity state.
Five jobs on the bench
A developer inbox earns its place when the email is part of product behavior.
Signup & email verification
Create an identity the environment has not seen, submit the address, inspect the verification message, use its current action, then prove the account reaches the verified state.
OTP email testing
Trigger one code at a time. Match it to the current request, use it before expiry, and do not let an older code produce a false pass after a resend.
Magic-link login
Treat the email as an authentication handoff. Check the destination host and route, use the current link, then inspect the session the application creates.
Password-reset email
Start with a known test account, request recovery, use the intended reset action and verify the credential transition—not merely the existence of a reset email.
Transactional UI checks
Inspect sender, recipient, subject, locale, text, HTML and links as a recipient sees them, while remembering that rendering correctness and business-state correctness are separate assertions.
Fresh inboxes improve attribution
Reuse one mailbox for ten signup attempts and the inbox becomes another piece of shared test state. Old links look current. Two identical subjects compete for attention. A resend creates a second plausible OTP. A fresh recipient shrinks the evidence set: this inbox exists for this scenario.
Fresh does not mean deterministic
Internet email is asynchronous. A clean address tells you who owns the message; it does not guarantee when delivery happens. Avoid turning a slow sender into a false product conclusion, and do not keep clicking Resend until several valid-looking messages exist.
Tool choice
Temporary inbox, local capture, or automation platform?
Staging discipline
A disposable inbox is not permission to put production secrets into test mail.
Use synthetic accounts and non-sensitive fixtures. Keep live credentials, customer data and private production material out of temporary testing workflows. If a flow is security-sensitive or regulated, use infrastructure your organization controls and has approved for that environment.
Message arrived
Proves only that the observed receiving path delivered a message to this recipient.
Message is correct
Adds sender, subject, content, locale and action payload to the evidence.
User journey works
Requires using the action and asserting the application state the email was supposed to change.
Where KC03 takes over
This page chooses the workflow. The Developer Knowledge Center tests the edge cases.
Use this page when the question is “how can a developer use a temporary inbox?” Move into the Developer & QA articles when the question becomes specific: verification state, OTP resend and expiry, magic-link sessions, password-reset security, parallel E2E isolation, or polling versus realtime observation.
Open Developer & QA articlesNeed a clean recipient for the next manual test?
Create a MailOnce inbox, trigger one email-producing action, and keep the evidence attributable to that test.