Rate limits
Celigo protects shared infrastructure with a leaky-bucket rate limit applied per account. The limits are generous for normal automation but you can and will hit them if you run unthrottled loops.
The limit
Bucket size
1,000 requests
Refill rate
300 requests per second
Steady-state
≈ 1,080,000 requests per hour per account
Requests consume one token. Bursts up to 1,000 requests are allowed as long as the bucket refills to absorb them.
What you get back
When the bucket is empty, the API returns:
HTTP/1.1 429 Too Many Requests
Retry-After: 2
Content-Type: application/json
{
"errors": [
{
"code": "rate_limited",
"message": "Too many requests. Retry after 2 seconds."
}
]
}Retry-Afteris a whole number of seconds — wait at least that long before your next request.Never parse the
messagestring; act on the status code and the header.
Correct back-off pattern
Key points:
Honor
Retry-After. Don't guess; the server tells you what to use.Add a small jitter (≤ 250 ms) so parallel workers don't re-collide on the second.
Cap retries. Five is a reasonable upper bound. If you're still being throttled after five retries, you're overloading the account — throttle the source, don't send more requests.
Never exponentially retry past
Retry-After. Exponential back-off is for 5xx responses. On429 Too Many Requests, the server already told you exactly how long to wait.
How to stay under the limit
Batch where the API supports it. Creating 100 imports in a single
POSTis one request; looping 100POSTs is 100 requests.Use
fields=to shrink pages, then use biggerlimit=values. Fewer round-trips for the same data.Cache reads. Configuration (integrations, flows, connections) rarely changes minute-to-minute. Refresh on TTL, not on every use.
Throttle at the source, not at the edge. If you're syncing an external system into Celigo, rate-limit the source crawl rather than letting it overload the API.
Separate limits
Flow execution has its own internal rate limits separate from API calls. They're described in flow concurrency. Running thousands of flows concurrently doesn't count against the API bucket — it counts against flow concurrency, which is sized differently.
Outbound HTTP connections (flows hitting external systems) respect rate limits set per-connection (
rateLimiton the HTTP connection object). Those are your limits to configure.
Monitoring
Audit logs record every API write. Watch for unexpected spikes by source.
Account usage is viewable in the UI under Account → API usage.
If you need visibility inside a workload, log every
429 Too Many Requestsresponse and track the latency distribution — a sudden jump in p99 often means you're headed toward being throttled.
Last updated
Was this helpful?