Limits are enforced at two points — creating an inbox, and sending — because those are the two things that cost real money and real reputation.

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 here. An unverified key can still read, label and organize its own mail.

Confirm with POST /v0/agent/verify and sending is enabled 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

Exceeding a quota returns 429 with a Retry-After header carrying the exact reset — next midnight UTC for a daily cap, the start of next month for a monthly one. Not an estimate.

{
  "name": "RateLimitError",
  "code": "quota_exceeded",
  "message": "Daily send limit reached (100 on the free plan).",
  "fix": "Upgrade the plan, or wait for the quota to reset."
}

Inbox limits return 403 with inbox_limit_reached at creation time.

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.