Rate limits
The per second request limit, the rate limit headers, and the recipients per minute budget for sends.
Notix limits how fast a team can call the API, and how many people a team can send to each minute. Both limits answer 429 when you go over.
Requests per second
Each team has a per second request limit. It is two requests a second, unless it has been raised for your account.
Over the limit, the API answers 429 RATE_LIMITED with a Retry-After header in seconds.
{
"error": {
"code": "RATE_LIMITED",
"message": "Rate limit exceeded. Try again in 2 seconds."
}
}
Requests per minute and per day
Behind the per second limit, each team also has two ceilings. Normal use never meets them. You can hold your per second rate all minute, but a whole day at the full rate goes past the daily ceiling on Free.
| Ceiling | Default | Resets |
|---|---|---|
| Per minute | A full minute at your per second limit: 120 at the default of 2 a second. | 60 seconds after the first request in the window. |
| Per day | 50,000 requests on Free, 2,000,000 on paid plans. | Midnight UTC. |
If your per second limit has been raised, both ceilings rise with it. For example, at 20 a second the ceilings are 1,200 a minute and ten times the daily figure. Requests refused by the per second limit do not count towards either ceiling. MCP calls count towards the daily ceiling; their per minute limit is described below.
These never count towards either ceiling: verification and one-time code requests (/v1/verify), and GET /v1/auth/check.
These ceilings are being introduced in stages. For now Notix measures them and refuses nothing; this page will say when they are switched on.
Over a ceiling, the API answers 429 RATE_LIMITED with a Retry-After header in seconds and a reason: RATE_LIMIT_MINUTE or RATE_LIMIT_DAY.
{
"error": {
"code": "RATE_LIMITED",
"message": "Daily API request limit reached. It resets at midnight UTC, in 3600 seconds."
},
"reason": "RATE_LIMIT_DAY"
}
If Notix cannot count requests for a moment, a request that writes or sends answers 503 SERVICE_UNAVAILABLE. Try again shortly.
Rate limit headers
Every authenticated response carries three headers.
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Requests allowed in the window. |
X-RateLimit-Remaining | Requests left in the window. |
X-RateLimit-Reset | When the window resets, as a Unix time in seconds. |
Recipients per minute
Sends also spend a budget of recipients per minute. The budget is 6,000 at the default limit, or 3,000 for each request per second your account allows, whichever is higher.
Every distinct address across to, cc and bcc counts once. A send over the budget answers 429 RATE_LIMITED with Retry-After, and sends nothing.
Plan and key limits
Plan send limits are separate from the rate limit, and also answer 429.
The owner can also set limits on one key: requests per minute, daily or monthly sends, and SMS per day. Past one of those, the API answers 429 LIMIT_EXCEEDED. Read this key's limits shows them.
Warm-up and probation limits
A new domain can send 200 emails a day for its first 14 days, and a domain that was paused and then resumed can send 500 a day for 7 days. Every send from that domain counts. Broadcasts and automations can use 80% of the day, so the rest is kept for transactional email.
A send over that limit answers 429 RATE_LIMITED with details.reason set to DOMAIN_WARMUP_LIMIT. Nothing was sent. The limit resets at midnight UTC. Automations wait and carry on, and broadcasts pick up where they stopped the next day. See Warm-up.
{
"error": {
"code": "RATE_LIMITED",
"message": "news.acme.com is warming up: it can send 200 emails a day for now (160 of them marketing). It resets at midnight UTC.",
"details": { "reason": "DOMAIN_WARMUP_LIMIT" }
}
}
Scheduled email limit
You can schedule up to 7 days of your daily limit for later. For example, a team that can send 500 emails a day can have 3,500 waiting to send. Past that, a send with scheduledAt answers 429 RATE_LIMITED with details.reason set to SCHEDULED_BACKLOG_LIMIT, and nothing is scheduled. Wait for some to go out, or cancel some, then schedule more. Emails going out now are not affected.
An email that waits more than 7 days behind a hold on its domain (a pause, a warm-up or probation limit, unfinished DNS for broadcasts, or a broadcast hold) is not sent. It is marked failed with the reason, so you can see it and send it again.
{
"error": {
"code": "RATE_LIMITED",
"message": "You already have 3,500 emails scheduled for later, which is 7 days of your daily limit. Wait for some to send, or cancel some, then schedule more.",
"details": { "reason": "SCHEDULED_BACKLOG_LIMIT" }
}
}
The MCP endpoint
The hosted MCP endpoint allows a short burst, ten calls a second at the default limit. It allows no more calls per minute than your REST limit allows, and its calls count towards the daily ceiling.
The Notix MCP server waits out a 429 whose Retry-After is 30 seconds or less. A longer wait, or the daily ceiling, comes back to your agent at once as an error that says when to try again.
Staying under the limit
- Use batch sending to send many emails in one request.
- On a 429, wait for
Retry-After, then retry with backoff. - Need a higher limit? Contact us and say what you send.