Skip to main content
200 requests per minute, per connector. The limit is keyed to the connector_token in the request header, not to your API key. Each of your end users therefore has an independent budget, and one customer’s traffic cannot exhaust another’s. It applies across all endpoints — every request carrying the same connector token counts against the same 200. Requests beyond the limit are rejected with 429 Too Many Requests until the window resets.

Response headers

Every response carries the first three. Retry-After appears on 429 only. Retry-After is authoritative — prefer it over computing a delay from X-RateLimit-Reset, and over a fixed sleep. Watching X-RateLimit-Remaining on successful responses and slowing down before it reaches zero is cheaper than recovering from a 429.

A 429 response

The other limit, which is not yours

Bindbee’s 200 per minute governs how fast you can read. The source systems have their own limits, usually far tighter, and those govern how fast Bindbee can sync. You never see a 429 from that second limit — it surfaces as sync duration instead, and it is the main reason cadence is measured in hours rather than minutes. Neither you nor Bindbee can configure it away. See Sync frequency.

Higher limits

Custom limits are available for enterprise use cases. Contact support@bindbee.dev or your account manager.