Home > Develop > Documentation > API > OGC API > Rate Limiting

Rate Limiting

Rate Limiting

In order to assure stability of the system and to guarantee desired performance for all users, we have to protect it against deliberate attacks or runaway scripts. Every request arriving into our system will therefore go through a rate limiting filter. As long as the agreed upon request policies are conformed, responses by our services shall be delivered in timely fashion. If number of requests issued violates any of the agreed upon policy, response with HTTP 429 status will be returned.

Rate Limit Policies

Every user is granted a rate limit policy based on his account type defined in our pricing plan. We are able to adjust rate limit policies for each individual user so do contact our Support for specific requirements. Please note that each user might have multiple rate limiting policies. You can see your current rate limits in the Sentinel Hub Dashboard.

Important: To conform to our rate limiter, you need to pass each of your rate limit policies. Imagine you had a policy of 20 requests per second and a policy of 10000 request per day. By issuing 100 requests in one second only 20 would pass. Even though you have a limit of 10000 requests per day, 80 requests would violate the “per second policy” and thus be rate limited.

Tokens do not accumulate: If you have a rate limit policy with 20 request per second and you don't consume any token for a longer period you are still able to do just 20 requests in the next second.

Response Headers

All requests going through rate limiting include headers to allow for programmatic adaption to Rate Limiting:

curl -I http://services.sentinel-hub.com/ogc/wms/{instanceId}
HTTP/1.1 429 Too Many Requests
Date: Mon, 22 Oct 2018 07:07:41 GMT
Retry-After: 55408
X-RateLimit-Remaining: 0
X-RateLimit-ViolatedPolicy: {"samplingPeriod": "PT1M", "limit": 1}
  • Retry-After: Time until next token is available in millisecond
  • X-RateLimit-Remaining: Number of tokens remaining for usage
  • X-RateLimit-ViolatedPolicy: Policy that has been violated

Note: X-RateLimit-ViolatedPolicy is only returned in rate limited (HTTP 429) responses.

Try it out

We have set-up an instance with a very small limit of 10 requests per minute, so that you can try it out and use it for integration purposes:

Note that many people may be using it at the same moment so there is a chance that it will be over the limit more or less all the time. Its purpose is to evaluate response headers anyway.

Tips to Avoid Being Rate Limited

  • Caching
    Store API responses that you expect to use a lot. For example, don’t call same requests on every page load but try to store responses in local storage.
  • Request only what you need
    Be defensive in fetching and try to request only the data that you actually need.
  • Exponential backoff
    When a rate limit has been exceeded, we recommend implementing retry with an exponential backoff. An exponential backoff means that you wait for exponentially longer intervals between each retry of a single failing request.

Implementation phase

To avoid inconvenience for our users, limits will be introduced in three stages:

  • Beginning of November 2018 - technically implemented but limits set so high that they should not affect almost anyone
  • Mid November 2018 - limits are enforced to expected levels for all newly established accounts
  • Beginning of January 2019 - limits are enforced for all accounts