Skip to content
CyberTemp
All posts
How to manage temp mail inboxes before you hit a limit

How to manage temp mail inboxes before you hit a limit

CyberTemp6 min read

Every CyberTemp plan caps how many inboxes you can hold open at once. FREE gives you five. If you're generating a fresh burner for every signup, every airdrop entry, every OTP test run, five goes fast — and once you're at the ceiling, creating a new inbox stops working until something ages out or you delete one yourself. Most people find this out by accident, mid-signup, instead of planning around it. Here's how the limit actually works, when to delete an inbox instead of waiting it out, and how to automate the cleanup if you're doing this at any real volume.

Why the inbox count sneaks up on you

The per-service-burner pattern is the whole appeal of temp mail: a new address for every signup means a spam source you can trace, a service you can drop without touching your real inbox, and no shared history between accounts. It also means the number of inboxes you're holding grows every time you do it. Nobody counts as they go.

Five feels like plenty until you're testing three signup flows in one afternoon, farming a handful of allowlist spots, or running a sneaker raffle with one entry per address. The concurrent-inbox limit isn't a soft warning — it's a hard ceiling on your plan, and it applies per API key or per browser session, not per address you've ever created. Old, expired inboxes stop counting against it. Live ones don't.

How retention windows actually work per tier

Every inbox has a retention window that starts the moment it's created, and it's what eventually frees up a slot without you doing anything:

  • FREE — 10 minutes. Built for a single verification code, not a session you come back to.

  • ECO — 24 hours. Enough for a signup flow with a delayed confirmation email, or a same-day return to an inbox you generated that morning.

  • CORE — 7 days. Long enough to hold an address through a multi-step onboarding flow or a week-long free trial.

  • ELITE — 30 days. Built for inboxes you treat like a real secondary address, not a one-time burner.

This is why a FREE-tier user hits the limit constantly and a CORE user rarely notices it: on FREE, inboxes expire fast enough that slots recycle on their own within minutes. On CORE and ELITE, they stick around for days or weeks, which is great for the inbox itself and bad for anyone who forgets they're piling up. The trade-off is real — longer retention means more control over when mail arrives, but it also means you're the one responsible for clearing space instead of the clock doing it for you.

Deleting an inbox instead of waiting it out

You don't have to wait for expiry. DELETE /inbox?email=<address> removes an inbox you own and frees the slot immediately — useful the moment you're done with an address, not ten minutes or seven days later.

curl -X DELETE "https://api.cybertemp.xyz/[email protected]" \
  -H "X-API-Key: tk_..."

In the browser this is just as direct: open the inbox on cybertemp.xyz and clear it once you've got what you needed, instead of leaving a dozen tabs' worth of one-off addresses sitting active in the background. If you're not sure what's currently open against your account, GET /inbox lists everything you own — id, address, and creation time, most recent first, capped at 200 rows. That's the fastest way to see what's actually eating your limit before you assume you need to upgrade.

Automating cleanup with the API

If you're generating inboxes programmatically — CI runs, a bot doing multi-account signups, a scraper verifying dozens of accounts a day — build teardown into the same script that creates the inbox, rather than trusting retention to catch up later.

import httpx

API_KEY = "tk_..."
HEADERS = {"X-API-Key": API_KEY}
BASE = "https://api.cybertemp.xyz"


def list_inboxes():
r = httpx.get(f"{BASE}/inbox", headers=HEADERS)
r.raise_for_status()
return r.json()


def delete_inbox(email: str) -> None:
r = httpx.delete(f"{BASE}/inbox", params={"email": email}, headers=HEADERS)
if r.status_code not in (200, 204, 404):
r.raise_for_status()


def free_up_slots(keep_recent: int = 5):
inboxes = list_inboxes()
for stale in inboxes[keep_recent:]:
delete_inbox(stale["email_address"])

A run that creates ten inboxes and deletes them in teardown never gets near the plan ceiling, no matter how small it is. That's the difference between a script that runs reliably every day and one that mysteriously starts failing to create inboxes a few weeks in, once nobody's watching how many are still open. If you're running this inside CI already for OTP or signup testing, the same client and headers work — no separate setup for cleanup.

What upgrading actually changes

The concurrent-inbox limit and the request-rate limit move together as you go up a tier, which matters if you're hitting either one:

  • FREE — 5 concurrent inboxes, 10 requests/sec, 10-minute retention.

  • ECO — 25 concurrent inboxes, 20 requests/sec, 24-hour retention, unlocks IMAP access.

  • CORE — 100 concurrent inboxes, 50 requests/sec, 7-day retention, unlocked custom domains.

  • ELITE — unlimited concurrent inboxes, unlimited requests/sec, 30-day retention, encrypted inboxes and webhooks.

If cleanup discipline is already tight and you're still bumping into the ceiling, that's the actual signal to upgrade — not a guess about what tier "sounds right." A script hitting a 429 with a Retry-After header is telling you the exact thing to fix: back off and retry, or move to a tier where the per-key rate limit isn't the bottleneck. Guessing wastes more time than checking GET /getPlan and reading the actual numbers back.

Bottom line

For casual use, this mostly doesn't matter: open cybertemp.xyz, generate an inbox, use it, and let it expire. FREE's 10-minute window means you'll almost never notice the 5-inbox cap unless you're opening several at once in the same few minutes.

For anyone generating inboxes at volume — multi-account workflows, CI pipelines, bots doing signups on a schedule — the fix isn't more inboxes, it's better teardown. Delete what you're done with, check GET /inbox before assuming you're out of room, and only upgrade once cleanup alone stops being enough. The plans page has the exact concurrent-inbox and rate-limit numbers per tier if you're deciding which one actually fits your volume.

For the naming pattern that makes dozens of active inboxes easy to track in the first place, the airdrop farming guide covers address-per-project conventions built for exactly this kind of volume. If a cleanup script keeps hitting inboxes that never seem to accept mail in the first place, that's usually a domain issue rather than a limit issue — see why temp email gets rejected. And for the polling side of the same API — reading messages back out of an inbox instead of just creating and deleting them — the OTP test automation post covers that end to end.

Share