Rate limits - Bridgly

Bridgly limits how quickly you can send requests to keep the API reliable for everyone.

Default limits

Your actual rate limits may vary based on your tier and any custom agreement. The defaults for authenticated API requests are:

Window	Requests
Per second	5
Per minute	100

Both limits apply. Staying below 5 requests per second can still exceed the 100-request minute limit. Limits are applied per account, per endpoint and shared across all API keys belonging to that account. Creating another key does not increase your limit for the same endpoint. Requests made through the SDK or MCP server count toward the same limits as direct API calls.

When a limit is exceeded

The API rejects the request with 429 Too Many Requests. The scrape does not run, and the rejected request does not consume credits. The response includes a Retry-After header with the number of seconds to wait before trying again. For example:

HTTP/1.1 429 Too Many Requests
Retry-After: 10
Content-Type: application/json

{
  "status": "error",
  "message": "Too many requests. Please slow down.",
  "retryAfterSeconds": 10
}

Wait at least the indicated delay, then retry at a slower pace. Spread requests out instead of sending large bursts, and reduce parallel requests if you keep receiving 429 responses.

Response headers

The API also reports the shortest configured rate-limit window through:

Header	Meaning
`X-RateLimit-Limit`	Maximum requests allowed in that window.
`X-RateLimit-Remaining`	Requests remaining in that window.
`Retry-After`	Seconds to wait after a `429` response.

The remaining count covers that window only; a longer window may still be exhausted. See Responses & errors for the other API status codes.

​Default limits

​When a limit is exceeded

​Response headers

Default limits

When a limit is exceeded

Response headers