Playwright email testing

Temporary inboxes for end-to-end email verification.

mailfab fits the shape of real Playwright tests: create a mailbox, trigger the product flow, wait for the inbound message, read the content, and clean up. No SDK claims, no magic parser assumptions, just predictable email automation primitives.

Create a fresh inbox per test

Use a signed-in account with API keys or the mailfab CLI to create an address for the scenario under test.

Run the browser action

Let Playwright submit the signup, login, invite, or password reset form that sends the verification message.

Wait, read, and assert

Poll with the CLI or API, read the message body, and let your test extract the link or code it expects.

A clean Playwright shape

test("verifies signup email", async ({ page }) => {
  const inbox = await createMailfabInbox()

  await page.goto("/signup")
  await page.getByLabel("Email").fill(inbox.address)
  await page.getByRole("button", { name: "Create account" }).click()

  const message = await waitForMailfabMessage(inbox.id)
  expect(message.subject).toContain("Verify")
})

The helper names above belong to your test suite. mailfab provides the authenticated inbox, polling, reading, and deletion primitives those helpers can call.

Operational boundaries

Use the right inbox mode for the job.

Guest inboxes are scoped to the current browser session, which makes them convenient for manual checks but not a durable shared test fixture.

API keys, CLI usage, sending, webhooks, and share links are signed-in workflows.

Keep your Playwright code responsible for parsing message content, link selection, and product-specific assertions.

From manual checks to CI-ready flows.

Start with a browser-scoped guest inbox when you need a fast manual address. Move to signed-in mailboxes when Playwright, CI, webhooks, or team-visible records need stable authenticated access.

API key auth
CLI polling
Message reads