Verification Codes for AI Agents: Closing the Email Loop
By Denis · Published 19 Sep 2026. Updated 28 Sep 2026.
Ask anyone who has automated a signup what stops the script, and the answer is almost always the same shape: the site says "we emailed you a code", and the automation has no inbox. The form half is easy, fill, submit, done. The email half is where agents stall, because a one-time code sits in a place most agents cannot read, guarded by a validity window measured in minutes.
Closing that loop is a solved problem when the agent owns a disposable mailbox with the right primitives. This article walks the loop end to end with Tempx's surfaces, and and, of equal weight, the choices that keep codes private and the usage honest.
The loop, and where it breaks
Drawn out, the loop has four beats: submit the form with an address; wait for the message; extract the code; enter it before it expires. Teams break it in different places. The wait is the most common failure, a naive poll loop checks every few seconds, trips a rate limit, backs off, and discovers the code has expired in the meantime.
Extraction fails next: the code lives in a message with HTML and plain-text parts, marketing chrome around it, and formats that drift ("123-456" today, six bare digits tomorrow). And on shared test inboxes there is the cruelest failure: two runs land two codes in one box, and the regex happily reads the wrong one.
Every one of those has a boring fix, and the fixes compose into a reliable loop.
One blocking wait instead of a poll loop
Tempx's MCP server exposes the wait as a first-class tool. The agent submits the form, then makes exactly one call:
const hit = await tools.wait_for_email({
subject_contains: "your code",
timeout_seconds: 120, // window: 5–175 s, returns early on arrival
});
if (!hit.received) throw new Error("code never arrived");
const body = hit.email.text || hit.email.preview;
The waiting happens on the server: the call returns the moment a matching message lands, so the agent spends nothing on empty intervals, and arrival inside the code's validity window becomes something you can assert rather than hope for. Filters on sender and subject keep unrelated mail out of the result.
A sizeable timeout is cheaper than it looks. Delivery is often fast, but first messages to a fresh address can take longer than you expect; a 120-second ceiling on the wait costs nothing when the mail arrives in eight.
Reading the code out of the message
Prefer the plain-text part when it exists, it is the format senders keep stable, and it is what Tempx returns alongside the sanitized HTML. Then match narrowly: look for the code near its label ("Your code is: 493-012"), not any digit run in the message, or you will at times read a phone number out of the footer.
Keep the extraction honest about drift. A small pattern list (three to eight digits, optional separator, case-sensitive alphanumerics for the mixed format) covers most senders, and logging the unmatched message (via get_email) beats silently guessing. A sender changing format should produce a diff, not a mystery failure.
For everything past the code (the link in a verification mail, the reset URL, the surrounding text) the same read tools apply. The MIME decoder and header analyzer exist for the cases where you need to see exactly what was sent, not the sanitized summary.
Fresh inbox per run, and the retention clock
The parallelism rule is absolute: one fresh inbox per test run. Shared boxes create interleaved codes, cross-run leakage and flaky extractions, and they solve a problem (address scarcity) that does not exist, creating an address is free and instant. Scoping also means one run's failure never poisons the next.
Know the retention clock, because it is part of the loop's timing. Tempx private inboxes keep mail for one hour by default, named inboxes for seven days. An hour is generous for reading a code that expires in five minutes, and the short window is the point: anything sensitive that lands there stops existing fast, by design rather than by cleanup discipline.
Building the loop in CI? Assert the timing too, if the code's validity window is five minutes, arrival within sixty seconds is part of the contract, and wait_for_email's return gives you the timestamp to check it against.
Private inboxes, because named ones are readable by guessers
Tempx has two kinds of inbox, and for verification codes the difference matters. A named inbox is readable by anyone who knows or guesses the name, convenient for quick manual checks, wrong for anything sensitive. A private inbox can be read only with its bearer token, which is exactly what an MCP connection carries.
So the rule is simple: agents asserting on real message content use private inboxes, created per run, accessed through the token or the MCP connection. The blast radius of a leaked credential stays "one disposable inbox that expires within the hour" instead of "a mailbox someone can watch".
The same scoping discipline applies on the agent side of the connection: read-only permissions when the loop only reads, revocation one click away, and connections that expire on their own. None of this is inconvenient; it is the default shape of the tools.
The honest boundary of the technique
Everything above is about your flows: testing your signup, your reset path, your agent's ability to complete a loop you own. Using disposable inboxes to mass-create or bypass verification on services you don't operate is a different activity, abusive, often against those services' terms, and against Tempx's own terms of use. The tooling does not try to distinguish these cases for you; the boundary is yours to hold.
Inside that boundary, the pattern is quietly powerful: the address is disposable, the code is read the instant it exists, the inbox evaporates, and the loop (form, mail, code, confirm) runs end to end without a human tab-switching in the middle. That is the whole trick, and it composes into bigger things: agent-driven test suites, self-verifying migrations, automations that finish what they start.
Common loop bugs, and their one-line fixes
The loop is small enough that its failure modes are catalog-worthy. The regex grabs the wrong number, anchor to the code's label, not bare digits. Two runs, one inbox, fresh address per run, always. The wait times out on a slow first delivery, size the timeout to the sender's worst case, not the average; fresh-address first mail can dawdle. The code works but is already expired, arrival-to-submission is part of the loop; measure it before blaming the sender. The agent re-reads yesterday's mail, always pass a sinceTs at loop start, or match on something unique to this run's request.
Every fix is one line because every cause is precise. The debugging discipline that finds them: log the address, the filter, the timeline, and the raw matched message, with those four, the category is identifiable at a glance, and the fix is often visible in the same glance.
Where this pattern goes next
The verification loop composes into larger automations cleanly because its edges are clean: deterministic input (the address), one asynchronous dependency (the mail), a bounded wait, and an idempotent action at the end. Teams stack it into self-provisioning test accounts (a fresh identity per suite run, verified and discarded), migration verifiers (sign up through the new stack, prove the mail still arrives and validates), and standing monitors (a nightly loop that notices the day the codes stop arriving, hours before the customers do).
The common thread is inversion: email stops being the manual step automations wait on and becomes the event they react to. That inversion is available to anything that can hold a token and make an HTTP call, which, these days, is everything from a cron job to a coding agent. The loop itself never grows more complicated than the four beats it started with; what grows is the set of things you are willing to trust it with.
Drafted with AI assistance and reviewed against Tempx's editorial rules (no invented statistics, no competitor claims).
Related: How email verification codes work · Testing OTP emails · MCP integration guide · Testing email flows (developer guide)
Create a temporary email address
Free, instant, no sign-up, messages auto-delete.
Go to your inbox