Automating magic link sign-in tests with Playwright and InboxRhino

The Flakiness of Passwordless Sign-In Tests

Passwordless authentication via email magic links eliminates user passwords, but it adds friction to browser automation. QA teams running Playwright test suites frequently encounter flaky failures when verifying sign-in flows. The standard workaround relies on fixed delay timers like arbitrary sleep timeouts or custom polling loops that hit a local database. Fixed delays waste pipeline execution time, while database inspection bypasses actual email delivery validation.

Testing email delivery requires verifying that the mail transfer agent handles outbound routing, that headers land intact, and that the email contains a functional magic link URL. Local SMTP containers simulate local delivery, but they fail to catch DNS misconfigurations or upstream queue delays in staging environments. For teams comparing architecture choices, our overview of public MX versus local SMTP sandboxes in staging tests breaks down deliverability trade-offs in continuous integration pipelines.

Step 1: Provisioning a Real Test Inbox via API

To run an isolated test, create a temporary email address before launching the browser context. Sending a POST request to the InboxRhino inbox endpoint yields a fresh real address on the test.inboxrhino.in domain. Because these addresses route through real MX records, your application transaction system delivers mail through its normal outbound email provider setup.

In Playwright, you can provision this address inside a hook or directly at the start of the test function. The API response returns a unique inbox identifier along with the email address string. Storing this address in a test variable allows Playwright to fill out your app sign-in form dynamically.

Step 2: Triggering the Magic Link Request

With an active inbox address created, instruct Playwright to navigate to your sign-in page. Fill the email input element with the newly generated inbox address, click the submit button, and assert that the user interface displays the expected confirmation message. This step validates that your front-end application successfully passes payload data to your authentication backend.

Step 3: Long-Polling for Incoming Email

Instead of writing a recursive retry loop that hammers an API every few seconds, send a single HTTP GET request configured with a long-polling query parameter. Setting wait_seconds=180 causes the InboxRhino API to hold the connection open until the message arrives or the 180-second timeout period elapses.

This long-polling strategy eliminates retry overhead and simplifies Playwright test logic. Similar to how we structure long-polling for reset links in our guide on automating password reset tests with long-polling email APIs, the test script suspends execution at the API request line until the incoming MX delivery completes.

The API payload includes the parsed message content, raw HTML body, subject header, and sender details once delivery finishes.

Step 4: Extracting the Target URL and Authenticating

Once the long-polling request returns the email payload, extract the magic link URL from the message HTML using standard string matching or regular expressions. A pattern targeting your application authentication path or token parameter extracts the raw target URL cleanly.

Pass that extracted URL straight into Playwright to navigate the page directly to the authentication callback. The browser processes the token, sets the session cookie, and lands on the authenticated dashboard page. Asserting on a post-login DOM element completes end-to-end verification without manual intervention.

Visual Inspection and Security Sandboxing

Automated assertion checks pass or fail on token extraction, but manual triage is often necessary when visual regressions or broken layouts occur in staging emails. Opening incoming message bodies in unsecured internal viewers poses security risks.

InboxRhino includes a built-in web viewer console designed for manual visual inspection. The viewer operates inside a strict sandbox that blocks remote images, executable scripts, form submissions, and popups. As covered in our analysis of why unsandboxed HTML in email test consoles creates quiet security leaks, isolating untrusted staging payloads protects developer workstations and internal consoles from cross-site scripting vulnerabilities.

Trade-Offs, Quotas, and Limits

Implementing temporary API inboxes introduces clear operational boundaries that teams must evaluate during workflow design:

• Receive-Only Architecture: InboxRhino addresses are strictly receive-only. Test scripts cannot send outbound emails, reply to messages, or forward email payloads to external endpoints.
• Retention Window: Messages, headers, and attachments are stored for 30 days before automatic deletion. The inbox address remains available until explicitly deleted.
• Free Tier Quotas: The live free tier provides 11 active inboxes, 33 inbound emails per UTC calendar month, and 1 organization user. This allocation supports local developer testing and initial workflow prototyping.
• Paid Plans Status: Paid INR plans (Starter, Growth, Scale) are marked as coming soon for teams requiring higher message limits and multi-user seats.

By replacing arbitrary timeouts with single-request long-polling, teams eliminate test flakiness in Playwright while verifying true end-to-end deliverability.