Plans and limits

What each tier allows, and where limits are enforced.

Every tier gets the whole API. The tiers differ in volume, not in features.

A dash means no limit. Pricing and how to upgrade are on carlyemail.com/pricing.

Two counts are worth reading twice. The default pod counts, so the free tier's allowance of two leaves room for exactly one more. Deleted inboxes do not count — an address stays claimed after deletion so mail still in flight cannot land in a new inbox, but it stops using a slot.

Reading your own limits

GET /v0/organizations returns every count beside every limit, so an agent can check before it is refused rather than after. null means unlimited.

{
  "organization_id": "org_...",
  "plan": "free",
  "inbox_count": 2,  "inbox_limit": 3,
  "domain_count": 1,  "domain_limit": 1,
  "pod_count": 1,     "pod_limit": 2,
  "webhook_count": 0, "webhook_limit": 2,
  "storage_bytes": 41231, "storage_limit_bytes": 1073741824
}

GET /v0/billing answers the same question about the plan alone, without the counts, and says whether billing is configured on this deployment.

Unverified organizations

Before the owner email is confirmed, an organization is capped hard:

This is deliberate. Sign-up is a single unauthenticated call, which is what lets an agent create its own mailbox mid-conversation — so the abuse gate has to sit somewhere, and it sits on the recipient line: every message an unverified account can send goes to the one person who can shut it down. Domains and webhooks are barred because each is a way to make an unconfirmed account useful to somebody who does not own the address it was opened with.

An unverified key can read, label and organize its own mail, and email its owner — enough to prove a whole send/receive loop before any human steps in. Confirm with POST /v0/agent/verify and the free tier applies immediately.

The daily cap

The free tier's daily cap matters more than its monthly one. It is what stops a newly signed-up agent emitting three thousand emails in an hour and taking the shared subdomain's reputation down with it. Paid plans have no daily cap because they have a payment method attached and a person behind it.

What happens at the limit

Nothing degrades quietly. The request that would cross a cap is refused with 429 and a code naming what ran out.

The two time-based caps carry a Retry-After header with the exact reset — next midnight UTC for the daily one, the start of next month for the monthly one. Not an estimate.

{
  "name": "RateLimitError",
  "code": "daily_limit_reached",
  "message": "Daily sending limit reached (100 on the free plan).",
  "fix": "Upgrade the plan, or wait for the limit to reset at 00:00 UTC."
}

The four creation caps reset on upgrade rather than on a clock, so their Retry-After is a formality — the fix string is the actionable part.

Storage

Over your storage allowance, sending is refused and so is creating an inbox.

Deleting messages frees the space back. Storage is counted from live messages, so a deleted thread stops counting as soon as it is deleted.

Message size

Suppression is not a limit

An address that hard-bounced or complained is refused at send time regardless of your plan and regardless of remaining quota. Those entries are read-only — you can see them, you cannot delete them. Continuing to mail an address that complained is what gets a whole sending domain blocked. See suppression.