Agent Account usage limits

Agent Account usage is limited per plan across a few areas: how many accounts you run, storage, bandwidth, how much each account sends, message and attachment size, and retention. This page lists the limits across the Free, Essentials, Pro, and Enterprise plans, explains what counts toward each, and covers what your application sees when it hits one. For plan details and pricing, see Nylas pricing; to set stricter per-account caps yourself, use Policies, Rules, and Lists.

Plans and limits

Agent Account limits are set per plan at the organization level, so they apply across every app in your organization. There are four plans: Free, Essentials, Pro, and Enterprise. The table lists what each one allows; for current plan details and pricing, see Nylas pricing. You can set stricter per-account caps with a policy.

Limit	Free (hard cap)	Essentials (hard cap)	Pro	Enterprise
Agent Accounts (per month)	3	10	50 included; overages billed	Custom
Storage	3 GB	10 GB	50 GB included; overages billed	Custom
Bandwidth (per month)	3 GB	10 GB	50 GB included; overages billed	Custom
Emails sent (per month)	3,000	10,000	50,000 included; overages billed	Custom

Agent Accounts, storage, bandwidth, and monthly emails are totalled across the whole organization. On Free and Essentials, all four are hard caps with no overage; Pro includes the same four resources with an overage rate beyond the included amount, and Enterprise is negotiated per contract.

The limits below apply the same way across every paid plan (Essentials, Pro, and Enterprise) unless noted:

Limit	Free (hard cap)	Essentials, Pro & Enterprise
Emails sent (per account, per day)	20	Unlimited
Message size (inbound)	50 MB	100 MB
Message size (outbound)	25 MB	25 MB
Attachment size (inbound)	50 MB	50 MB
Attachments per message (inbound)	10	20
Inbox retention	30 days (fixed)	Configurable
Spam retention	7 days (fixed)	Configurable
Rules	5	30
Lists	10	50

The daily send cap and retention apply to each account. The attachment-size and attachment-count limits apply to inbound mail; outbound messages have a single size limit, covered under Sending limits.

The four metered resources

Every plan meters four resources, and the table above sets the ceiling for each. Here is how each one is charged:

Agent Accounts is a cumulative charge for the billing month. Every account that was active when the month started, plus every account created during the month, counts toward it. Deleting an account doesn’t subtract it from the current month, but a deleted account isn’t counted in the following month.
- Example: you start March with 20 accounts, create 10 more, and delete those 10 before the month ends. March is charged on 30 accounts. April starts at 20.
Storage is a point-in-time charge, read at the end of the billing period. Deleting messages or running a clean-up before the period ends lowers that period’s storage cost.
Bandwidth is a cumulative charge on all data your Agent Accounts move in and out: attachments you upload, and the mail your accounts send and receive.
- A message sent to many recipients counts once, not once per recipient. A 100 MB attachment sent to 10 people is 100 MB; 10 separate 100 MB messages are 1 GB.
Emails sent is charged on the total number of messages your Agent Accounts send in the month, including calendar invitations.
- Overage is priced in volume bands, so the rate per 1,000 messages drops as your monthly volume grows.

How hard caps and overages work

What happens at a limit depends on the plan. On Free and Essentials, every limit is a hard cap: when you reach one, that activity stops until the period resets, so sends return HTTP 429, storage-bound actions return 403, exhausting the bandwidth budget pauses inbound delivery, and once the month’s Agent Account count reaches the cap you can’t create another account until the next month, even if you’ve deleted some. On Pro and Enterprise, the four metered resources can run past their included amounts and the overage is billed instead of being blocked. The daily send quota resets at 00:00 UTC; the monthly count and bandwidth budget reset on the first of each calendar month.

Each resource is charged as described in the four metered resources. The rules are the same on Pro and Enterprise; only the included amounts and rates differ.

Resource	Pro: included	Pro Monthly overage	Pro Annual overage	Enterprise	Charged as
Agent Accounts	50	$0.40 / account	$0.20 / account	Per contract	Cumulative
Storage	50 GB	$0.40 / GB	$0.20 / GB	Per contract	Point-in-time
Bandwidth	50 GB / month	$0.80 / GB	$0.50 / GB	Per contract	Cumulative
Sent emails	50,000 / month	from $0.80 / 1,000	from $0.70 / 1,000	Per contract	Total sent, volume bands

Essentials has no overage on these resources; usage is hard-capped instead. Enterprise plans meter the same four resources the same way, with included amounts and overage rates set in your contract, generally following the Pro Annual structure; contact your Nylas account team for your figures. Overage rates shown are the current published Pro rates; for the latest rates and any volume pricing, see Nylas pricing.

Sending limits

How much an Agent Account can send is bounded by volume over time, by how fast you send, by the number of recipients on a message, and by message size. The three volume limits each run on their own counter and return HTTP 429 when exceeded: a per-account daily quota, an organization-wide monthly send allowance, and a monthly bandwidth budget. A per-second rate limit caps how fast your organization can send, applied separately to your Sandbox and production applications; short bursts above it are queued and sent shortly after instead of rejected. Two per-message limits also apply: a recipient limit and a total size limit.

Per-account daily send quota

Every Agent Account has a daily send quota that resets at 00:00 UTC. When an account goes over it, send requests return HTTP 429 with the type too_many_requests until the counter resets. Nylas reserves the quota before sending and releases it if the send fails, so failed attempts don’t count against you. The Free plan caps each account at 20 sends per day; Essentials, Pro, and Enterprise have no daily per-account cap. You can set a stricter quota through a policy. If a single message has more recipients than the account’s daily limit, the send returns HTTP 400 instead of 429, because waiting for the counter to reset wouldn’t let it through.

The quota counts every message an account sends, across these paths:

Messages sent with POST /v3/grants/{grant_id}/messages/send.
Drafts you send.
Mail submitted over SMTP by a connected mail client.
Calendar invitations, updates, and cancellations sent with notify_participants (see How Agent Account calendars work).

Monthly send allowance and bandwidth

Beyond the per-account daily quota, your organization shares a monthly allowance that resets on the first of each calendar month (UTC): a total count of messages sent and a bandwidth budget for the data moved in and out. The send count tracks outbound messages only, while bandwidth covers both directions. On Free and Essentials, exceeding either returns HTTP 429 on send, and exhausting the bandwidth budget pauses inbound delivery until the month resets. On Pro and Enterprise, the extra is billed as overage instead of being blocked. See the four metered resources for how bandwidth counts a message sent to many recipients.

Per-second send rate limit

Beyond the daily and monthly quotas, Agent Account sends are throttled by a per-second rate limit. Like your other limits, it applies at the organization level, and it’s pooled by application environment: all of your organization’s Sandbox applications share a combined 1 request per second, and all of your non-sandbox applications share a combined 5 requests per second. The cap is across every Agent Account and app of that environment in your organization.

Short bursts above this rate are permitted. When you send faster than your limit, Nylas holds the extra messages in a short queue and sends them in order as capacity frees up, instead of rejecting them. Queued messages usually go out within seconds. A message at the back of a full queue can take up to 90 seconds. A queued send returns HTTP 202 Accepted instead of 200. See Send queueing for how to track a queued message.

If you keep sending faster than your limit, the queue fills up and send requests return HTTP 429 with a Retry-After header that gives the number of seconds to wait before you retry. The limit is measured over a rolling one-second window. If your application needs a higher sustained rate, contact Nylas support to have your limit reviewed.

Send queueing

Send queueing is how Agent Accounts handle a burst of sends above the per-second rate limit: Nylas accepts the extra messages, holds them for a short time, and sends them in the order it accepted them. Queued messages usually go out within seconds. A message at the back of a full queue can take up to 90 seconds. Your application gets HTTP 202 Accepted right away and learns the outcome from webhooks.

These send requests can be queued:

POST /v3/grants/{grant_id}/messages/send without send_at, in JSON or multipart form.
POST /v3/grants/{grant_id}/drafts/{draft_id}, which sends a draft.
A scheduled message when its send_at time arrives.

What the 202 response contains

A queued send returns the same message or draft object as a 200, including the message id and thread_id. Use that id to match the webhooks for this message. The response never includes the headers array, even when you pass fields=include_headers or fields=include_basic_headers, because the final Message-ID isn’t set until the message is sent. If you retry a request with the same Idempotency-Key, you get the same 202 and Nylas doesn’t queue a second copy.

Track a queued message

Subscribe to message.delivered to confirm that a queued message went out. It fires when the recipient’s mail server accepts the message, with the same message id that the 202 returned.

Once it’s sent, a queued message fires the same webhooks as any other Agent Account send, such as message.created and the deliverability webhooks. The one addition is message.send_failed, which fires when Nylas can’t send a queued message or draft.

A queued message doesn’t appear when you list or search messages until it’s sent. If Nylas can’t send it, for example because it’s still waiting after 90 seconds, message.send_failed fires and the message doesn’t count against your send quotas. A failed message sent with /messages/send isn’t kept. A failed draft stays in your Drafts folder, so you can fix it and send it again.

Cancel a queued message

While a message waits in the queue, you can cancel it: delete it with DELETE /v3/grants/{grant_id}/messages/{message_id}, or delete a queued draft with DELETE /v3/grants/{grant_id}/drafts/{draft_id}. A cancelled message isn’t sent and doesn’t count against your send quotas. Once Nylas starts sending the message, the delete returns HTTP 409. A queued message or draft can’t be changed: updating it or sending the draft again also returns 409.

Recipients per message

A single outbound message should address at most 50 recipients total across the to, cc, and bcc fields. To reach a larger audience, split the send into batches of 50 or fewer. Each batch still counts toward your daily and monthly send limits. If a message exceeds the recipient limit, it can be rejected by the sending infrastructure and surfaced as a send error.

Message size

Every outbound message must be 25 MB or less in total raw MIME. Raw MIME is the encoded message including its headers, body, and all attachments. This is the only size limit on sending: it’s the same on every plan and every send path, and separate from the plan-based size and attachment limits that apply to inbound mail (shown in the table above). Messages over the cap are rejected at send time.

How storage is used

Your storage limit is the most data your organization can hold at rest at any one time, enforced both per account and across the whole organization. It includes nearly everything an account keeps: received messages, the copies of messages it sends, attachments, drafts, and contact and calendar data. Deleting messages frees the space back up. On Free and Essentials, reaching the cap blocks both sending and receiving with HTTP 403 until you free space; on Pro and Enterprise, storage past the included amount is billed as overage.

You can set a per-account storage cap below your plan maximum through a policy. See the configurable limits table for that field and the other per-account limits.

Retention

Retention controls how long mail stays in an Agent Account before Nylas deletes it, and it differs for the inbox and the spam folder. On the Free plan, inbox mail is kept for 30 days and spam for 7 days, and these are fixed. On Essentials, Pro, and Enterprise, retention is configurable per account (see configurable limits); spam retention must always be set shorter than inbox retention so junk doesn’t sit against your storage.

Retention runs as a periodic prune that deletes messages older than the limit, and the spam period must be shorter than the inbox period. You can shorten either window per account with a policy, down from the plan default. See the configurable limits table for the policy fields.

Other limits

Beyond the plan ceilings in the table above, a policy can set stricter per-account caps for attachment size and count, inbound message size, the number of messages received per day, and retention. The configurable limits table lists all nine policy fields and what each one controls.

Policies can also restrict the allowed attachment MIME types. Configure the attachment allowed-types policy field to allow or block specific types. An empty list allows every type, and wildcards such as image/* match a whole category.

When Nylas pauses or blocks sending

Separately from quotas, Nylas can stop Agent Accounts from sending in two cases that protect the wider sending ecosystem: a reputation-based pause on a sending domain, triggered by a high bounce or complaint rate, and an abuse block applied by Nylas operations. Both are recoverable, and they surface differently in your application. For sender-reputation hygiene that applies to any mailbox, see Improving email deliverability and Email deliverability for Agent Accounts.

Bounce and complaint thresholds

Nylas tracks bounce and complaint rates per sending domain, not per Agent Account, so every Agent Account on a domain shares the same rates. When those rates stay high, sending can be paused for the whole domain until you fix the cause. The deliverability webhooks report the same delivery, bounce, and complaint events that the rates are based on.

How the rates are measured

Window. The rates cover a rolling 24 hours of sending, measured against the recipients you sent to in that time.
Bounces. Only hard bounces count. A hard bounce is a permanent failure: the address doesn’t exist, the recipient’s mail server rejects the message by policy, or the address bounced before and is no longer delivered to. Sending to an address that already bounced counts as another hard bounce. Soft bounces, such as a full mailbox, a temporary rejection, or greylisting, don’t count.
Complaints. A complaint is a recipient clicking Mark this email as spam or moving your email to the junk folder. Complaints count together with bounces and weigh more than a bounce, so a few complaints raise your rate more than the same number of bounces. Complaints are counted only for recipient domains that send complaint feedback to senders.
Low volume. A domain with very little sending isn’t measured, so one bounce on a handful of messages doesn’t pause it.

Recommended rates

Keep each sending domain at or below these rates over any 24-hour period:

Rate	Recommended
Hard bounce rate	Under 2%. Stay below 5%.
Complaint rate	Under 0.1%

These are targets, not the exact points where sending pauses. Nylas doesn’t publish those levels and can change them. A domain whose rates stay well above these targets can be paused.

What a pause looks like to your code

Nothing changes for your application until a pause. When sending is paused for a domain, send requests from every Agent Account on that domain fail right away. Here are the responses you may see:

Status	Response body	Cause
`400 Bad Request`	`"your email domain is disabled"` or `"sending is disabled for this domain"`	Sending is paused for the `from` domain.
`403 Forbidden`	`"sender domain is not verified for sending"`	The `from` domain isn’t verified. Finish verification in Setup domains.
`429 Too Many Requests`	`"rate limit exceeded"`	A per-account or per-domain rate limit was hit — back off and retry, or raise quotas via policy. When the response includes a `Retry-After` header, wait that many seconds before you retry.

Staying inside the envelope

Validate recipient addresses before sending. Stop sending to an address after it hard-bounces: sending to it again counts as another hard bounce.
Honor unsubscribe and list-removal requests immediately. Complaints weigh more than bounces and the recommended complaint rate is 0.1%, so a few spam reports can push a domain past it.
Use double opt-in for any list you care about.
Wire up the four deliverability triggers (message.bounced, message.complaint, message.delivered, and message.rejected) and pause your own outbound logic if bounced, complaint, or rejected rates start climbing — you’ll see the problem in your own telemetry before Nylas tells you about it.
Authenticate your sending domain. Missing or misconfigured DKIM, SPF, or DMARC shows up as elevated bounces from recipient servers that refuse the mail outright.

Abuse-restriction blocks

Separately from reputation pauses, Nylas may apply an abuse restriction to a sender, sender domain, organization, application, or grant when our operations team identifies abusive or out-of-policy use. Active restrictions reject matching sends immediately. There is no threshold to stay under — restrictions are applied because of a signal we treat as abuse, not because of a quota you can wait out.

What you’ll see

What the block can be scoped to

A restriction can target any of the following. When more than one matches, Nylas applies the most specific, with specificity running from most to least specific in this order:

A single sender email address (most specific)
A sender domain, including its subdomains
An organization
An application
A specific Agent Account grant (least specific)

A more sender-specific restriction wins over a broader one: a restriction on a single sender address takes precedence over one on the whole domain. A restriction at the application level affects every Agent Account grant under that application, not just the one you happened to send from.

How to recover

Contact support. Include the application ID, the grant ID, and one example error response so the abuse team can locate the restriction and walk through what triggered it.
Once the underlying issue is resolved, Nylas operations disables the restriction. Send requests start succeeding on the next attempt — there’s no propagation delay you have to wait through.

What’s next

Send an email — core send mechanics for any grant
Sending errors — error-code reference across the Email API
Policies, Rules, and Lists — plan-tier send quotas and outbound rules
Agent Account webhook notifications — schemas for message.delivered, message.bounced, message.complaint, and message.rejected
Improving email delivery — sender-reputation hygiene that applies to every mailbox
Setup domains — DKIM, SPF, and DMARC setup for custom domains