Testing OTP and magic link flows without writing Playwright

Because most React and Vue OTP UIs do not bind onChange to each input independently. They listen for a single onPaste event on a parent wrapper, split the pasted string across the cells, and only then move focus to the submit button. When a Playwright script calls page.locator('input').nth(0).fill('1'), nth(1).fill('2'), and so on, you trip the per-input keystroke handler that some libraries also wire up, and the values race the focus-moving logic. The result is that cells visually contain digits but the form's internal state is stale, the submit button is disabled, or the verify call fires with a four-digit code instead of six. The fix is not 'type more carefully', it is 'paste once into the parent', which is what the application is actually built to handle.

Browsers fire a paste event with a clipboardData property of type DataTransfer that the application reads with event.clipboardData.getData('text/plain'). Most split-input OTP UIs listen for that exact shape on a wrapper element. The trick is to construct the same shape in JavaScript without actually using the system clipboard: const dt = new DataTransfer(); dt.setData('text/plain', '123456'); element.dispatchEvent(new ClipboardEvent('paste', { clipboardData: dt, bubbles: true, cancelable: true })). Because the event bubbles and looks identical to a real paste, the application's handler runs unmodified, splits the digits across the cells, advances focus, and enables submit. The Assrt agent runs this exact expression through its evaluate tool. The recipe is committed in the system prompt at agent.ts lines 234-236 so the model produces the same code every run instead of inventing variations.

The DisposableEmail class lives at /Users/matthewdi/assrt-mcp/src/core/email.ts (130 lines). Each call to DisposableEmail.create() POSTs to https://api.internal.temp-mail.io/api/v3/email/new with a min_name_length and max_name_length of 10, returning a fresh address and a per-inbox token. The address is unique because the local-part is a random 10-character string out of 36^10 possibilities; the token gates polling for that one inbox. Reusing an inbox across tests is a known source of flakiness in this domain (a previous run's verification email matches the current run's regex). Assrt sidesteps the problem by creating a new inbox for each scenario, which is one of the reasons the create_temp_email tool exists separately from check_email_inbox.

The waitForVerificationCode method at email.ts lines 82-129 runs an ordered list of seven patterns against the message body. The first six are anchored to keywords: code, Code, CODE, verification, OTP, otp, pin, PIN, Pin. The seventh, eighth, and ninth are bare-digit fallbacks at six, four, and eight digits in that order. The order matters: 'Your code is 482910' matches the keyword pattern first, but a body that just contains a six-digit token still resolves through the bare-digit fallback. If none of the patterns match, the function returns the raw email body so the agent can fall back to LLM-based extraction. The trade-off: a bare-digit fallback can pick up the wrong number (an order ID, a year). For most real verification emails the keyword match wins; the fallback is the safety net.

A magic link is just an email with a URL the user is supposed to click. The same primitive (waitForEmail at email.ts line 67, polling every 3 seconds for up to 60 seconds) returns the message body to the agent. The agent then either calls evaluate to extract the link with a regex over body_text, or asks Claude to locate the URL and feeds it to the navigate tool. The end shape is identical to a numeric OTP test: the agent creates a temp inbox, fills the form, waits for an email, takes the verifier (URL or digits), drives the browser to the next state, asserts the success condition. The reason the same flow handles both is that the only thing that differs is the regex; the email-arrival, polling, and timeout logic is shared.

Not out of the box, because the disposable inbox is email only. Two paths work. The first is to wire your test login to a fixed phone number whose codes route to a service you control, then have the agent call that service through the http_request tool to read the latest code. The http_request tool is at agent.ts lines 172-184 and can hit any URL with custom headers, so a Twilio sub-account read or a phone-receiver API like 5sim.net works without modifying Assrt itself. The second is to bypass SMS in test environments via a back door (a fixed code for a fixed test number) and only run the real SMS path in a smoke suite. The codebase actually contains screenshots from real SMS topup tests against 5sim, so the http_request route has been used for live runs.

You can. Most teams do, and the resulting code is fine when one developer wrote it and remembers that the OTP UI on the staging environment is a split-input but the OTP UI on the demo environment is a single field. The cost shows up six months later when a new contributor inherits a flaky test, opens the spec file, and sees three regex flavours plus six page.fill() calls plus a comment that says 'do not change this, only works on Tuesdays.' The Assrt approach moves the regex bank, the inbox lifecycle, and the synthetic-paste recipe into the agent itself, where they are version-controlled in one place and run identically across every test in the suite. The vendor inbox option is a building block; the agent surface is the abstraction over it.

Six lines of Markdown. The format is the same #Case syntax Assrt uses for every other scenario. A working example: '#Case 1: Sign up with disposable email and verify the OTP. - Navigate to /signup. - Click "Sign up with email". - create_temp_email and use the returned address. - Submit the form. - wait_for_verification_code. - Paste the code into the OTP input. - Verify the dashboard URL contains /app.' That entire scenario, written by a human or generated by assrt_plan, drives a real Chrome through real signup, hits a real disposable inbox, parses a real email, types a real code, and asserts a real URL. No Playwright code, no Mailosaur key, no regex you maintain.

Partially. The keyword-anchored patterns (code, verification, OTP, pin) bias toward verification emails because marketing copy rarely uses those words next to a six-digit number. The fallback bare-digit pattern can be tricked by an order confirmation that says 'Order #482910', which is one reason why a fresh-per-test inbox matters: the only emails that arrive in the test's inbox are the ones the test triggered. In the rare case of a multi-email flow (welcome email plus verification email), the agent can call check_email_inbox to see all messages and pick the one whose subject matches 'verify' or 'confirm'. The check_email_inbox tool at agent.ts lines 880-892 returns sender, subject, and body for the latest message; with that surface the agent can disambiguate without the user writing any glue code.

Three steps. Install the Assrt MCP (npx @m13v/assrt-mcp@latest install), point it at a development URL, and write or generate a six-line scenario that includes 'create_temp_email', 'wait_for_verification_code', and 'paste the code'. The agent does the rest: visits the page, fills the form, polls the inbox, runs the synthetic-paste expression, asserts the post-login state. There is no API key for the inbox (temp-mail.io's internal endpoint requires no auth from the client), no environment variable for the regex, and no Playwright config to maintain. If you want to read the implementation first, the four files are email.ts (130 lines), the three tool definitions in agent.ts at lines 114-131, the runtime cases in agent.ts at lines 850-892, and the system-prompt paste recipe at agent.ts lines 228-236.