Limites de débit

Limitation de débit par portefeuille pour les opérations sur ordres et les requêtes API.

Vue d'ensemble

La limitation de débit utilise des fenêtres fixes de 60 secondes. Les limites par portefeuille dépendent du niveau (tier) du portefeuille et s'appliquent aux :

Placements d'ordres (POST /order, PUT /order, PlaceOrder via WebSocket, et soumissions d'ordres sur contrats perpétuels via la route TEE)
Annulations d'ordres (DELETE /order, DELETE /order_cloid, et annulations sur contrats perpétuels via la route TEE)
Requêtes API (lectures liées à un portefeuille et autres écritures signées)

Des limites distinctes, indexées par source réseau et assorties d'un plafond global au niveau du processus, s'appliquent aux annulations, à l'autorisation d'agents, aux écritures MMP et aux simulations de risque publiques.

Les compteurs sont conservés en mémoire par chaque processus API. Ils ne sont pas partagés entre les réplicas : considérez donc les valeurs publiées comme le maximum qu'un seul processus acceptera, et non comme un budget à l'échelle du cluster.

Limites par défaut

Niveau	Ordres/min	Annulations/min	Requêtes API/min	Ordres ouverts max	Positions max
Par défaut	60	120	600	100	50
Tier 1	30	60	300	50	20
Tier 2	120	300	1 200	500	200
Teneur de marché	1 200	2 400	6 000	5 000	Illimité

Les nouveaux portefeuilles reçoivent les limites par défaut. Contactez le support pour passer à un niveau supérieur. Votre limite actuelle de requêtes API figure dans l'en-tête X-RateLimit-Limit de toute lecture liée à un portefeuille, par exemple GET /orders?wallet=....

Réponse en cas de dépassement

Lorsqu'une limite de débit est dépassée, l'API renvoie 429 Too Many Requests :

{
  "error": "rate_limit_exceeded",
  "message": "Rate limit exceeded for OrderPlacement: 60 per minute, retry after 45 seconds",
  "retry_after_secs": 45,
  "limit": 60
}

En-têtes de réponse

Les endpoints soumis à une limite par portefeuille renvoient ces en-têtes. Une réponse 429 contient X-RateLimit-Limit, X-RateLimit-Remaining: 0 et Retry-After, mais pas X-RateLimit-Reset :

En-tête	Description	Exemple
`X-RateLimit-Limit`	Nombre maximal de requêtes autorisées par fenêtre	`60`
`X-RateLimit-Remaining`	Requêtes restantes dans la fenêtre courante	`42`
`X-RateLimit-Reset`	Horodatage Unix en secondes de la réinitialisation de la fenêtre (réponses réussies uniquement)	`1737312060`
`Retry-After`	Secondes avant nouvelle tentative (uniquement en cas de 429)	`45`

Exemples d'en-têtes de réponse

Requête réussie :

HTTP/1.1 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1737312060

Requête limitée :

HTTP/1.1 429 Too Many Requests
Retry-After: 45
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0

Catégories de limites

Les limites de débit sont suivies séparément pour chaque type d'action :

Placement d'ordres

Comptabilisé par portefeuille selon la valeur Ordres/min du niveau :

POST /order et PUT /order
PlaceOrder via WebSocket
POST /v1/tee-perp/orders/submit et les autres soumissions d'ordres sur contrats perpétuels, comptabilisés au titre du manager du compte

POST /bulk_order et PUT /bulk_order sont plafonnés à 50 entrées par requête.

Annulation d'ordres

Comptabilisé par portefeuille selon la valeur Annulations/min du niveau :

DELETE /order et DELETE /order_cloid
Annulations sur contrats perpétuels, comptabilisées au titre du portefeuille API signataire

Chaque route d'annulation, y compris DELETE /bulk_order et DELETE /bulk_order_cloid, est également limitée, avant vérification de la signature, à 6 000 annulations unitaires par source réseau et 60 000 au niveau du processus par minute. Une annulation groupée compte une annulation unitaire par entrée.

Requêtes API

Comptabilisées par portefeuille selon la valeur Requêtes API/min du niveau :

Lectures liées à un portefeuille, indexées sur le paramètre de requête wallet
Écritures signées non listées ci-dessus, comme la configuration MMP et le mode de marge

Soumission de RFQ

POST /rfq/request et les commandes WebSocket de soumission de RFQ sont limités à 10 par portefeuille et par minute, quel que soit le niveau.

Simulation de risque

Les simulations publiques de portefeuille et d'ordres (POST /risk/simulate/portfolio, POST /risk/simulate/orders, et l'aperçu pour contrats perpétuels POST /v1/tee-perp/preview) disposent de limites distinctes de 60 requêtes par source réseau et 600 requêtes au niveau du processus par minute. Au plus quatre simulations s'exécutent simultanément dans un même processus API. Une requête qui dépasse un quota ou trouve les workers de simulation saturés renvoie 429 Too Many Requests.

Autorisation d'agents

POST /approve-agent, DELETE /revoke-agent et DELETE /revoke-all-agents sont limités, avant vérification de la signature, à 120 requêtes par source réseau et 1 200 requêtes au niveau du processus par minute.

Écritures MMP

Les écritures de configuration MMP sont limitées, avant vérification de la signature, à 120 requêtes par source réseau et 1 200 requêtes au niveau du processus par minute, en plus de la limite de requêtes API du portefeuille.

Limites de positions et d'ordres

En plus des limites de débit, les portefeuilles sont soumis à un nombre maximal d'ordres ouverts et de positions :

Type de limite	Description	Rejet
Ordres ouverts max	Nombre maximal d'ordres ouverts simultanément	Nouvel ordre rejeté tant que le portefeuille est à la limite
Positions max	Nombre maximal de positions distinctes (-1 = illimité)	Ordre rejeté s'il ouvrait une nouvelle position

Il s'agit de rejets d'ordres, et non d'erreurs HTTP. La réponse à l'ordre est un HTTP 200 avec status: "REJECTED" et une reason telle que :

max_open_orders_exceeded: current=100, limit=100
max_positions_exceeded: wallet 0x... has 50 positions, limit is 50

Bonnes pratiques

Gestion des limites de débit

Surveillez les en-têtes : suivez X-RateLimit-Remaining de manière proactive
Respectez Retry-After : attendez la durée indiquée avant de réessayer
Implémentez un backoff : utilisez un backoff exponentiel en cas de 429 répétés

import time

def place_order_with_retry(order, max_retries=3):
    for attempt in range(max_retries):
        response = api.place_order(order)

        if response.status_code == 429:
            retry_after = int(response.headers.get('Retry-After', 60))
            time.sleep(retry_after)
            continue

        return response

    raise RateLimitError("Max retries exceeded")

Optimiser l'utilisation des requêtes

Utilisez les endpoints groupés : POST /bulk_order pour plusieurs ordres en une seule requête
Groupez les annulations : DELETE /bulk_order ou DELETE /bulk_order_cloid plutôt que plusieurs requêtes DELETE /order
WebSocket pour les mises à jour : abonnez-vous aux mises à jour d'ordres plutôt que d'interroger GET /orders en boucle

Supervision

Suivez ces métriques côté client :

Débit de requêtes par type d'action
Évolution de X-RateLimit-Remaining
Fréquence des réponses 429
Durées moyennes de Retry-After

Référence des erreurs

Statut HTTP	Code d'erreur	Description
429	`rate_limit_exceeded`	Limite de débit dépassée, réessayez après le délai indiqué

Consultez Erreurs pour la référence complète des erreurs.

Vue d'ensemble​

Limites par défaut​

Réponse en cas de dépassement​

En-têtes de réponse​

Exemples d'en-têtes de réponse​

Catégories de limites​

Placement d'ordres​

Annulation d'ordres​

Requêtes API​

Soumission de RFQ​

Simulation de risque​

Autorisation d'agents​

Écritures MMP​

Limites de positions et d'ordres​

Bonnes pratiques​

Gestion des limites de débit​

Optimiser l'utilisation des requêtes​

Supervision​

Référence des erreurs​