Just wondering with conneciton builder, how does airbyte know when its being RATE LIMITED, what does it look for

Airbyte determines that it is being rate limited in the Connector Builder by looking for specific HTTP status codes in the API response—most commonly 429 (Too Many Requests), but you can configure other codes like 420 or 503 if your API uses them. When one of these status codes is encountered, Airbyte interprets this as a rate limit event and triggers the appropriate backoff and retry logic according to the configured rate limiting policy. Additionally, Airbyte can extract rate limit information from HTTP response headers, such as the number of remaining requests (

X-RateLimit-Remaining

) and the reset time (

X-RateLimit-Reset

), to optimize when it resumes making requests. These headers and status codes are configurable in the connector's API budget settings. Here’s a summary of what Airbyte looks for: - HTTP status codes indicating rate limit (e.g., 429, 420, 503). - Rate limit headers in the API response, such as

X-RateLimit-Remaining

and

X-RateLimit-Reset

. When these are detected, Airbyte will pause and retry according to the defined rate limiting policy, ensuring it does not exceed the API’s usage limits and avoids being blocked or throttled [Global Configuration – HTTP API Budget](https://docs.airbyte.com/platform/next/connector-development/connector-builder-ui/global-configuration#http-api-budget) [Rate limiting (API Budget)](https://docs.airbyte.com/platform/next/connector-development/config-based/understanding-the-yaml-file/rate-limit-api-budget) [Error Handling Patterns](https://docs.airbyte.com/platform/next/connector-development/connector-builder-ui/error-handling#common-error-handling-patterns).

The key here is that almost all connectors do some basic 429 handling, but each connector can specify its own error handling to override this. In some cases APIs return the wrong codes, so you may have a 500 but based on the error message can tell Airbyte to translate that as

RATE_LIMITED

because of how that particular API works. When in doubt, read the connector code. But it's generally safe to assume that 429s will be treated as rate limited and wait (either based on the

Retry-After

header or other logic) and that thinks like 5xx errors will tend to fail (often triggering a retry. 4xx errors are more likely to throw a Source error by default that might not be retried.