> ## Documentation Index
> Fetch the complete documentation index at: https://digitalsurge.com.au/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate limits

> Digital Surge API rate limits for read and write requests, and how to handle HTTP 429 responses.

Rate limits are applied per account (per IP for unauthenticated requests) and are split by request type:

| Requests                                                  | Limit                   |
| --------------------------------------------------------- | ----------------------- |
| Reads (`GET`, `HEAD`, `OPTIONS`) — authenticated          | 1,800 per minute        |
| Writes (`POST`, `PUT`, `PATCH`, `DELETE`) — authenticated | 600 per minute          |
| Reads — unauthenticated (public endpoints)                | 1,800 per minute per IP |
| Writes — unauthenticated                                  | 60 per minute per IP    |

Authentication-related endpoints have significantly stricter limits.

## Handling `429 Too Many Requests`

When you exceed a limit the API returns HTTP `429`, and the response includes a `Retry-After` header with the number of seconds to wait:

```http theme={null}
HTTP/1.1 429 Too Many Requests
Retry-After: 37
```

Respect `Retry-After`, and add jittered exponential backoff around bursts. A few practical tips:

* **Poll gently.** Ticker prices don't change faster than a few times per second — polling `GET /api/public/broker/ticker/` more than once a second gains you nothing.
* **Batch reads.** The ticker and balances endpoints return *all* assets in one call; don't fetch per-asset in a loop.
* **After creating a swap**, poll its status about once per second for up to \~10 seconds — that is well inside the limits.

If you have a use case that genuinely needs higher limits, [contact support](https://help.digitalsurge.com.au).