An agent that can browse, write code and read documents still stops at the same place: it asks a service for an account, the service sends a six-digit code to an email address, and the agent has nowhere to receive it. The run either fails or sits waiting for a person to paste the code in, which defeats the point of running it unattended.
About the 80% in the title
That number is not a measurement. I looked for a study of how many websites require email verification at signup and did not find a credible one, and I have not run a census myself. So treat the title as a figure of speech. The claim I can defend is narrower.
On the services agents are usually sent to (developer platforms, SaaS trials, community forums, newsletters, vendor portals), signing up with an email address and then proving you control it, with a code or a confirmation link, is the default pattern. Social login does not remove the requirement so much as move it: "Continue with Google" needs a Google account, and that account was created with a verified address too. Some services let you in before you verify and remind you later; many do not. For most of the signups an agent will attempt, an email address it can read is a prerequisite.
Measure your own number instead
The percentage that matters is the one for the services your agent needs. Take that list and write down four things for each service:
| Service | Email required | Code or link | CAPTCHA at signup | Phone required |
|---|---|---|---|---|
| (your service 1) | yes / no | code / link / none | yes / no | yes / no |
| (your service 2) |
Rows with email but no CAPTCHA and no phone are the ones an inbox fully unblocks. Rows with a CAPTCHA or a phone step stay blocked no matter what the agent's email setup is. Twenty services is enough to see which of those groups your use case falls in, and it will be a more useful number than any headline.
Why the agent does not already have an address
The common workarounds each have a catch. The developer's own Gmail mixes the agent's codes with a person's mail, ties the agent's accounts to that person's identity, and gives two parallel runs no way to tell whose code is whose. A catch-all address on the company domain works, but someone has to build the parsing, the waiting and the routing. Public disposable-mail sites have inboxes anyone can read, and many signup forms reject their domains. Why AI agents can't sign up goes through these in more detail.
What the agent needs is narrower than a mailbox a person would use: an address it can create on demand, and a way to block until the code arrives and get it back as a field instead of a paragraph.
The two calls
With the Lumbox TypeScript SDK (npm install lumbox):
import { Lumbox } from "lumbox";
const lumbox = new Lumbox(); // reads LUMBOX_API_KEY from the environment
const inbox = await lumbox.createInbox();
console.log(inbox.address); // a new address on trylumbox.com
// the agent types inbox.address into the signup form and submits it
const otp = await inbox.waitForOtp({ from: "example.com", timeout: 90 });
console.log(otp.code); // e.g. "482915"createInbox calls POST /v1/inboxes and returns an inbox with its id and address. waitForOtp calls GET /v1/inboxes/:id/otp, which holds the request open until a verification email with a code arrives from a sender matching from, for up to timeout seconds (the server caps it at 120). It looks back five minutes, so an email that arrived while the agent was still clicking "Submit" is found.
Two SDK details are worth knowing. First, when the timeout passes the API returns HTTP 408, and the SDK retries 408s twice by default, so a 90-second wait can take several minutes to fail; construct the client with new Lumbox({ maxRetries: 0 }) if you want exactly one attempt. Second, services that send a confirmation link instead of a code need inbox.waitForEmail({ from, timeout }), which returns the whole parsed email with parsed.verification_links. That call only sees mail arriving after it starts, so start it before submitting the form and await it afterwards:
const pending = inbox.waitForEmail({ from: "example.com", timeout: 90 });
await submitSignupForm(inbox.address);
const email = await pending;
const link = email.parsed.verification_links[0];What happens between the calls
Mail to the address arrives at Lumbox's mail server and is parsed on arrival. The parser is regular expressions and keyword rules, not a language model: it looks for 4 to 8 digit codes near words like "code" or "verification" in the subject and plain-text body, collects URLs that look like verification or magic links, and assigns a category such as verification or security. /otp only returns codes from emails in the verification category. That makes it fast and predictable, and it also means an alphanumeric code or a code shown only in an image will not be extracted; the email's text is still in the response for the agent to read.
What an inbox does not fix
An email address clears one gate. Several others are common and none of them are email problems:
- CAPTCHAs and bot checks, which exist to confirm a person is present. An agent should hand these to one.
- Phone verification, which needs a number that can receive SMS.
- Payment cards and identity checks for trials and regulated services.
- Terms of service that forbid accounts created by software. An inbox does not change what a service allows.
- Domain reputation. Some signup forms reject addresses on shared domains. A custom domain added to Lumbox with
POST /v1/domainsgives the agent addresses on your own domain instead.
Using it responsibly
One inbox per agent, or per task that has a real reason to exist, is the intended shape. Creating accounts in bulk to multiply free trials or get around per-account limits is not, and Lumbox has limits pointing the same way: the Free plan holds 3 inboxes at a time, new-organisation signups are throttled per IP address, names that impersonate well-known brands are refused on shared domains, and organisations caught abusing the service are suspended.
Inboxes do not expire, so an address given to a service keeps working for password resets and login codes for as long as you keep it. Giving an agent an email address covers the setup choices in more depth, and the quickstart gets you a key and a first inbox.