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.
Playwright email testing
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.
Use a signed-in account with API keys or the mailfab CLI to create an address for the scenario under test.
Let Playwright submit the signup, login, invite, or password reset form that sends the verification message.
Poll with the CLI or API, read the message body, and let your test extract the link or code it expects.
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
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.
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.