Why This API Has The Limits It Has

Stage: a position we held and then reversed. In control: us, and now the answer is yes with conditions.

1. What this page used to say

For a long time this page argued that there would be no programmatic access here, and the argument was not decoration. It ran like this: the domains a generator hands out are a limited stock, every domain eventually stops being accepted on signup forms, replacing one costs money and lead time, and a machine draws that stock down at a rate no person can match. A loop does not get bored. One automated consumer pulls a narrow slice of the pool over and over, the receiving side of the internet sees a single domain appear across thousands of signups in a short window, and that is precisely the pattern that gets a domain blocked. The cost of that lands on everyone else using the site.

Every sentence of that is still true. What was wrong was the conclusion drawn from it.

2. What changed

The flaw was treating one pool as the only pool. The reasoning said an interface would spend a shared resource; it did not say the interface has to spend the same resource that visitors do. Once the two are separated, the argument stops forbidding an API and starts describing how to build one.

So the API hands out addresses on domains of its own. They are not offered on the front page, they are not in the dropdown, and no visitor is ever given one. When integrators burn through them, and they will, the fire stays inside a pool that was set aside to be burned. The domains people use on the site are untouched by it.

That single decision resolves most of the old objection. The rest is handled by limits that follow from the same reasoning rather than from a pricing table.

3. What the interface will not do

Three hundred inboxes an hour on one key, six hundred reads a minute, one hundred live inboxes at a time. Those numbers are not a tier to be upgraded. They are the point where ordinary automated use ends and something else begins.

An inbox from the API lives twenty four hours from the moment it is created, and reading it does not extend that. This differs from the website on purpose. A visitor who keeps a tab open is telling us the address is in use; a test that polls the same inbox for an hour is telling us nothing except that a loop is running, and rewarding it with a longer life would keep inboxes alive for as long as a pipeline runs.

Sending remains unavailable, in any form, exactly as it is on the site. Receiving is the whole product.

4. What it does that the browser cannot

Two capabilities exist only through the interface, and both remove work rather than adding a feature.

Messages are pushed. A connection stays open and the server speaks when mail lands, which means the polling loop that every integration used to open with does not need to be written. The same mechanism has been serving the website since the first day, and this is a second door onto it.

The confirmation code comes back extracted. Ask for it and the request waits until the message arrives, then returns the digits and the activation link alongside the message itself. Everyone who has automated a signup flow has written this parser at least once, usually against one vendor's email template, and usually again six months later when the template changed.

5. What it is not for

An address from this pool is recognisably disposable. It is meant for systems you own: your test suite, your staging environment, an agent you control, a signup flow of yours that needs checking in five languages without five rounds of clicking.

Pointed at somebody else's service to farm accounts or slip past their limits, it stops being a tool and becomes an incident, in their logs first and ours shortly after. Pretending we cannot tell the difference in traffic would be the same wink this page refused to give when it was arguing the opposite case.

6. When your own infrastructure is still the right answer

One thing has not changed since the earlier version of this page. If a pipeline needs a mailbox on every run at high volume, and the mail comes from a system you control, then receiving it in infrastructure you also control is faster, private, and free of anyone else's domain reputation. That path costs an afternoon and then belongs to you.

The interface here is for the case in between: real signup flows on services you do not own, checked occasionally rather than ten thousand times a day, where standing up mail infrastructure to test one form is the wrong shape of effort.

The handover

The reference for every endpoint, along with the key, lives on the API page. If what you needed was one address for one form, the generator on the front page is still faster than reading this. How the address string is put together in the first place is in how an address generator works, what the receiving site does with it starts in what happens the moment you submit, and if the reason you came here was volume rather than convenience, why mass signups do not work covers what actually catches them.