Rate Limits

Ratenbegrenzung pro Wallet für Orderoperationen und API-Anfragen.

Überblick

Die Ratenbegrenzung verwendet feste 60-Sekunden-Fenster. Wallet-Limits ergeben sich aus der Stufe (Tier) der Wallet und gelten für:

• Orderplatzierungen (POST /order, PUT /order, WebSocket PlaceOrder und TEE-Perp-Order-Übermittlungen)
• Orderstornierungen (DELETE /order, DELETE /order_cloid und TEE-Perp-Stornierungen)
• API-Anfragen (Wallet-bezogene Lesezugriffe und andere signierte Schreibvorgänge)

Separate Limits, die nach Netzwerkquelle geschlüsselt sind und einer prozessweiten Obergrenze unterliegen, gelten für Stornierungen, Agent-Autorisierung, MMP-Schreibvorgänge und öffentliche Risikosimulationen.

Die Zähler werden von jedem API-Prozess im Arbeitsspeicher gehalten. Sie werden nicht zwischen Replikaten geteilt. Betrachten Sie die veröffentlichten Werte daher als das Maximum, das ein einzelner Prozess zulässt, nicht als clusterweites Budget.

Standardlimits

Stufe	Orders/Min.	Stornierungen/Min.	API-Anfragen/Min.	Max. offene Orders	Max. Positionen
Default	60	120	600	100	50
Tier 1	30	60	300	50	20
Tier 2	120	300	1.200	500	200
Market Maker	1.200	2.400	6.000	5.000	Unbegrenzt

Neue Wallets erhalten die Standardlimits. Wenden Sie sich für ein Upgrade der Stufe an den Support. Ihr aktuelles Limit für API-Anfragen finden Sie im Header X-RateLimit-Limit jedes Wallet-bezogenen Lesezugriffs, zum Beispiel GET /orders?wallet=....

Antwort bei Überschreitung des Rate Limits

Wird ein Rate Limit überschritten, gibt die API 429 Too Many Requests zurück:

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

Response-Header

Wallet-begrenzte Endpunkte liefern diese Header. Eine 429-Antwort enthält X-RateLimit-Limit, X-RateLimit-Remaining: 0 und Retry-After, aber kein X-RateLimit-Reset:

Header	Beschreibung	Beispiel
X-RateLimit-Limit	Maximal zulässige Anfragen pro Fenster	60
X-RateLimit-Remaining	Verbleibende Anfragen im aktuellen Fenster	42
X-RateLimit-Reset	Unix-Zeitstempel in Sekunden, zu dem das Fenster zurückgesetzt wird (nur bei erfolgreichen Antworten)	1737312060
Retry-After	Sekunden bis zum erneuten Versuch (nur bei 429)	45

Beispiel für Response-Header

Erfolgreiche Anfrage:

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

Begrenzte Anfrage:

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

Kategorien der Ratenbegrenzung

Rate Limits werden für jeden Aktionstyp separat erfasst:

Orderplatzierung

Wird pro Wallet auf die Orders/Min. der Stufe angerechnet:

• POST /order und PUT /order
• WebSocket PlaceOrder
• POST /v1/tee-perp/orders/submit und die übrigen Perp-Order-Übermittlungen, angerechnet auf den Account-Manager

POST /bulk_order und PUT /bulk_order sind auf 50 Einträge pro Anfrage begrenzt.

Orderstornierung

Wird pro Wallet auf die Stornierungen/Min. der Stufe angerechnet:

• DELETE /order und DELETE /order_cloid
• Perp-Stornierungen, angerechnet auf die signierende API-Wallet

Jede Stornierungsroute, einschließlich DELETE /bulk_order und DELETE /bulk_order_cloid, ist zusätzlich vor der Signaturprüfung auf 6.000 Stornierungspositionen pro Netzwerkquelle und 60.000 Positionen prozessweit pro Minute begrenzt. Eine Sammelstornierung zählt eine Position pro Eintrag.

API-Anfragen

Wird pro Wallet auf die API-Anfragen/Min. der Stufe angerechnet:

• Wallet-bezogene Lesezugriffe, geschlüsselt nach dem Query-Parameter wallet
• Oben nicht aufgeführte signierte Schreibvorgänge, etwa MMP-Konfiguration und Margin-Modus

RFQ-Übermittlung

POST /rfq/request und die WebSocket-Befehle zur RFQ-Übermittlung sind unabhängig von der Stufe auf 10 pro Wallet und Minute begrenzt.

Risikosimulation

Öffentliche Portfolio- und Ordersimulationen (POST /risk/simulate/portfolio, POST /risk/simulate/orders und die Perp-Vorschau POST /v1/tee-perp/preview) haben separate Limits von 60 Anfragen pro Netzwerkquelle und 600 Anfragen prozessweit pro Minute. In einem API-Prozess laufen höchstens vier Simulationen gleichzeitig. Eine Anfrage, die ein Kontingent überschreitet oder auf ausgelastete Simulations-Worker trifft, gibt 429 Too Many Requests zurück.

Agent-Autorisierung

POST /approve-agent, DELETE /revoke-agent und DELETE /revoke-all-agents sind vor der Signaturprüfung auf 120 Anfragen pro Netzwerkquelle und 1.200 Anfragen prozessweit pro Minute begrenzt.

MMP-Schreibvorgänge

Schreibvorgänge für die MMP-Konfiguration sind vor der Signaturprüfung auf 120 Anfragen pro Netzwerkquelle und 1.200 Anfragen prozessweit pro Minute begrenzt, zusätzlich zum API-Anfragelimit der Wallet.

Positions- und Orderlimits

Zusätzlich zu den Rate Limits gelten für Wallets Höchstgrenzen für offene Orders und Positionen:

Limittyp	Beschreibung	Ablehnung
Max. offene Orders	Maximale Anzahl gleichzeitig offener Orders	Neue Order wird abgelehnt, solange die Wallet am Limit ist
Max. Positionen	Maximale Anzahl eindeutiger Positionen (-1 = unbegrenzt)	Order wird abgelehnt, wenn sie eine neue Position eröffnen würde

Dies sind Orderablehnungen, keine HTTP-Fehler. Die Orderantwort ist HTTP 200 mit status: "REJECTED" und einem reason wie:

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

Best Practices

Umgang mit Rate Limits

1. Header überwachen: Verfolgen Sie X-RateLimit-Remaining proaktiv
2. Retry-After beachten: Warten Sie die angegebene Dauer, bevor Sie es erneut versuchen
3. Backoff implementieren: Verwenden Sie exponentiellen Backoff bei wiederholten 429-Antworten

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")

Anfragen effizient nutzen

1. Bulk-Endpunkte verwenden: POST /bulk_order für mehrere Orders in einer Anfrage
2. Stornierungen bündeln: DELETE /bulk_order oder DELETE /bulk_order_cloid statt mehrerer DELETE /order-Anfragen
3. WebSocket für Updates: Abonnieren Sie Order-Updates, statt GET /orders abzufragen

Monitoring

Erfassen Sie diese clientseitigen Metriken:

• Anfragerate pro Aktionstyp
• Verlauf von X-RateLimit-Remaining
• Häufigkeit von 429-Antworten
• Durchschnittliche Retry-After-Dauer

Fehlerreferenz

HTTP-Status	Fehlercode	Beschreibung
429	rate_limit_exceeded	Rate Limit überschritten, nach der angegebenen Zeit erneut versuchen

Die vollständige Fehlerreferenz finden Sie unter Fehler.