MailSlurp lets you create inboxes on demand from the API, SDKs, or dashboard. Most teams use this to generate clean test identities for each test run, isolate environments, and avoid cross-test mailbox pollution.

What this solves

Creating inboxes programmatically helps you:

  • Run deterministic signup, verification, and password-reset tests.
  • Create one inbox per test or per CI job for easier debugging.
  • Avoid exposing personal email addresses in QA workflows.
  • Control mailbox lifecycle with expiration and cleanup policies.

Pattern 1: create a random inbox

The default call returns a unique address on a MailSlurp-managed domain:

This is usually the best choice for high-volume automation because every run starts with a clean mailbox.

Pattern 2: create an expiring inbox

For short-lived QA jobs, set an expiration so stale inboxes are removed automatically.

Use this for:

  • Branch-preview environments
  • One-time UAT sessions
  • Security-sensitive workflows where retention should be limited

Pattern 3: create a specific address on your domain

If you need predictable addressing, pass an explicit value (for example ).

This requires a verified domain in MailSlurp. See custom domain setup.

Use this pattern when:

  • You test strict sender/recipient allowlists.
  • External systems can only send to known static addresses.
  • You need audit-friendly mailbox naming per workflow.

Test architecture recommendations

Avoid sharing a single inbox across your entire suite. A better model is:

  1. Create inbox per test case or per worker.
  2. Trigger application action (signup, reset, invite, OTP).
  3. Wait for matching message criteria.
  4. Assert subject/body/links/codes.
  5. Delete inbox or rely on expiration policy.

For receive-side waits and assertions, use receiving emails in code.

Lifecycle and cleanup

Use explicit cleanup for long-running test projects:

  • Delete inboxes at the end of each run when possible.
  • Use expirations for backup cleanup when test jobs fail early.
  • Add naming conventions or tags so orphaned resources are easy to audit.

If you manage teams, pair this with organization controls and API key scoping.

Security and governance

Inbox provisioning is infrastructure, not just test data. Recommended controls:

  • Separate API keys by environment.
  • Avoid reusing production keys in CI.
  • Keep retention policies aligned with compliance requirements.
  • Route high-risk events to webhook-driven monitoring.

See API key setup and email webhooks.

Next steps