Disposable Email for Developers: Testing Sign-Up and Reset Flows
Email is often the awkward part of checking a sign-up flow. Reusing your personal address mixes test messages with real mail, while repeatedly creating permanent accounts adds cleanup work. A temporary inbox can help with an occasional manual check of an application you own or are authorised to test. Use synthetic data and a disposable test account whose loss would not matter.
Choose the right receiving tool
Start with the question you need to answer. A manual check can establish whether one particular message arrived, whether its subject makes sense and whether the intended code appears in its text. It cannot establish delivery to every email provider, prove that a message avoids spam folders elsewhere or measure how the layout behaves in other mail clients. Keep those separate test cases.
For TempMailPortal, use the official website or Android app. The service is receive-only: your own application or mail provider must send the test message. New random inboxes use private access credentials; knowing the recipient address alone does not grant access. Treat the resulting mailbox as short-lived test storage, never as a destination for customer records, production secrets or recovery links for an account you care about.
What changed for developer access
The older public API examples on this page are no longer a supported integration path. Do not copy mailbox credentials out of the website into a test runner, reuse legacy API keys or build a CI dependency on internal endpoints. The current access policy describes the supported website and Android access paths and their allowances. A successful request to a compatibility endpoint does not make that endpoint a supported public developer API.
The Android app starts with one active guest inbox without Google sign-in. Optional Google sign-in raises the allowance to five active inboxes. Daily creation, request and incoming-mail limits still apply; adding a device or upgrading a guest does not reset usage. The account dashboard provides usage and deletion controls, not a message reader or developer credentials.
A practical manual email check
- Create the inbox first. Open the website or Android app and create a fresh random inbox. Choose a message lifetime that gives you time to finish the check. Available lifetimes for new private inboxes are 10 minutes, one hour and 24 hours.
- Prepare your own test case. Copy the address into your authorised test environment. Use a clearly labelled sample account and a unique marker in the message so you can distinguish this run from earlier attempts.
- Trigger one message. Exercise the sign-up or test-account reset flow you control. Confirm that your sending system accepted the request; do not repeatedly submit the form simply because the receiving inbox is still empty.
- Read the result. Refresh the inbox when needed, then check the sender, subject and expected text. Compare any suggested verification code with the message itself. A detected code is a convenience, not proof that the sender is authentic.
- Check the application outcome. Complete the test in your own environment and verify its expected state. Keep the distinction between receiving a message and successfully completing your application's flow.
- Clean up. Clear your test messages with the inbox controls and remove the sample account from your own system. Changing or forgetting a saved address does not delete its server-side messages. Do not keep secrets in screenshots or logs.
Message retention and address access are different. Private address credentials last 30 days, while messages expire after the selected lifetime, at most 24 hours. Saving an address or starring a message does not extend its content's lifetime. A sender's code may expire sooner still.
Diagnose missing mail without repeating the whole test
Work outward from the system you control. Record whether your mail provider accepted the send request and returned a message identifier. Then inspect its delivery or bounce event for the exact test recipient. A successful send API response often means queued, not delivered to the receiving server. More inbox refreshes cannot repair a misspelled recipient or a rejected send.
If the provider reports delivery, compare the recipient with the inbox currently open and check whether the selected retention period has already elapsed. Switching addresses can leave you looking at an empty mailbox while the original one received the test. Check any displayed usage or rate-limit warning and wait for the stated reset instead of retrying in parallel.
Keep a useful test record: date, app or browser version, test-run marker, expected result, observed result and sender-side status. Redact recipient details, mailbox credentials, codes and links before sharing diagnostics. A missing message alone does not identify which hop failed, and one successful delivery does not establish an uptime or latency guarantee.
When you need automated tests
For CI, recurring regression suites or tests that need predictable retention, choose a receiving system designed for automation and under your team's control. It should provide a documented API, isolated test data, bounded waits, explicit cleanup and capacity suitable for your workload. TempMailPortal's consumer inbox is not offered as that public integration.
A domain and catch-all owned by your team is one possible receiving architecture. Cloudflare's Email Worker reference describes processing incoming mail with an email() handler. That documentation explains an implementation building block; it does not grant access to TempMailPortal's internal service. The mail-delivery guide explains the general receiving path.
In your own automated environment, distinguish test runs with unique markers, use inert links to the test system and remove data after the assertion. Bound retries and report a meaningful timeout. Keep production credentials out of fixtures. A test suite should fail clearly when its mail dependency is unavailable instead of creating more accounts or polling indefinitely.
What this guide establishes
This update reconciles the manual workflow with the current source, access policy and Android 1.4.4 listing. It does not claim that a new external-delivery experiment was run. The August and September API timing examples described an older public-access model and have been removed from the current instructions. They are not evidence for today's supported integrations.
Questions developers usually ask
- Can TempMailPortal send or reply? No. It receives incoming mail. Send test messages through a system you control.
- Can I use the old API script in CI? No supported public developer integration is offered. Use a documented receiving service or your own test infrastructure.
- Does the browser inbox sync to Android? Browser guest inboxes do not automatically transfer into Android. Start the check on the surface you intend to use; Android device pairing requires the same signed-in account on both devices.
- Can I inspect attachments? Android can preview supported retained image and text files or save available files, subject to size, expiry and usage limits. The website shows filenames only. Use harmless fixtures and keep files you need in your own test system.