# Handling Rate Limits (429)

Rhythm APIs may return a `429 Too Many Requests` response when a client sends requests at a high rate. This is standard behavior for REST APIs and is not specific to your account or credentials.

When you receive a `429`, your client should pause and retry the request after a delay rather than immediately retrying — which would likely trigger another `429`.

## Exponential backoff

The recommended approach is **exponential backoff with jitter**: each successive retry waits longer than the last, with a small random offset to avoid synchronized retries from multiple clients.

A basic pattern:

1. Receive a `429` response
2. Wait `base * 2^attempt + jitter` milliseconds
3. Retry the request
4. If the retry also returns `429`, increase the attempt count and repeat
5. Stop after a maximum number of attempts and surface an error


Retry-After header
If the response includes a `Retry-After` header, use that value as your wait time instead of calculating your own.

## Open source libraries

Rather than implementing backoff from scratch, use a well-tested library for your language:

### JavaScript / Node.js

- **[p-retry](https://github.com/sindresorhus/p-retry)** — Promise-based retry with full backoff control (ESM only; requires a bundler or dynamic `import()` in CommonJS projects)
- **[axios-retry](https://github.com/softonic/axios-retry)** — drop-in retry plugin for Axios (ensure your `axios` dependency is kept up to date independently)


### Python

- **[tenacity](https://github.com/jd/tenacity)** — full-featured retry library with exponential, fibonacci, and custom wait strategies


### Java

- **[Resilience4j Retry](https://resilience4j.readme.io/docs/retry)** — production-grade retry with exponential backoff and jitter; the recommended choice for Java 17+ projects


### C# / .NET

- **[Polly](https://github.com/App-vNext/Polly)** — comprehensive resilience library with retry, circuit breaker, and backoff policies


### Go

- **[retry-go](https://github.com/avast/retry-go)** — simple retry with configurable backoff strategies including exponential and fibonacci


### PHP

- **[GuzzleRetryMiddleware](https://github.com/caseyamcl/guzzle_retry_middleware)** — retry middleware for Guzzle with `Retry-After` header support
- **[PHP Backoff](https://github.com/stechstudio/backoff)** — standalone backoff library with exponential, linear, and polynomial strategies


## Summary

- A `429` response means your client is sending too many requests — it is not an auth error
- Always implement retry logic with exponential backoff in any integration that calls Rhythm APIs under load
- Honor the `Retry-After` header when present
- Use an established library rather than rolling your own implementation