> For the complete documentation index, see [llms.txt](https://docs.lsports.eu/u/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lsports.eu/u/trade/combo-builder/rate-limits-and-throughput.md).
# Rate Limits & Throughput
The ComboBuilder API is built for high request volumes, including the traffic peaks that come with major tournaments. This page explains how request volume is counted, the capacity provisioned for your account, and how the API behaves when traffic runs high.
### How request volume is counted
Request volume is measured across the whole ComboBuilder API, not per endpoint. Calls to `/v1/markets`, `/v1/combobuilder`, and `/v1/combobuilder/auto` all count toward the same combined total. There is no separate allowance for each endpoint.
Most of your volume comes from `/v1/combobuilder`, because a bettor's bet slip is repriced every time they add or change a selection.
### Provisioned capacity
Each operator is provisioned with a throughput baseline of around **2,000 requests per second (RPS)**, shared across all ComboBuilder endpoints. This is the capacity allocated to you by default, not a fixed ceiling.
If you expect sustained traffic above this baseline — for example around a major tournament — share your projected peak RPS with your CSM in advance. We provision additional capacity ahead of the event so your traffic is covered.
{% hint style="info" %}
Tell your CSM your expected peak volume before a high-traffic event. Advance notice lets us allocate capacity in time.
{% endhint %}
### What happens at high volume
Under normal operation, ComboBuilder does not hard-block your traffic with a rate-limit error. The API scales to absorb spikes in demand.
If sustained traffic exceeds the capacity provisioned for you, requests are not rejected with a dedicated rate-limit response. Instead, response times rise, and any request that cannot complete in time returns a standard server response:
| Response | Meaning | What to do |
| --------------------------- | ------------------------------------ | ------------------------------ |
| **503 Service Unavailable** | The service is momentarily saturated | Retry with exponential backoff |
| **504 Gateway Timeout** | The request did not complete in time | Retry with exponential backoff |
Build standard resilience into your integration: retry on `503` and `504` with exponential backoff, and treat both as transient. If you see them consistently, contact your CSM to review your provisioned capacity.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.lsports.eu/u/trade/combo-builder/rate-limits-and-throughput.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.