Rate Limits

The Krayon API employs several safeguards against bursts of incoming traffic to help maximize its stability. Users who send many requests in a short period of time may experience error responses that appear as status code 429.

We have several limiters in the API, including a rate limiter that limits the number of requests received by the API within any given second.

For most APIs, Krayon allows up to 120 operations per minute for each environment, test, or production.
This means that each user is allowed to make a maximum of 120 requests per minute to our API. Exceeding this limit will result in receiving rate-limiting errors. It is important to ensure that your application adheres to this rate limit, to maintain a stable and reliable service for all users.

We recommend implementing appropriate rate-limiting measures within your application to avoid reaching the global limit.

Treat these limits as maximums and don’t generate unnecessary load. See Handling limiting gracefully for advice on handling 429s.

We may reduce limits in the future.

Handle Throttling Gracefully

A basic technique for integrations to gracefully handle throttling is to monitor 429 status codes and build a retry mechanism (like a circuit breaker). The retry mechanism should follow an exponential backoff schedule to reduce request volume when necessary. We 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 a more sophisticated approach would be essential to control traffic to Krayon on a global level, and throttle it back if you detect substantial rate limiting.

A common technique for controlling rate is to implement a mechanism such as a token bucket rate limiting algorithm on the client side. Ready-made and mature implementations for token buckets are available in almost any programming language.