# Rate limits

To ensure fair usage and protect the stability of the platform, the SOAP API limits the number of **concurrent requests per customer**. This is a concurrency limit, not a time-window limit: it caps how many requests you can have in flight at the same time, not how many you can send per minute or hour.

## How it works

- The number of requests you can have **in flight at the same time** is limited. Read your current limit from the `RateLimit-Limit` response header.
- The limit applies to your customer account as a whole, across all units and API keys.
- A slot is taken when a request starts and released as soon as it completes. There is no reset interval to wait for.
- When all slots are in use, additional requests are rejected with **429 Too Many Requests** and are not processed.


## Response headers

Responses include headers describing the limit and your current usage:

| Header | Description |
|  --- | --- |
| `RateLimit-Limit` | The maximum number of concurrent requests allowed for your account. |
| `RateLimit-Remaining` | The number of request slots currently available. The request returning this header counts as in flight, so a single request reports one slot less than your limit. |
| `RateLimit-Type` | The type of limit applied. Always `Concurrent` for the SOAP API. |


A rejected request looks like this:

```http
HTTP/1.1 429 Too Many Requests
RateLimit-Limit: 10
RateLimit-Remaining: 0
RateLimit-Type: Concurrent
```

## Handling 429 responses

Because the limit is concurrency-based, a slot frees up as soon as one of your in-flight requests completes. To stay within the limit:

- Cap the number of parallel requests in your integration below the limit, and prefer sequential calls where throughput allows.
- On a 429 response, retry with an exponential backoff rather than retrying immediately in a tight loop.
- Watch `RateLimit-Remaining` to know how close you are to the limit before requests start being rejected.