Mailinator has been around since 2003, and its central idea is still clever: every address at @mailinator.com already exists. You make up a name, send mail to it, and open the inbox. There is no signup and no provisioning call before the first email lands.
Lumbox starts from the other end. An inbox does not exist until your code creates one with an API call, it belongs to your account, and it can send as well as receive. This post compares the two for the job most readers here have in mind: an AI agent or a script that has to receive a verification email and act on it. Everything I say about Mailinator comes from its own documentation, pricing page and blog, read in September 2026.
The public inbox model
Mailinator's docs are direct about the free public system. Every inbox and email on it is readable and deletable by anyone, there is no privacy by design, messages auto-delete after a few hours, and attachments are either stripped or not delivered. For a signup you do by hand and never touch again, none of that matters.
For an agent it does. A verification code that lands in a public inbox can be read by anyone who guesses or scrapes the inbox name, and the account it verifies is then only as private as that name. Mailinator's own AI announcement says the same thing in plainer words: public inboxes are public, so do not use them for anything sensitive.
Paid plans fix the privacy half. Subscribers get a private domain (a subdomain of testinator.com by default, or a domain you bring) where every address still exists implicitly, and a "super inbox" lists all mail for the domain as it arrives. Private messages persist until your plan's storage fills. The pricing page lists a Verified Pro tier at $0 with verification (one private domain, 2,000 emails a month, 60 a day) and a Business tier at $79 a month billed yearly.
What the Mailinator API gives you
API access is for subscribers; the API page says to start with a free trial or Verified Pro. The documented flow has three steps: list message summaries for an inbox, fetch the full message by ID (headers plus body parts), then parse. Mailinator's September 2026 guide on automated testing recommends polling every two seconds against a thirty second deadline, and for the parse step it says plainly that there is no call: you run your own regex over the text parts. A separate endpoint returns the links found in a message, which covers reset links and magic links well.
Lumbox parses every inbound message when it arrives. The email object carries parsed.otp_codes, parsed.verification_links and parsed.magic_links, and one endpoint blocks until a code shows up:
curl -H "X-API-Key: $LUMBOX_API_KEY" \
"https://api.lumbox.co/v1/inboxes/inb_XXXXXXXXXXXXXXXXXXXX/otp?timeout=60&from=github.com"
{"code":"482913","all_codes":["482913"],"from":"noreply@github.com",
"subject":"Your verification code","expires":null,"email_id":"eml_XXXXXXXXXXXXXXXXXXXX"}If nothing matching arrives within the timeout, the call returns HTTP 408 and you decide whether to resend the code or give up.
The extraction is a fixed set of regular expressions, not a model, so it has edges. On received mail it scans the subject and plain-text body for 4 to 8 digit codes near words like "code" or "verification". A code that only appears in the HTML part, or one that contains letters, will not land in otp_codes, and /otp only considers emails the parser categorised as verification mail. For those messages you call /wait, read the body, and apply your own pattern, which is the same work Mailinator's guide describes.
Receive-only versus two-way
Mailinator's documentation states that the system is receive-only: nobody can send an email from Mailinator. Its routing rules can POST a matching message to a webhook or drop it, and you can inject messages into your own private inboxes over HTTP, but there is no outbound mail. The AI announcement lists email sending under features the team is exploring.
For a QA suite that checks your app sent the right email, receive-only covers everything. Agents often need the other direction: replying on a support thread, answering a "did you request this?" message, or forwarding a receipt to a person. Lumbox inboxes send, reply and forward from the same address that received the mail. Replies carry In-Reply-To and References headers so they thread correctly, and volume is capped per plan.
Side by side
| Mailinator | Lumbox | |
|---|---|---|
| Getting an address | Every address already exists; private domains on paid plans | One POST /v1/inboxes per address, default @trylumbox.com |
| Free tier privacy | Public inboxes, readable by anyone, deleted after a few hours | Private to your account; 3 inboxes on the free plan |
| API access | Subscribers (Verified Pro or trial) | All plans, including free |
| Waiting for mail | Poll the inbox endpoint | Long-poll /wait and /otp, up to 120 seconds per call |
| Codes and links | Your own regex; a links endpoint for URLs | Parsed on arrival into parsed.* fields |
| Sending | None (receive-only) | Send, reply, forward |
| Push | Routing rules POST messages to a webhook | Webhooks signed with HMAC-SHA256 |
| SMS | SMS testing (numbers at extra charge) | None |
| MCP | CLI-based server with list_inbox and get_email | npm and hosted server, more than 80 tools |
| First paid tier | Business, $79/month billed yearly | Starter, $9/month |
Where Mailinator is the better choice
If a person is testing a signup flow once, the public inbox is quicker than anything that needs an API key: type a name, look at the mail. If a QA team runs a large suite across many addresses, a private domain where every address already exists is less code than creating an inbox per test, and the super inbox view helps when a test fails. Mailinator also handles SMS, which Lumbox does not do at all.
Its MCP support is worth knowing about. The mailinator-cli package starts a local MCP server with two tools, list_inbox and get_email, and works against public inboxes without a token. For an assistant that only needs to read a test email, two tools are enough.
Where Lumbox fits better
Lumbox is built around an agent owning an address for as long as a task needs it. The usual loop is one inbox per task: create it, give the address to the signup form, block on /otp, and delete the inbox afterwards. Inboxes never expire on their own, so the delete belongs in your cleanup code, and with three inboxes on the free plan you will notice quickly if it is missing.
The other difference is who can read the mail. On public Mailinator, anyone can. On a Mailinator private domain, your team can. On Lumbox, reading an inbox needs an API key from the account that owns it, so an address that leaks into a log does not expose the mail sent to it. An agent can even create its own account: POST /v1/orgs with a name returns an API key once, with no card on file.
The quickstart creates an inbox and waits for a code in three calls, and the long-poll post covers how /wait and /otp behave around timeouts. Inbox and send limits for each plan are on the pricing page.