Rate Limits

Overview

Bindbee enforces rate limits to ensure fair usage and maintain service reliability for all customers. All API endpoints are subject to rate limiting to protect our infrastructure and provide consistent performance.

Rate Limit Policy

Current Rate Limit: 200 requests per minute per connector The Bindbee API enforces rate limits based on the connector (as indicated by the connector_token in the request header). This means each of your end users has their own independent rate limit of 200 requests per minute. This rate limit applies across all endpoints and is enforced strictly. Once a connector reaches the limit, subsequent requests for that connector will be rejected with a 429 Too Many Requests error until the rate limit window resets.

Rate limits are applied per connector token, not per API key. This ensures fair resource allocation across all your end users’ connections.

Rate Limit Headers

Bindbee includes rate limit information in the response headers of every API request, allowing you to monitor your usage and implement appropriate backoff strategies.

Successful Requests (2xx Status)

When your request is successful, the following headers are included:

Header	Description	Example
`X-RateLimit-Limit`	The maximum number of requests allowed per minute	`200`
`X-RateLimit-Remaining`	The number of requests remaining in the current window	`157`
`X-RateLimit-Reset`	Unix timestamp (in seconds) when the rate limit will reset	`1700000000`

Example Response Headers:

X-RateLimit-Limit: 200
X-RateLimit-Remaining: 157
X-RateLimit-Reset: 1700000000

Rate Limit Exceeded (429 Status)

When you exceed the rate limit, you’ll receive a 429 Too Many Requests response with the following headers:

Header	Description	Example
`X-RateLimit-Limit`	The maximum number of requests allowed per minute	`200`
`X-RateLimit-Remaining`	Always `0` when rate limited	`0`
`X-RateLimit-Reset`	Unix timestamp (in seconds) when you can retry	`1700000060`
`Retry-After`	Number of seconds to wait before retrying	`60`

Example 429 Response:

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 200
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1700000060
Retry-After: 60

{
  "error": "Rate limit exceeded",
  "message": "You have exceeded the rate limit of 200 requests per minute"
}

Best Practices

1. Monitor Rate Limit Headers

Always check the X-RateLimit-Remaining header to track your usage and adjust your request frequency accordingly.

2. Implement Retry Logic with Backoff

When you receive a 429 response, wait for the duration specified in the Retry-After header before retrying.

3. Distribute Requests Across Multiple Connectors

Since rate limits are per connector, requests for different end users (different connector tokens) have independent rate limits. You can process multiple connectors in parallel without affecting each other’s rate limits.

4. Batch Requests When Possible

Reduce the number of API calls by using batch endpoints or requesting multiple resources in a single call where supported.

5. Implement Rate Limit Tracking

Track rate limit usage across your application to proactively avoid hitting limits.

Calculating Time Until Reset

The X-RateLimit-Reset header contains a Unix timestamp. You can calculate the wait time as follows:

import time
from datetime import datetime

reset_timestamp = int(response.headers.get('X-RateLimit-Reset'))
current_time = int(time.time())
seconds_until_reset = reset_timestamp - current_time

print(f"Rate limit resets in {seconds_until_reset} seconds")
print(f"Reset time: {datetime.fromtimestamp(reset_timestamp)}")

Need Higher Limits?

If your application requires higher rate limits for specific connectors or use cases, please contact our support team at support@bindbee.dev or reach out to your account manager. We offer custom rate limits for enterprise customers based on your specific needs.

Common Questions

What happens if I exceed the rate limit?

Your requests for that specific connector will be rejected with a 429 Too Many Requests status code until the rate limit window resets (60 seconds from when you first exceeded the limit).

Does the rate limit apply per endpoint or across all endpoints?

The rate limit applies across all endpoints for a given connector. All requests made with the same X-Connector-Token count toward the same 200 requests per minute limit.

Are rate limits shared across different connector tokens?

No, each connector token has its own independent rate limit of 200 requests per minute. This means different end users (different connectors) do not affect each other’s rate limits.

Can I make requests without a connector token?

Some endpoints may not require a connector token (such as organization-level endpoints), but any endpoint that accesses or manipulates end user data requires both the API key and the connector token. Check the specific endpoint documentation for requirements.

Bindbee API Basics

Connectors

Integrations

Supplemental Data

Overview

Rate Limit Policy

Rate Limit Headers

Successful Requests (2xx Status)

Rate Limit Exceeded (429 Status)

Best Practices

1. Monitor Rate Limit Headers

2. Implement Retry Logic with Backoff

3. Distribute Requests Across Multiple Connectors

4. Batch Requests When Possible

5. Implement Rate Limit Tracking

Calculating Time Until Reset

Need Higher Limits?

Common Questions

What happens if I exceed the rate limit?

Does the rate limit apply per endpoint or across all endpoints?

Are rate limits shared across different connector tokens?

Can I make requests without a connector token?

​Overview

​Rate Limit Policy

​Rate Limit Headers

​Successful Requests (2xx Status)

​Rate Limit Exceeded (429 Status)

​Best Practices

​1. Monitor Rate Limit Headers

​2. Implement Retry Logic with Backoff

​3. Distribute Requests Across Multiple Connectors

​4. Batch Requests When Possible

​5. Implement Rate Limit Tracking

​Calculating Time Until Reset

​Need Higher Limits?

​Common Questions

​What happens if I exceed the rate limit?

​Does the rate limit apply per endpoint or across all endpoints?

​Are rate limits shared across different connector tokens?

​Can I make requests without a connector token?

Overview

Rate Limit Policy

Rate Limit Headers

Successful Requests (2xx Status)

Rate Limit Exceeded (429 Status)

Best Practices

1. Monitor Rate Limit Headers

2. Implement Retry Logic with Backoff

3. Distribute Requests Across Multiple Connectors

4. Batch Requests When Possible

5. Implement Rate Limit Tracking

Calculating Time Until Reset

Need Higher Limits?

Common Questions

What happens if I exceed the rate limit?

Does the rate limit apply per endpoint or across all endpoints?

Are rate limits shared across different connector tokens?

Can I make requests without a connector token?