> 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
How ComboBuilder handles request volume, and what to expect at peak traffic
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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.