What rate limits are there?

Cronofy sets rate limits on a per application basis. This is part of a broader service delivery strategy which means we can provide a 99.99% uptime service commitment as part of the Cronofy API Service Level Agreement.

By default these limits are 50 requests per second, and 500 requests per minute.

Cronofy’s APIs are designed to minimize the number of API calls needed to achieve your scheduling goals. Because of this design approach, the default rate limits are usually sufficient for integrations with thousands of connected users.

You also don’t have to worry about any downstream rate limits imposed by calendar providers such as Google. Cronofy’s integrations with downstream providers are fully managed to ensure they are efficient and have sufficient headroom with any downstream rate limits to avoid any interruption of service.

Increasing your application’s rate limits #

When your application exceeds its rate limits, it will receive a 429 Too Many Requests status in response.

If you wish for your rate limits to be increased, you can contact support@cronofy.com and we will review your application’s usage on a case-by-case basis.

So long as your integration is using Cronofy in a reasonable way, an increase will be granted in line with the number of accounts you currently have connected, with room factored in for further growth.

We can also increase rate limits temporarily. For example to support a one-off data migration or to provide time for you to alter your integration to reduce the API calls it is making.

We’re here to help #

Whether you’re considering a new integration with Cronofy, extending an existing one, or planning for growth, we’re here to help.

We’re keen to provide guidance so that you can get the best out of our service, and so you can provide the best possible scheduling experience to your users.

So if you have any concerns or are looking for advice, please get in touch at support@cronofy.com where our support and engineering teams can provide appropriate guidance.

Common anti-patterns #

There are some common issues we see where we would not grant a long-term rate limit increase.

Polling #

We have implemented push notifications and webhooks throughout the API so you can be informed of actions and changes to data rather than polling for them.

Using an activity-driven approach will not just reduce your API request volume by 10x or more, it will also mean your system is more up-to-date as you’ll receive the data as soon as it is available rather than waiting for the next poll.

Relevant links:

Scheduled operations with no spread #

Some integrators will perform some form of sweep or similar operation on a daily or weekly basis. At small numbers these will come in under rate limits as there’s less than 500 API requests required to complete the task with API requests being made as quickly as they can be dispatched.

However, as more users are connected, these tasks grow linearly to the point where rate limits may be encountered as more than 500 API requests are required and response times mean they complete in under a minute.

When this is the case, we’ll often see integrators consume a very low portion of their rate limit 99% of the time, and then saturate it for a short period.

This issue can be avoided by spreading the work over an appropriate period, eg. spreading daily work over an hour through background jobs, or weekly work over several hours.

Not using batch operations when applicable #

We have batch operations available where the need to perform several operations at once is common.

This usually relates to onboarding situations as priming an account can require a heavy amount of upfront activity, with more incremental activity being required for the rest of the lifetime of the individual users or organizations.

For example: