Test magic-link login with Robot Framework and an inbox API

Magic-link tests often fail for a simple reason: the test guesses how long email delivery will take. A short delay misses a slow message. A long one wastes time on every run. A better Robot Framework email-testing flow waits for the expected message through a test email API, extracts the link, checks where it points, and then uses it in the application under test.

InboxRhino provides receive-only MX inboxes on test.inboxrhino.in. Its API can wait up to 180 seconds for a message and filter by subject or sender. The service cannot send, reply to, or forward email, so your application still has to generate the sign-in message.

Set up one inbox per test flow

Keep the inbox address separate from the account’s ordinary email address. Create an inbox through the API before the test, then use the returned address when registering or requesting a sign-in link in your application. The create request is a POST to https://api.inboxrhino.in/v1/inboxes with a bearer API key in the Authorization header.

In Robot Framework, use your team’s HTTP-library keywords to make that request and retain the returned inbox ID and address as test variables. Keep the API key in an environment variable or your CI secret store; do not put it in the suite file or print it in test output. InboxRhino’s documentation includes Playwright integration examples, but the same REST sequence can be called from a Robot suite.

Use a distinct inbox for each parallel test, or otherwise ensure two tests cannot consume each other’s messages. An inbox ID identifies where the API should look; the unique address is what your application should send the magic link to.

Wait for the message instead of sleeping

After the application has accepted the login request, ask the API for the matching email. The messages endpoint is /v1/inboxes/{id}/messages. Pass wait_seconds=180, limit=1, and include=content; add a subject or sender filter where your application provides a stable value. For example, the API quickstart uses a subject filter of Verify. Choose a filter specific enough to avoid matching unrelated mail.

In Robot, make this request a keyword such as “Wait For Sign-in Email.” Have it return the first matching message only after checking that the response contains a message. If the wait expires, fail with the inbox ID and the filter used, but do not include the full message body or a login token in the failure text. The API’s wait is bounded at 180 seconds; choose a shorter limit if your test environment has a known delivery target.

Check the message subject and sender before parsing its content. Then read the parsed body returned when content is requested. Confirm the exact response field names against the API documentation rather than assuming the HTML and plain-text bodies share a field. A related walkthrough shows the same wait-for-message pattern for signup verification in a Postman collection.

Extract the URL as untrusted input

Do not grab the first string that looks like a URL and navigate to it. Email content can contain tracking links, support links, or unrelated addresses. Parse the message body’s links with an HTML parser, then select the application’s sign-in route using rules you control: the expected HTTPS host and the expected path pattern.

Before using the URL, assert that it has the correct scheme, hostname, and route. Reject unexpected hosts, malformed links, and messages with no matching sign-in link. Keep the complete URL out of logs and screenshots: a magic link commonly contains a credential that can grant access to the test account. Avoid printing the message body when a test fails.

Robot Framework can pass the validated URL to the browser or HTTP steps already used by your suite. Open it in the test session, then assert a meaningful authenticated state, such as the expected account page or signed-in indicator. A successful email delivery is not proof that authentication worked; the final assertion must verify the application accepted the link.

Make failures diagnosable

Separate failures into stages: the application did not accept the login request, no matching email arrived, the message lacked a valid link, or the link did not authenticate the session. That distinction narrows debugging without exposing tokens. For visual inspection, InboxRhino also has a sandboxed email viewer that blocks scripts, forms, popups, and remote images. It can help a QA practitioner inspect HTML without treating the message as executable page content.

InboxRhino retains emails for 30 days before deletion, so do not use test inboxes as an archive. For a small flow, the free tier includes 11 active inboxes, 33 inbound emails per month, and one user. Budget the message quota around retries and parallel runs. The important test design choice is still the same: wait for a narrowly matched message, validate its destination, and keep the one-time URL out of routine logs.