Cyclr allows you to enter any limitations on the frequency with which API calls will be accepted by an application. These settings can be made for the Connector overall and, if required, different rates can be set for specific methods.
If the appropriate values are set, Cyclr will not make any calls that would cause the rate limit to be exceeded. Instead, those requests are queued.
Why would you want to limit the number of requests per second?
Some APIs enforce limits on the number of requests every second/minute/hour from each of their users. You will need to enforce these rules in your Connector to avoid potential 429 errors, otherwise you may receive errors because you have gone over their limits.
Adding Rate Limits
Rate limits allow you to limit the number of requests per second. To add rate limits, go to the Rate limit tab, and click on the “Add Rate Limit” button.
You can choose how many requests you send per second (MaxRequestsSecond), or how many seconds between requests (SecondsBetweenRequests), depending on how the API that you are working with has it set up. You should be able to find this information in the API’s documentation.
Remember to save your Connector every time you make changes.
November 2024 Update: Rate Limits have been improved
Rate Limits created on either Custom Connectors or Library Connectors before mid-November 2024 will continue to function as described above. Rate Limits created after then have improved functionality.
Cyclr’s Rate Limits can now be specified in two ways, giving you the option to choose which one better fits the limits of the API you’re working with: Maximum Requests per Time Frame or Time between Requests.
Maximum Requests Per Time Frame allows you to specify the number of calls Cyclr can make within a set period of time. This time frame can be Seconds, Minutes, Hours, days or Months.
Time Between Requests allows you to have Cyclr wait between each call, with the smallest available time frame being Milliseconds.
When Multiple Rate Limits Apply
With the improved Rate Limits, more than one Rate Limit can be true at the same time. This can help with APIs that provide both a daily limit and a “burst limit” that restricts the daily limit from being used in a short amount of time.
For example, you can limit the number of Requests as 100K per Day, but only allow 100 requests per Minute by implementing them as two separate Connector-level Rate Limits:
- Connector-level Rate Limit for “Maximum Requests Per Time Frame” of 100,000 Requests/24 hours.
- Connector-level Rate Limit for “Maximum Requests Per Time Frame” of 100 Requests/1 minute.
If Rate Limits are defined at both the Connector-level and Method-level, Cyclr will retrieve all the related limits when executing a Connector Method and use the most restrictive limit.
Overriding Connector-level Rate Limits
Method-level Rate Limits have an additional option called “Override Connector Rate Limits?“
When enabled, Cyclr will ignore any Connector-level Rate Limits for that particular Method, and only use Rate Limits defined at the Method-level. If no Rate Limits have been set at the Method-level, no rate limiting will occur, resulting in Cyclr making calls to that Method as quickly as it can.
Calls to Methods with the “Override Connector Rate Limits?” option enabled won’t count towards any other Rate Limits of the Connector, so it won’t impact the usage other Methods.
Custom “Retry After” Header
With some APIs, if they receive requests too quickly to process, they may return “429 Too Many Requests” errors. These errors usually include a Retry-After HTTP Header which contains a time value indicating when it’ll start accepting requests again which Cyclr will automatically use.
However, if an API uses a different HTTP Header for this, you can provide its name in the Custom Retry After Header field. The value is case-sensitive so must exactly match the name of the HTTP Header that API uses.
