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

# Rate limits

> Understand Futuur API rate limits and how to stay within them.

The Futuur API enforces rate limits per authenticated user to ensure fair access and platform stability.

## Limits

| Window | Limit |
| - | - |
| Per minute | 2,000 requests |
| Per day | 1,000,000 requests |

Both limits apply to your account (identified by your public key), not per IP address. The limits are shared across all endpoints — different paths and querystrings count against the same bucket.

## What happens when you exceed a limit

When you exceed a rate limit, the API returns HTTP `429 Too Many Requests` with a `Retry-After` header indicating when you can retry. Back off until the indicated time.

<Warning>
  Requests carrying HMAC headers that fail authentication are also limited per IP, and sustained abuse is rate-limited at the network edge.
</Warning>

## Duplicate POST requests

Submitting the same POST request more than once within a 1-second window causes a `wager_action_duplicated` error. This protects against accidental double-submission of orders.

<Note>
  The duplicate check is based on request content, not idempotency keys. If you need to retry a failed POST, wait at least 1 second before resubmitting.
</Note>

## Best practices

**Use the `include_mine` parameter wisely.** Order book and event detail reads are served from cache. By default they return the public payload; pass `include_mine=1` only on the calls where you actually need your own orders or wagers embedded, so the rest of your polling stays on the fast path.

**Prefer polling intervals of 1 second or more.** Responses are cached for a few seconds server-side, so faster polling returns the same data while consuming your quota.

**Cache responses where possible.** Market data like event listings and price history does not change every second. Cache responses and serve them from memory rather than re-fetching on every operation.

**Use exponential backoff on 429 responses.** If you receive a `429`, wait before retrying. Start with a short delay (e.g., 1 second) and double it on each successive failure, up to a maximum wait time.

```python python theme={null}
import time
import requests

def request_with_backoff(url, headers, max_retries=5):
    delay = 1
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers)
        if response.status_code == 429:
            retry_after = response.headers.get('Retry-After')
            wait_time = int(retry_after) if retry_after else delay
            time.sleep(wait_time)
            delay = min(delay * 2, 60)  # cap at 60 seconds
            continue
        return response
    return response
```


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.