Rate limits

Every day many hundrets of clients and developers make requests to the LiSA API. To help manage the volume of these requests, limits are placed on the number of requests that can be made. These limits help us provide the reliable and scalable API that our valued customers rely on.

The maximum number of requests that are allowed is based on a time interval, some specified period or window of time. The most common request limit interval is one minute. If an endpoint has a rate limit of 60 requests per minute, then up to 60 requests over any one-minute interval is allowed.

Past the limit, the API will return a 429 Too Many Requests error.

Rate limits header

You can check how many requests you’ve already made using the X-RateLimit-Remaining header that was sent in response to your API request. This header lists how many requests you're eligable to make before exceeding the limit. For example:

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 34
X-RateLimit-Reset: 5

In this example, 26 is the current request count and 60 is the maximum allowed size.

A 429 response will also include a Retry-After header with the number of seconds to wait until retrying your query.

Retry-After header

When a request goes over a rate limit, a 429 Too Many Requests error and a Retry-After header are returned. The Retry-After header contains the number of milliseconds to wait until you can make a request again. Any request made before the wait time has elapsed is throttled.

X-RateLimit-Remaining: 0
Retry-After: 60000

Avoiding rate limit errors

Designing your app with best practices in mind is the best way to avoid throttling errors. For example, you can stagger API requests in a queue and do other processing tasks while waiting for the next queued job to run. Consider the following best practices when designing your app:

Optimize your code to only get the data that your app requires. Use caching for data that your app uses often. Regulate the rate of your requests for smoother distribution. Include code that catches errors. If you ignore these errors and keep trying to make requests, then your app won’t be able to gracefully recover. Use metadata about your app’s API usage, included with all API responses, to manage your app’s behavior dynamically. Your code should stop making additional API requests until enough time has passed to retry. The recommended backoff time is 1 second.

For moderate to high traffic environments, we highly recommend to use the LiSA Proxy API only.

Other LiSA APIs should be consumed by background processes, that pull data from the LiSA services on demand (as per LiSA API notification) or per scheduled job. Traffic from you production environments should not be passed 1:1 to the LiSA APis.