Generate Temporary Email Addresses with Private Inboxes

Generate a temporary email address with an inbox your test can read. MailSlurp gives signup, password-reset and notification checks their own private recipients, so parallel tests can receive real mail without sharing a personal mailbox.

Create inboxes in the dashboard for manual QA or through the API for automated runs. Read messages, links and attachments in code, then check the action the customer needs to complete.

A generated address with a working inbox

Each MailSlurp inbox has an email address that can receive messages. Put that address into your application's signup or reset form and let the application send through its normal email provider. The message is available through the API and dashboard.

For a one-off check, create an inbox, copy its address into the application and inspect the received message. For a repeatable test, create the inbox in setup and wait for the expected sender or subject. The temporary email API quickstart includes a complete Node.js example with a supported matching wait and cleanup.

Unlike a shared public temp-mail page, a private API inbox gives your suite control over which test owns the recipient and its messages. Keep the API key in your secret store and use separate inboxes for tests that run at the same time.

Check more than arrival

A signup test should follow the verification link and check the activated account. A reset test should change the password and confirm the user can sign in. A notification test should check the recipient and the values the customer needs, such as an order reference or attachment.

MailSlurp's wait API can filter messages by subject, sender and time. Combine those rules with a dedicated inbox so yesterday's email cannot pass today's test. Use the Playwright email example for a browser journey or the verification code API for email OTP extraction.

Temporary or persistent inboxes

Choose a temporary inbox for a test that creates and removes its own user. Set an expiry as a fallback and delete the inbox during normal teardown. Remove the application test user separately; deleting a mailbox does not remove that user from your database.

Keep a persistent inbox when the same test identity needs mail across sessions, such as a returning-user or scheduled-notification check. Names and tags help identify its environment and owner. Inbox lifetime controls and message retention are separate settings; select both for the workflow you need.

Use incoming email in your application

Inboxes also support services that process replies and attachments. Configure an email webhook to notify your handler when a message arrives, then retrieve the content by ID. Use the message ID to avoid processing retries twice.

The inbox documentation covers creation options and mailbox controls. For a complete automated test, follow the test email address walkthrough.