Handle rate limits and retries
Every BrowserBee integration should assume that some requests will fail transiently. The goal is not to avoid all failures, but to recover from the right ones in a controlled way.
What to retry
Retry only when the failure appears transient, such as:
- network interruptions
- timeouts
- temporary service unavailability
- explicit rate limiting responses
Do not blindly retry validation failures or permanently invalid requests.
Recommended default retry policy
Use these defaults unless your workload requires something stricter:
- bounded retries, not infinite loops
- exponential backoff
- jitter so many workers do not retry simultaneously
- request logging with correlation data
Rate limit strategy
When you hit rate limits:
- slow down instead of continuing at the same rate
- separate bursty traffic from steady background synchronization
- batch or queue work on your side where possible
- monitor retry volume so you can see when the integration is under stress
Application design guidance
The more reliable your integration becomes, the more you should separate:
- request construction
- retry and backoff logic
- business-level error handling
- alerting and operational visibility
That separation prevents every call site from reinventing failure handling.
What to log
At minimum log:
- endpoint path
- environment
- request attempt number
- error class or status code
- final success or failure
Do not log full tokens or sensitive payloads.
Next steps
- Review API limits.
- Review Errors.