Add email verification to a browser agent by connecting its login workflow to an inbox API, retrieving the matching code, and passing that value back to the active browser challenge. Lumbox can supply the email side of this design while Skyvern, Browserbase or Steel supplies the browser workflow, with adapter work depending on the platform you use.
The useful unit of evaluation is a customer portal login. A browser can navigate a form correctly while the code travels somewhere the runtime cannot read. Replacing the browser provider does not necessarily change that email route. Start by identifying the destination mailbox and the owner who can authorize access or forwarding.
Define the handoff
Keep browser state and email state connected in your application. Save the customer account reference, portal origin, browser session, inbox ID and attempt start time before requesting the code. These are application records, not fields that Lumbox automatically adds to a portal email.
The email adapter’s job is to return a candidate verification value with enough context to inspect it. The browser adapter’s job is to place that value into the intended challenge and check the result. If either adapter times out, the parent workflow decides what happens next.
| Part of the workflow | Responsibility |
|---|---|
| Customer onboarding | Establish authorized access and email routing |
| Browser controller | Navigate, request a code and identify the challenge |
| Email adapter | Retrieve a matching message or parsed code |
| Application state | Associate the result with the active attempt |
| Browser verification | Confirm the portal accepted the login |
This boundary also makes vendor evaluation easier. You can exercise the email adapter with a controlled message before running a whole browser task. You can test the browser with a manually supplied code before diagnosing an inbound-email delay.
Skyvern: inspect its existing authentication path first
Skyvern documents authenticator-based TOTP and email or text-message code handling, including ways to push codes into a waiting workflow. Its 2FA setup documentation is the right starting point for deciding where an external code source belongs.
Do not add another integration merely because the workflow involves email. If Skyvern’s existing authentication route already meets the customer’s needs, use that. If you need a separate inbox service, retrieve the code in your application and connect it to the documented Skyvern input for the active run. Verify the current input contract before implementing the adapter.
This article proposes an architecture. It does not establish a native Lumbox connector in Skyvern, and it does not claim an end-to-end integration has been tested. The distinction matters when estimating implementation work for a pilot.
Browserbase: keep email retrieval in your orchestration
Browserbase provides infrastructure for agents that browse and interact with the web. Its platform introduction describes cloud browsers and other agent infrastructure. Your application can coordinate a browser task with an HTTP request to Lumbox.
When the browser reaches a code challenge, preserve the session and call the email adapter from the runtime controlling the task. Once a suitable result arrives, resume the intended interaction. Avoid letting an unrelated browser task consume a result simply because it is the latest one in a shared mailbox.
An adapter does not need to make the model responsible for polling. Deterministic application code can wait, classify the outcome and expose only the result needed for the next browser action. That leaves the browser agent free to handle page interaction without repeatedly asking whether mail has arrived.
Steel: distinguish existing Lumbox tools from a custom adapter
Steel documents a browser API, session management and credential capabilities in its documentation. Lumbox’s repository also contains Steel-backed browser tools. Those tools require the relevant browser configuration; installing an email MCP server is not proof that a browser session is ready.
If you already control Steel directly, the same external email-adapter pattern applies. If you use Lumbox’s browser tools, inspect the Lumbox browser documentation and test the tool path you intend to call. Do not assume a compound signup tool handles every portal’s challenge sequence.
Choose one controller for a given session. Two independent agents typing into the same challenge can create a confusing failure even when the email response is correct. Session ownership belongs in the workflow design.
The Lumbox retrieval contract
For an existing inbox, call GET /v1/inboxes/:id/otp with an explicit since timestamp and, where useful, a received-sender filter. It waits 30 seconds by default and accepts up to 120 seconds. A successful response includes code, all_codes, from, subject, expires and email_id; HTTP 408 indicates no suitable code before timeout. See the API reference.
The route selects mail in the verification category, and extraction depends on parser rules. Forwarded templates therefore need their own check. The sender seen by Lumbox may be the forwarder. A substring sender filter cannot authenticate the portal or uniquely identify the browser attempt.
For a magic link, read the appropriate structured link fields from an email response instead of expecting the numeric-code shortcut to solve the task. For a phone-only challenge, an email inbox alone does not provide a phone number or receive SMS directly.
Run a small integration trial
Use an owned test account and write down the expected outcome before recording a demo. First, establish that the message arrives and is parsed. Then test the handoff into the browser. Finally, confirm the authenticated page represents the account you intended to access.
Include a delayed message and a second overlapping attempt. Check that the application neither switches inboxes accidentally nor submits a stale result after the browser has moved on. Keep a human handoff available when the route or challenge changes.
Record the result by stage rather than reporting only “login failed.” Useful stages are delivery, extraction, retrieval, browser entry and portal acceptance. This gives your team a concrete basis for comparing browser providers and inbox services without attributing every failure to the model.
For a first Lumbox trial, the free plan includes three inboxes. That supports a small routing experiment, subject to its email limits. Use the pricing documentation for current allowances, then size the pilot around the inboxes you need to keep active.
Implementation references: apps/api/src/routes/inboxes.ts, apps/mcp-server/src/tools.ts, apps/docs/content/docs/browser.mdx, and packages/plans/src/index.ts. Platform documentation and source checked October 3, 2026. No live integration benchmark is claimed.
Kumar