Skip to main content
There are no rate limits on requests sent to Chift.
You can make as many API calls as needed. Chift does not impose any internal restrictions. Any limitations you may encounter come directly from the connected third-party software (connectors).
⬇️ IMPORTANT ⬇️
Connector-specific rate limits
If a connector enforces rate limits, they are documented on the connector’s page. Check the full list here: Chift Connectors Documentation.
Fair usage policyWhile Chift does not impose strict rate limits, we expect you to follow a fair usage policy.
We actively monitor traffic patterns to ensure platform stability and equitable access for all users.
In case of excessive or abusive usage that impacts overall performance, Chift reserves the right to temporarily throttle or block requests until the issue is resolved.

​
How Chift handles rate limits

Even though Chift doesn’t define its own limits, we handle rate limits from connectors gracefully to avoid unnecessary errors and ensure stable synchronizations. We distinguish between two main types of rate limits:

​
1. Daily rate limits

When a connector enforces a daily limit, Chift cannot bypass it.
In such cases, we return a clear error specifying:
  • the type of rate limit, and
  • the remaining time before it resets.
This lets you retry the operation later, once the limit expires.

​
2. Short-term (minutely) rate limits

For short-term rate limits, Chift automatically retries the request to maximize the success rate. By default:
  • Chift performs up to 5 retries,
  • with exponential backoff between attempts: 1s, 2s, 4s, 8s, and 16s.
This helps smooth out temporary rate spikes without immediately failing the process.
If all retries ultimately fail, Chift returns an error with a specific code and message indicating a rate limit issue, and includes a Retry-After header with the number of seconds to wait before retrying.When the connector does not provide clear information about rate limits, the error may appear as a generic synchronization failure and the Retry-After header may be absent.

​
Custom handling

For some connectors, we apply custom retry logic based on the additional information available in their documentation or error messages.
For example, when a “retry-after” value is provided, Chift respects it. This retry logic is fully abstracted from your side. You don’t need to handle it manually.
Its purpose is simply to maximize reliability and reduce unnecessary failures caused by rate limits.

​
Retry-After header

When Chift returns a 429 error (rate limit reached), the response includes a Retry-After header:
The value is an integer representing the number of seconds to wait before retrying. Chift computes this value from the connector’s own rate limit information (reset timestamp or retry delay). Use this header to schedule your retry at the correct time instead of relying on fixed backoff intervals.