Last week we shipped a developer API for Emcognito: one key, two endpoints, and you can create anonymous email aliases from a script, a password manager workflow, or your own tooling. Then we did something every competitor in this category considers backwards — we made the API available only on paid plans. SimpleLogin gives API keys away free. So do addy.io and Firefox Relay. Here is why we deliberately went the other way, and why we think free API keys and disposable email are a dangerous combination.
What the API does
The API is intentionally small. With a key from your developer settings you can:
- Create aliases —
POST /v1/aliasesmints a fresh anonymous address that forwards to your inbox, exactly like one created in the dashboard. - List aliases —
GET /v1/aliasesreturns your existing addresses so scripts can reuse instead of re-mint.
Keys are scoped to your account, shown exactly once at creation, stored only as a hash on our side, and can be rotated or revoked in one click. Creation is capped at 50 aliases/day on Plus and 200/day on Pro. Full reference and curl examples live at emcognito.com/developers.
The obvious question: everyone else gives this away
They do, and we looked hard at following suit — a free API is a genuinely nice on-ramp, and we like the products that offer one. But an alias service has one asset that everything else depends on: deliverability. Mail from our domains has to land in inboxes, not spam folders, or the product is worthless to every user at once.
Now consider what a free, anonymous, no-card-required API key actually is in this category: infinite burner addresses at machine speed, with zero accountability. That is precisely the tool you want for scripted signup floods, review fraud, trial abuse, and credential-stuffing infrastructure. When that traffic runs through a forwarding service, the reputational damage lands on the shared domain — which means it lands on every legitimate user's mail too. Abuse of a free API is not a support ticket; it is an outage for everyone.
A card on file is the honest anti-abuse control
There are other defenses, and we use several — per-key daily caps, per-plan checks on every single request, server-side attribution of every API-minted alias. But CAPTCHA walls, phone verification, and shadow rate limits all tax legitimate users to slow down abusers, and abusers are better at beating them than real users are at tolerating them.
A paid plan is different. It is a small, honest deposit that says an accountable person stands behind this key. We already apply exactly this policy to composing new mail from an alias — it is a paid feature for the same reason: a card on file is our strongest anti-abuse control. The API follows the same rule. And because the plan is re-checked on every request, a refunded or downgraded account loses API access instantly — there is no window where a burned card keeps a working key.
What it costs
The API is included in both paid tiers — there is no separate "developer" plan and no per-call pricing:
- Plus — $2/month: API access with 50 alias creations/day, plus 2,500 forwards a month and compose-from-alias.
- Pro — $4/month: API access with 200 alias creations/day and 15,000 forwards a month.
At $2/month, Plus is the cheapest paid tier in this category that includes an API, so "paid-only" here is a smaller hurdle than it sounds. Aliases themselves stay unlimited on every plan, including Free — the API changes how you can create them, not how many you can have.
What this means if you just want to try it
Everything in the dashboard stays free: unlimited aliases, forwarding up to the Free cap, replying to forwarded mail. The API is for the moment you want aliases created programmatically — a new address per signup from a script, a keyboard-driven workflow, an integration of your own. When you hit that moment, the key is two clicks away on a paid plan.
Read the API docs or see plans and pricing. And if you think we've made the wrong call on paid-only, tell us — hello@wm.emcognito.com reaches a person, and this decision is written in code, not stone.