Rate Limits
Understand rate limit tiers, response headers, and best practices for handling limits.
NevarMail enforces rate limits at both the API level and the provider level to protect your sending reputation and ensure reliable delivery.
Provider rate limits
Each provider can have its own rate limits configured at three levels:
| Level | Scope | Example |
|---|---|---|
| Per minute | Rolling 60-second window | 100 sends/minute |
| Per hour | Rolling 3600-second window | 5,000 sends/hour |
| Per day | Rolling 24-hour window | 50,000 sends/day |
Configure provider rate limits when adding or updating a provider:
POST /api/providers
{
"name": "SendGrid",
"type": "sendgrid",
"rateLimitPerMinute": 100,
"rateLimitPerHour": 5000,
"rateLimitPerDay": 50000
}Current usage
Check a provider's current usage against its limits:
GET /api/providers/:id/status{
"usageMinute": 5,
"usageHour": 120,
"usageDay": 1500,
"rateLimitPerMinute": 100,
"rateLimitPerHour": 5000,
"rateLimitPerDay": 50000
}Rate limit response headers
When making API requests, rate limit information is included in response headers:
| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests allowed in the current window |
X-RateLimit-Remaining | Requests remaining in the current window |
X-RateLimit-Reset | Unix timestamp when the window resets |
What happens when limits are reached
When a provider hits its rate limit:
- Automatic failover -- If other healthy providers are configured, NevarMail routes the email to the next available provider
- 429 response -- If no providers have capacity, NevarMail returns a
429 Too Many Requestsresponse - Retry-After header -- The response includes a
Retry-Afterheader indicating when to retry
Plan tiers
| Tier | API Requests/min | Sends/month |
|---|---|---|
| Free | 60 | 1,000 |
| Starter | 300 | 25,000 |
| Professional | 1,000 | 100,000 |
| Enterprise | Custom | Custom |
Best practices
- Implement exponential backoff -- When you receive a
429response, wait and retry with increasing delays - Monitor usage -- Check provider status regularly to stay ahead of limits
- Configure multiple providers -- Enable automatic failover when one provider is at capacity
- Use scheduling -- For bulk sends, schedule emails over a longer time window instead of sending all at once
- Respect Retry-After -- Always honor the
Retry-Afterheader value before retrying