MailSlurp logo

product

Email Sandbox API for safe SMTP testing

Capture SMTP traffic from staging, dev, and QA environments. Inspect messages, validate content, check deliverability signals, and automate release checks with MailSlurp.

MailSlurp Email Sandbox is a controlled environment for testing email flows before production delivery, without letting staging or QA traffic reach real customers.

When teams adopt an email sandbox

  • They need to test signup, reset, or magic-link journeys safely.
  • They need deterministic message checks in CI instead of manual inbox review.
  • They need richer diagnostics than local fake SMTP servers usually provide.
  • They want one platform for test capture now and production-adjacent validation later.

Sandbox architecture in practice

  1. Create dedicated inboxes by test run, branch, or environment.
  2. Route app traffic to sandbox SMTP/API endpoints.
  3. Wait for matching messages and validate expected outcomes.
  4. Inspect headers/content when assertions fail.
  5. Promote changes only when checks pass.
const sent = await mailslurp.inboxController.sendEmailAndConfirm({
    inboxId: mailTrap.id,
    sendEmailOptions: {
        to: [customer.emailAddress],
        subject: 'Test email',
        body: 'This is using a virtual inbox and will not be sent to real customers',
    },
});
expect(sent.to).toContain(customer.emailAddress);
expect(sent.virtualSend).toBeTruthy();

SMTP capture to API testing path

Use this path when a staging app already sends through SMTP and the team needs stronger release evidence:

  1. Capture staging email in MailSlurp Email Sandbox instead of sending to customers or shared team inboxes.
  2. Inspect the subject, sender, body, links, attachments, and headers from the received message.
  3. Assert the message by API in the same test run that triggered the app action.
  4. Trigger Email webhooks when received messages should start downstream checks or parser workflows.
  5. Promote stable checks into CI with Email testing API and Email integration testing.

For password reset, OTP, invite, billing, and notification flows, keep the captured message ID with the test result so failures are reproducible.

How do I use an email sandbox with Playwright?

Use Playwright for the browser journey and MailSlurp Email Sandbox for the message layer. Create a private inbox for the test, submit its address through the browser, wait for the expected email using a bounded subject or content match, extract the delivered link or OTP, and finish the journey in the same Playwright context.

For parallel CI, create one inbox per worker and delete it after the run. That prevents a message from another test satisfying the assertion and avoids the stale-email failures common with shared Gmail accounts. The Playwright email testing guide explains the pattern, the complete Playwright fake-email example shows the implementation, and the email testing API provides the reusable inbox, wait, and message-inspection controls.

How do I use an email sandbox with Cypress?

Use Cypress for the browser journey and MailSlurp Email Sandbox for the captured message. Install the official cypress-mailslurp plugin, create an inbox inside the test, submit its address in the app, and wait for the current run's subject, sender, or unique token before extracting the delivered link or OTP.

Give every parallel worker its own inbox and delete it in afterEach, including after a failed assertion. That prevents cross-test message consumption and stale-email matches. The Cypress email testing guide shows the production pattern, the complete Cypress plugin example covers setup, and the email testing API provides the underlying inbox, wait, and inspection controls.

What to verify before release

  • Recipient and sender correctness.
  • Link and code extraction behavior.
  • HTML/text body integrity and required components.
  • Header/authentication sanity checks.
  • Attachment presence and MIME correctness.

For authentication and deliverability checks, pair sandbox tests with:

Local fake SMTP vs cloud sandbox

Local tools are useful for quick template previews. Teams usually outgrow them when they need parallel test execution, deterministic wait APIs, and organization-level auditability. MailSlurp supports that transition while keeping the core test workflow deterministic and auditable.

Use the SMTP tester for transport diagnostics, the fake SMTP server guide for safe capture setup, and this sandbox page when the workflow needs repeatable API assertions.

From sandbox capture to production-style operations

Teams often start with safe capture, then formalize ownership and event handling:

FAQ

Can I use Email Sandbox with any framework?

Yes. If your stack can call SMTP or HTTP APIs, you can use MailSlurp.

Can Playwright read email from the sandbox?

Yes. Playwright drives the application while mailslurp-client creates the inbox, waits for the matching message, and returns its body, links, and metadata to the same test. No separate Playwright plugin is required.

Can Cypress read email from the sandbox?

Yes. The official cypress-mailslurp plugin exposes the standard MailSlurp client through cy.mailslurp(), so the test can create an inbox, wait for a matching message, inspect its body or links, and delete the inbox during cleanup.

Is this only for engineering teams?

QA, product, and support teams can inspect and validate messages in shared workspaces while engineering keeps the assertions in code.

Does this replace production delivery infrastructure?

Email Sandbox focuses on safe testing and pre-release verification. Use it alongside production send systems when the team needs strong message evidence before anything customer-facing goes live.