Skip to main content
Data API rate limits

Keeping an eye on the limits of your Data API for the best performance.

Updated over a week ago

Rate limiting is a method of counting requests made to our server by your application. Currently, we employ one method to determine when to block incoming requests called count which is based on the number of requests received. There is currently no distinction between read or write requests. It's also important to note that each application and sandbox retains its separate limit.


To count and check the amount of requests you make, and to make sure applications don't make too many, they are being collected in something we call a bucket. Multiple buckets handle a separate limit for a specified time.

In the new setup, 3 buckets are defined; one with a refresh rate per minute, one with an hourly refresh rate, and one with a daily refresh rate. For example, there is a 1-hour bucket for the count method, which allows 2600 requests. That means that you can make 2600 requests every hour.

The bucket that refreshes most frequently will always be used first. For example, there is also a 1 minute bucket allowing 200 requests, in addition to the hourly bucket mentioned above. Incoming requests will be taken from the 1-minute bucket first. If the minute bucket is empty, the hour bucket will be used. When a minute passes, the minute bucket is refreshed and requests will be taken from that bucket first.

Why this method?

Using this method will result in favoring small requests and penalizing large requests. This makes it possible for us to fine-tune the rate limiter better for the overall use of your application while keeping the platform more resistant against attacks / accidental overloading of our platform. With this change, we are also adding remaining requests for limits to the logs so builders can identify if the limit is nearly reached. This can be found in the Logs overview.

Default limits

Bucket refresh rate


1 minute


1 hour


1 day


In sandbox applications, these limits will be divided by 2. The reason for this is that sandboxes are more likely to contain inefficient pages and are used to test new code setups, which can slow down the server. We also want to discourage sandboxes from being used in production.


What will happen if app XYZ reaches the limit? What impact does it have on that application or the whole cluster?

If app XYZ hits the limit, all the requests of that application will be blocked until one of the buckets refreshes. One of the main reasons we have the limit is to prevent impact on the application cluster your app is on.

The limits seem lower than before. Doesn’t that mean we will encounter more rate-limiting errors?

This change was introduced to reduce the amount of rate-limiting errors. Usually, these errors occur during peak times, for instance in the morning when your users start their working day. The new system is better suited to handle such peaks.

When exactly do buckets get refreshed?

All buckets refresh with the passing of time. So an hourly bucket can refresh at 13:00 or 14:00, and a daily bucket will refresh at midnight in the timezone of the server.

Does this affect my on-premise or private cloud application?

No, if your application runs on-premise or in a private cloud, the limits will be increased accordingly.

Can the limits be configured dynamically or without any downtime?

Yes, updating the limits for an app will happen without downtime.

Suppose I send 2600 requests at 13:59, exhausting the hour-rate limit. Will I be able to send another 2600 at 14:01?

Yes, but only within that hour, increased by the number of queries you are allowed to make in that 1st minute (the minute bucket)

How many requests can I do per day at a maximum?

The max requests you can do per day is: (200 * 60 * 24) + (2600 * 24) + 1150, which is a bit more than 350k requests per day

Did this answer your question?