Rate Limits

The Everee API uses rate limiting to protect its stability and reliability for all our customers. When clients send too many requests in a short period of time, they may receive an HTTP code 429 error, indicating that no more capacity is available to handle their requests for a short time.

  • The rate limiter allows up to 10 operations per second (read or write) by default.
  • This limit can change to help make sure our systems are protected from abuse.
  • Some API endpoints may have special limits. If an endpoint has a special limit, the limit is included in the API endpoint's reference documentation.

Handling rate limits

In order to handle rate limiting in a smooth way, your application should watch for HTTP code 429 responses from the Everee API and retry the operation if one occurs.

The simplest approach is to retry after a short delay, but since rate limits are applied to a period of time (one second, for instance), retrying a large number of failed operations after a fixed period of time can lead to repeated failures and delays or instability in your application.

A better method is to back-off retries exponentially and include a small amount of randomness (slightly more or slightly less time) on each try. This approach helps to "spread out" failed requests over a short period, which maximizes the likelihood that they will succeed quickly.

There are well-used, mature libraries available in all major languages to help implement a backed-off retry approach when working with rate-limited APIs.

Rate limit metadata

The Everee API communicates the current rate-limiting status to users using the following HTTP response headers:

Header nameExplanation
RateLimit-RemainingRemaining operations allowed in the current time window.
RateLimit-ResetNumber of seconds remaining before more operations will become available.
RateLimit-LimitMaximum number of requests allowed for each time window.
RateLimit-PolicyThe rate-limiting policy in effect for this endpoint, as defined by the IETF draft RFC.