Now let’s talk about rate limits.
The API you’re connecting to may have limits on how frequently you can make requests. If you need to set these up within your connector, you can do this with a rate limits page.
All you have to do is click on rate limit.
And then you can choose how many requests you send per second. Or you can choose how many seconds waits between requests, it depends on how the API has it setup.
Now I have this just set to one match requests per second one, when I’m done, once I’ve set it up according to the documentation, all I have to do is hit Save.
And there we go. Now I have rate limits across all the methods within this connector, so that I can only make a single request per second, everything will be queued up and that way, I won’t hammer the system or face of potential 429 error.
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.