Email Testing API for Developers

A signup email test needs to follow the customer past "Email sent". The message must arrive at the right address, its verification link must point to the right application, and using that link must verify the intended account.

Repeating those checks in a shared mailbox makes parallel tests hard to trust. MailSlurp is an email testing platform that gives each test its own inbox and APIs for waiting for messages and extracting their contents. This reference shows how to add that email check to a TypeScript test; the email testing API overview explains the broader features if you are still evaluating the product.

Configure the SDK in your test project

Use a Node.js TypeScript test project with Node types available, and install the MailSlurp SDK:

npm install mailslurp-client

Store your API key in the test environment as MAILSLURP_API_KEY, then create the client in your test setup. Keep the key out of browser code and source control.

import { MailSlurp } from "mailslurp-client";

const apiKey = process.env.MAILSLURP_API_KEY;
if (!apiKey) throw new Error("Set MAILSLURP_API_KEY");

const mailslurp = new MailSlurp({ apiKey });

The helper below accepts this configured client, your application's origin, and two functions supplied by your test suite:

• requestVerification(emailAddress) submits signup or requests verification for that exact address. It must await the application action and reject if the request fails.
• assertAccountVerified(link, emailAddress) uses the delivered link through your application's normal verification flow, then asserts that the account for emailAddress is verified. It must reject on a failed action or assertion; merely receiving an HTTP response or opening a page is insufficient.

These are application adapters that you implement, not MailSlurp SDK methods. The helper belongs inside a test with those adapters; it is not a standalone signup application. Keep any required browser session in the adapters and remove the application test account in your suite's teardown.

Wait for the verification email and complete signup

This example expects a message with the exact subject Verify your email and one HTML link selected by a.verify-email. That link must use your application's origin and the /verify path. Adapt the subject, selector and path to your app before calling the helper.

import assert from "node:assert/strict";
import {
  MailSlurp,
  MatchOptionFieldEnum,
  MatchOptionShouldEnum,
} from "mailslurp-client";

type SignupActions = {
  requestVerification: (emailAddress: string) => Promise<void>;
  assertAccountVerified: (link: URL, emailAddress: string) => Promise<void>;
};

export async function testSignupEmail(
  mailslurp: MailSlurp,
  appOrigin: string,
  actions: SignupActions,
) {
  const inbox = await mailslurp.createInboxWithOptions({ expiresIn: 600_000 });
  try {
    const since = new Date();
    await actions.requestVerification(inbox.emailAddress);
    const email = await mailslurp.waitController.waitForMatchingFirstEmail({
      inboxId: inbox.id,
      since,
      timeout: 60_000,
      unreadOnly: false,
      matchOptions: {
        matches: [{
          field: MatchOptionFieldEnum.SUBJECT,
          should: MatchOptionShouldEnum.EQUAL,
          value: "Verify your email",
        }],
      },
    });
    const { links } = await mailslurp.emailController.getEmailLinks({
      emailId: email.id,
      selector: "a.verify-email",
    });
    assert.equal(links.length, 1, "Expected one verification link");
    const link = new URL(links[0]);
    assert.equal(link.origin, new URL(appOrigin).origin, "Wrong application origin");
    assert.equal(link.pathname, "/verify", "Wrong verification path");
    await actions.assertAccountVerified(link, inbox.emailAddress);
  } finally {
    await mailslurp.inboxController.deleteInbox({ inboxId: inbox.id });
  }
}

Call testSignupEmail(mailslurp, appOrigin, { requestVerification, assertAccountVerified }) from your test and await its promise. Set the overall test timeout long enough to cover the 60-second email wait plus signup, verification and cleanup.

Keep the test tied to the current signup

The helper records since immediately before triggering the application action. It then waits in this test's inbox for the exact subject, using the SDK's exported matching enums. unreadOnly: false keeps the result independent of whether someone has opened the message in the dashboard.

Selecting exactly one verification link avoids accidentally following the template's logo or help link. The origin and path assertions catch a link to the wrong environment or page before the application adapter uses it. The final account assertion is what establishes successful verification; receipt and link extraction alone cannot do that.

The finally block attempts to delete the inbox after success or failure. The ten-minute expiry is a fallback for an interrupted test process. If the wait times out, check that the app received the new address, sent the expected subject and used the intended email provider configuration. If link validation fails, inspect the delivered template and its environment settings before changing the assertion.

Use the email testing API with Playwright

In Playwright, implement requestVerification with the signup form actions and assertAccountVerified with navigation and an account-specific assertion in the same browser context. The MailSlurp SDK handles the inbox alongside Playwright; no separate MailSlurp plugin is required.

Use the Playwright email testing guide for verification, OTP and notification checks. The complete Playwright example provides a runnable browser integration to adapt to your application.

Extend the check to other account flows

Once signup works, add tests for the verification rules your app promises, such as rejecting expired links or preventing a link from verifying another account. Those outcomes need application assertions of their own.

For password resets, use the received link to set a new password, then sign in with it. If your application invalidates earlier reset tokens, request two emails and confirm that the older token is rejected. The Playwright guide's parallel reset example develops this workflow further.

For billing notifications, assert the expected recipient, invoice details and attachments. In a multi-tenant application, use separate test accounts and inboxes to check that a message contains only the intended tenant's data.

Pair API checks with deliverability diagnostics

Receiving a message in a test inbox answers whether that application flow produced usable email. To check where a campaign lands at other providers, run an inbox placement test. Use domain monitoring to investigate sender-authentication and DNS changes; those findings complement the account test and do not prove inbox placement.