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 Requests response
Retry-After header -- The response includes a Retry-After header 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 429 response, 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-After header value before retrying