Email Inbox API: Rate Limits, Quotas, and Best Practices

Email APIs have rate limits to prevent abuse and ensure fair resource allocation. Understanding these limits helps you design agent workflows that stay within them.

Key Limits to Know

Operation	Limit	Notes
Create inbox	100/minute	Per API key
List emails	1000/minute	Per API key
Send email	50/minute	Per inbox
Long-poll connections	500 concurrent	Per API key
Bulk send	100 recipients	Per request

Pattern: Avoid Polling Loops

The biggest rate limit mistake is building a polling loop that calls GET /emails every second for every agent. With 100 agents, that is 6,000 requests per minute. Use long-poll instead:

# Bad: burns quota with rapid polling
while True:
    emails = get_emails(inbox_id)
    if emails: break
    time.sleep(1)  # Still 60 req/min per agent

# Good: one request blocks until email arrives
email = wait_for_otp(inbox_id, timeout=60)

Long-poll uses one HTTP connection instead of 60 polling requests per minute per agent.

Pattern: Create Inboxes in Advance

For high-throughput workflows, create a pool of inboxes at startup rather than creating one per request in the hot path:

# Startup: pre-create 20 inboxes
inbox_pool = [create_inbox() for _ in range(20)]

# Runtime: pull from pool instead of creating
inbox = inbox_pool.pop()
# ... use inbox ...
# ... delete or return to pool when done

Pattern: Use Webhooks for Scale

For workloads above 100 concurrent agents, use webhooks instead of long-polling. One webhook can handle any number of concurrent inboxes without scaling connection count linearly.