The Naxai API uses several safeguards against bursts of incoming traffic to help maximise its stability. If you send many requests in quick succession, you might see error responses with a 429 status code.

API limiters

We have several limiters in the API, including a rate limiter and a concurrency limiter.

Treat the limits as maximums, and don’t generate unnecessary load. To prevent abuse, we might reduce the limits.

For advice on handling 429 errors, see Handling limiting gracefully. If you suddenly see a rising number of rate-limited requests, contact Naxai Support.

You can request a limit increase to enable a high-traffic application by contacting Naxai Support. If you’re requesting a large increase, contact us at least 6 weeks in advance.

Rate Limiter

The basic rate limiter restricts the number of API requests per second as follows:

Transactional SMS API : 200 operations per second
Transactional Voice API : 50 operations per second
Transactional RCS API : 50 operations per second
Transactional Email API : 200 operations per second
Contact API (Update and insert contacts): 100 operations per second
Other API endpoints : 20 operations per second

Rate Limit Response Headers

Naxai response includes headers related to the Rate Limit

{
X-RateLimit-Limit: "The current limit of the API allowed in one minute"
X-RateLimit-Remaining: "The remaining available requests within a minute"
X-RateLimit-Reset: "The date and time when remaining limit is reset" 
}

Handling Limiting Gracefully

A basic technique for integrations to gracefully handle rate limits is to watch for 429 status codes and build in a retry mechanism. The retry mechanism should follow an exponential backoff schedule to reduce request volume when necessary. We would also recommend building some randomness into the backoff schedule to avoid a thundering herd effect.

You can only optimize individual requests to a limited degree, so an even more sophisticated approach would be to control traffic to Naxai at a global level, and throttle it back if you detect substantial rate limiting. A common technique for controlling rate is to implement something like a token bucket rate limiting algorithm on the client-side. Ready-made and mature implementations for token bucket are available in almost any programming language.