What 200 Sends a Day Buys You: Free vs Paid Agent Accounts

Day 1: your prototype agent sends 11 emails. Day 14: it's drafting follow-ups and clears 60. Day 30: someone asks whether it can run the whole customer-onboarding sequence, and you finally go read the limits page properly. Let's do that now, before the agent forces the issue.

The free tier, in numbers

Agent Accounts — Nylas-hosted mailboxes for agents, currently in beta — ship with these defaults on the free plan:

Paid plans remove the daily send cap by default and raise storage. Retention is configurable through a policy, and a policy can also set a stricter per-account quota than the plan default — more on why you'd want that below.

What 200 sends a day actually covers

More than you'd guess. A support triage agent answering 150 tickets a day fits. A scheduling bot proposing slots and confirming bookings fits with room to spare. An internal agent that files reports, sends recaps, and nags people about reviews barely registers. Most single-purpose agents are bursty but low-volume, and 200/day absorbs the experiment phase completely.

Note the unit, though: per account, not per organization. The multi-tenant pattern the docs describe — one identity per customer, each with its own send quota and sender reputation — means a fleet of modest agents scales naturally, while a single account trying to be a broadcast cannon does not. If your plan is "one mailbox, thousands of cold emails," the free tier is telling you something about the plan.

The limits that bite before the cap

Here's the part that surprises people: the daily quota is rarely what stops a misbehaving agent. Reputation enforcement is. The usage limits page documents two rolling rates tracked per account:

• Bounce rate — under 2% is healthy; at 5% the account goes under review; at 10% sending is paused outright.
• Complaint rate — at 0.1% you're under review; at 0.5% sending is paused.

The measurement details matter. Only hard bounces — sends to addresses that don't exist — count toward the bounce rate; transient soft bounces like a full mailbox or greylisting don't. And the denominator is your recent representative send volume, not a fixed time window, so the rate stays meaningful whether the agent sends a hundred messages a day or a million.

Read that complaint threshold again. One recipient in a thousand clicking "mark as spam" puts you under review. At low volume it's even harsher arithmetic — a handful of annoyed recipients can flag a small account. And "under review" is silent to your application; you only get loud feedback once sends start failing.

Two more failure modes worth knowing: a paused account returns errors on send and does not unpause on a timer — you contact support with the fix you've applied. And hitting per-account or per-domain rate limits returns a 429, which your retry logic should back off from rather than hammer.

The instrumentation answer is the four transactional webhooks, which expose the same events the rates are computed from. Subscribing is one call:

curl --request POST \
  --url "https://api.us.nylas.com/v3/webhooks" \
  --header "Authorization: Bearer <NYLAS_API_KEY>" \
  --header "Content-Type: application/json" \
  --data '{
    "trigger_types": [
      "message.transactional.delivered",
      "message.transactional.bounced",
      "message.transactional.complaint",
      "message.transactional.rejected"
    ],
    "webhook_url": "https://youragent.example.com/webhooks/nylas"
  }'

These are your only real-time signal into the rates. Wire them up and pause your own outbound loop when bounced, complaint, or rejected events climb — you'll see the problem in your own telemetry before enforcement does it for you.

The block with no threshold

There's a second, rarer way sending stops, and it has no number to stay under. Nylas operations can apply an abuse restriction when they identify abusive or out-of-policy use. Matching sends fail immediately:

HTTP/1.1 403 Forbidden

send blocked by abuse restriction

A restriction can target a single sender address, a sender domain including its subdomains, an organization, an application, or one specific grant — and Nylas applies the most specific match. The scoping detail worth internalizing: an application-level restriction affects every Agent Account under that application, not just the one that misbehaved. One bad agent can take the fleet down with it.

Recovery is human, not automatic: contact support with the application ID, the grant ID, and an example error response. Once the restriction is lifted, sends succeed on the next attempt — no propagation delay.

When paying makes sense

The paid plan removes the daily cap, which matters once a legitimate agent routinely needs more than 200 sends from one identity. What paying does not buy you is an exemption from the bounce and complaint math — those thresholds are deliverability physics, not pricing tiers. An agent that sends garbage gets paused on any plan.

Which is why the stricter-quota policy option is more useful than it looks. An LLM agent in a malformed loop can decide to send 500 apologies in an hour; a policy capping that account at 50/day turns a reputation incident into a log line. Think of the plan limit as the ceiling and the policy as the circuit breaker you set well below it.

Do the math for your agent

Concrete next step: estimate your agent's busiest plausible day — not the average, the worst Tuesday. Under 200 sends per account? The free tier covers your entire build-and-validate phase, and your real risks are the 2% bounce and 0.1% complaint lines, so wire up the transactional webhooks first. Over 200? Decide whether that's genuinely one identity's workload or several customers' workloads that deserve separate accounts anyway.

What did your agent's worst Tuesday look like — and would 200 have covered it?