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

Limits

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.
Requests carrying HMAC headers that fail authentication are also limited per IP, and sustained abuse is rate-limited at the network edge.

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.
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.

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