Temp-mail websites such as Guerrilla Mail, 10 Minute Mail and temp-mail.org exist so a person can sign up somewhere without handing over a real address. They are free, need no account, and work in seconds, which is exactly what you want for a one-off manual signup. Developers start using them in scripts because of those same traits, and then run into the parts that were never designed for code: who else can read the inbox, when it disappears, and how a program is supposed to find the code inside a message. A temp email API keeps the disposable idea and gives each of those decisions back to you.
Having an API is not the difference
Some temp-mail services do publish an API. Guerrilla Mail, for one, documents a public JSON API that needs no key. So what separates the two is ownership, not whether an API exists. A service built for anonymous visitors treats the address as a lightweight session with no account behind it. An inbox API treats the inbox as a resource that belongs to an account, which is what lets it offer access control, a lifecycle you set, parsing and sending. The rest of this post takes each of those in turn using Lumbox.
The inbox as a resource
# create
curl -s https://api.lumbox.co/v1/inboxes \
-H "X-API-Key: $LUMBOX_API_KEY" -H "Content-Type: application/json" \
-d '{"name": "scraper-run-42"}'
# {"id": "inb_...", "address": "scraper-run-42@trylumbox.com", "status": "ACTIVE", ...}
# block up to 60s for a verification code
curl -s "https://api.lumbox.co/v1/inboxes/inb_.../otp?timeout=60" -H "X-API-Key: $LUMBOX_API_KEY"
# {"code": "847291", "all_codes": ["847291"], "from": "...", "subject": "...", "expires": null, "email_id": "eml_..."}
# list what arrived
curl -s "https://api.lumbox.co/v1/inboxes/inb_.../emails?limit=20" -H "X-API-Key: $LUMBOX_API_KEY"
# delete the inbox and its mail
curl -s -X DELETE https://api.lumbox.co/v1/inboxes/inb_... -H "X-API-Key: $LUMBOX_API_KEY"The /otp call is a long-poll: the server checks once a second and returns as soon as a matching message exists, or answers 408 after the timeout (at most 120 seconds). The list endpoint takes from, category, since and unread filters and pages with a cursor.
Who can read it
On a public-inbox service the address is the only credential, so anyone who knows or guesses it can read the mail, including the verification link for an account your script just created. An API inbox belongs to an organization, and every read needs an API key from that organization. If someone guesses scraper-run-42@trylumbox.com, the most they can do is send mail to it. Inside your own organization, an org key reaches every inbox, while a project key only reaches the inboxes created in its project, which is how staging scripts and production agents can be kept apart.
A lifecycle you control
Temp-mail sites delete addresses and messages on a timer the site chooses. Lumbox inboxes have no timer: there is no TTL setting, and an inbox with its messages stays until you call DELETE. That means a script can create an inbox, use it and delete it, and a long-running agent can keep one address for months. The catch is that live inboxes count against your plan (3 on Free, 10 on Starter, 50 on Pro, 250 on Scale), so a script that creates without deleting eventually gets a 402 PLAN_LIMIT_EXCEEDED.
Parsed on arrival
A temp-mail page shows you the message, and your code has to find the code in it. Here each message is parsed as it arrives, and the email JSON carries a parsed block with otp_codes, verification_links, magic_links, a keyword-based category and code_expiry. The parsing is regular expressions and keyword rules, not a model. Codes are extracted when they are 4 to 8 digits next to words like "code" or "verification", or sit alone on a line. Codes with letters, or digits split by a space, are not extracted, and /otp only returns codes from messages categorized as verification. The raw text_body and html_body are in the same response for anything the parser misses.
Sending from the same address
Temp-mail sites are built to receive. An API inbox can also send, which matters when a flow expects a reply or when an agent needs to contact someone:
curl -s https://api.lumbox.co/v1/inboxes/inb_.../send \
-H "X-API-Key: $LUMBOX_API_KEY" -H "Content-Type: application/json" \
-d '{"to": "someone@example.com", "subject": "Following up", "text": "Hi, ..."}'
# {"ok": true, "email_id": "eml_...", "thread_id": "thr_...", "message_id": "...", ...}Sending is metered separately from receiving. The Free plan allows 100 sends a month and 3 a minute, and a new Free account without a verified domain is limited to 5 sends in its first hour and 25 in its first day. Replies go through POST /v1/inboxes/:id/reply with the email_id you are answering, which sets the threading headers for you.
Webhooks, with one caveat
Instead of waiting on a request, you can register a URL for the email.received event with POST /v1/webhooks. The payload includes email_id, inbox_id, from, subject, category and otp_codes. Each delivery carries an X-Lumbox-Signature header, the hex HMAC-SHA256 of the raw body keyed with the whsec_ secret you received when creating the webhook:
import crypto from "node:crypto";
export function verifyLumboxSignature(rawBody, signature, secret) {
const expected = crypto.createHmac("sha256", secret).update(rawBody).digest("hex");
return typeof signature === "string" &&
signature.length === expected.length &&
crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}The caveat: today a failed email.received delivery is logged but not retried. If your receiver is down, that event is gone, although the email is still in the inbox. Treat the webhook as a prompt to fetch, and after any downtime catch up with the list endpoint and since. The pricing page lists webhooks on the Starter plan and above; the webhooks post covers receivers in more depth.
The domain question
Many signup forms check the address against lists of known disposable-email domains and refuse matches. Any shared domain can end up on those lists, and that includes a shared API domain like trylumbox.com, because every customer's inboxes live on it. If a target site refuses the shared domain, verify a domain you own: POST /v1/domains returns the DNS records to add, POST /v1/domains/:id/verify checks them, and inboxes created with "domain": "yourdomain.com" then receive there. The domains docs walk through the records.
Which to use
For a manual signup you will never revisit, a temp-mail website is quicker than creating an account anywhere. For a script, a test suite or an agent, the API version answers the questions the website leaves open: only your keys can read the inbox, it lasts until you delete it, and the code arrives as a field. The inbox docs list every endpoint above, and a Free key needs no credit card.