Why am I getting 429 errors?

What limits your API requests, what the rate-limit headers tell you, and how to back off correctly.

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. The provider endpoints below are browser-session only — an API key gets 403 SESSION_ONLY; from an API key, GET /api/v1/providers lists your providers read-only:

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:

429 response -- NevarMail returns a 429 Too Many Requests response
Retry-After header -- The response includes a Retry-After header indicating when to retry

API request rate limit

API requests authenticated with an API key are rate-limited to 60 requests/minute, applied the same way regardless of your plan. This limit can be raised for an individual API key on request -- it is not tied to your plan's emails_per_month allowance.

Monthly send allowances are set per plan and can be changed for your account by an administrator, so they are not listed here — see Pricing for the current plans, and your billing settings for the allowance that applies to you.

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
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