WEEX API-Ratenbegrenzungen: Wo Bots tatsächlich den 429-Fehler auslösen

Die meisten WEEX API-Integrationen, die in der Produktion fehlschlagen, scheitern nicht an Signaturen. Sie scheitern, weil der Bot die "Ratenbegrenzung" als eine einzige Zahl behandelt, während WEEX zwei unabhängige Budgets betreibt – ein IP-Gewichtungsbudget und ein pro-Konto-Orderbudget –, die sich zu unterschiedlichen Zeiten erneuern und in verschiedenen Antwort-Headern gemeldet werden. Wenn Sie das falsch machen, erhalten Sie einen HTTP 429 plus eine 10-sekündige Sperre, meist genau in dem Moment, in dem Volatilität Ihre Ausführungen wichtig macht.

Dies ist eine konsolidierte Karte der WEEX API-Ratenbegrenzungsregeln, wie sie im Juli 2026 existieren, gezogen aus der Spot- und Futures-Dokumentation und abgeglichen mit dem Live-Futures-exchangeInfo-Endpunkt. Sie deckt auch den Teil ab, den die Dokumentation nicht explizit nennt: wie viel Polling diese Zahlen Ihnen tatsächlich ermöglichen.

WEEX API-Ratenbegrenzungen auf einen Blick

Die folgende Tabelle führt Regeln zusammen, die derzeit über vier separate WEEX-Dokumentationsflächen verstreut sind – Spot-Zugriffsbeschränkungen, Futures-Endpunkt-Gewichtungen, die WebSocket-Übersicht und die Fehlerliste im Hilfe-Center.

Zwei Details in dieser Tabelle verursachen mehr Vorfälle als alles andere.

Erstens: Die Orderplatzierung verbraucht überhaupt kein IP-Gewicht – WEEX gibt für diese Aufrufe 0 im IP-Gewichtungszähler zurück. Zweitens, und das ist die Falle, das Stornieren und Abfragen von Orders ist weiterhin IP-limitiert. Eine Market-Making-Schleife, die Orders storniert und neu einstellt, verbraucht daher aus beiden Budgets gleichzeitig, und die Stornierungen sind die Seite, die den IP-Pool leise entleert.

Die maßgeblichen Zahlen stehen nirgendwo in Prosa. WEEX veröffentlicht sie im rateLimits-Array, das von exchangeInfo zurückgegeben wird – /capi/v3/market/exchangeInfo unter https://api-contract.weex.com für Futures und /api/v3/exchangeInfo für Spot. Lesen Sie dieses Array beim Start, anstatt Konstanten fest zu kodieren.

Die Live-Zahlen und warum die Dokumentation andere zeigt

Hier ist die Live-Futures-rateLimits-Antwort, abgerufen am 27. Juli 2026, neben den Beispielwerten, die auf der exchangeInfo-Dokumentationsseite von WEEX gedruckt sind:

Das sind keine kleinen Unterschiede – das Beispiel impliziert etwa 200 Gewichtung pro Sekunde, die Live-Antwort erlaubt etwa 0,83. Die Dokumentationswerte sind Platzhalter-Antwortbeispiele, keine veröffentlichte Zulage, und jeder, der die Dokumentationsseite gescraped hat, um sein Anfragebudget zu bemessen, hat gegen eine Zahl gebaut, die um mehr als zwei Größenordnungen daneben liegt. Dies ist das stärkste Argument dafür, exchangeInfo zur Laufzeit zu lesen: WEEX kann und wird diese Werte ändern, und nur der Endpunkt sagt Ihnen die Wahrheit.

Wenn man die Live-Futures-Zahlen durchrechnet, ist die praktische Obergrenze unangenehm:

• 500 Gewichtung ÷ 600 Sekunden = eine Gewichtung-1-Anfrage alle 1,2 Sekunden nachhaltig, pro IP.
• Das Polling eines Gewichtung-1-Endpunkts einmal pro Sekunde – der Standard in den meisten Tutorial-Bots – verbraucht 600 Gewichtung pro 10 Minuten und bringt Sie vor der elften Minute über das Limit.
• 300 Orders pro Minute = 5 Orders pro Sekunde nachhaltig, pro Konto.

Das Orderbudget ist großzügig. Das IP-Gewichtungsbudget ist es nicht. Wenn Ihre Architektur REST-Polling für Marktdaten voraussetzt, ist diese Annahme der Grund, warum sie bricht.

Wie man die WEEX-Ratenbegrenzungs-Header liest

WEEX baut die Headernamen aus dem Intervall auf, unter Verwendung von S, M, H, D für Sekunde, Minute, Stunde und Tag. Also ist X-USED-WEIGHT-1M das Gewicht, das von Ihrer IP im aktuellen Ein-Minuten-Fenster verbraucht wurde, und X-ORDER-COUNT-10S sind die Orders, die von Ihrem Konto im aktuellen Zehn-Sekunden-Fenster platziert wurden.

Parsen Sie X-REMAINING-* bei jeder Antwort und drosseln Sie entsprechend. Das Warten auf einen 429-Fehler, um Ihnen mitzuteilen, dass Sie zu schnell waren, ist ein Design, das garantiert, dass Sie zu schnell sein werden – und WEEX ist explizit, dass Sie nach einem 429 dafür verantwortlich sind, zu stoppen, nicht erneut zu versuchen. Beachten Sie auch, dass der Futures-Orderpfad sowohl einen 10-Sekunden- als auch einen 1-Minuten-Orderzähler meldet, sodass ein Burst, der das Minutenlimit leert, immer noch das kürzere Fenster auslösen kann.

Wissenswert, bevor Sie das Falsche debuggen: Mehrere Fehler sehen aus wie Drosselung, sind es aber nicht. Die API-Fehlercodeliste von WEEX trennt 429 (Anfragefrequenz überschritten) von 40008 (Anfrage-Zeitstempel abgelaufen – die Signatur ist 30 Sekunden gültig) und 40018 (ungültige IP-Anfrage, was bedeutet, dass Ihre aufrufende IP nicht auf der Whitelist des Schlüssels steht). Eine Uhr, die um mehr als 30 Sekunden abweicht, erzeugt einen stetigen Strom von Ablehnungen, der überraschend oft als Ratenbegrenzungsproblem missverstanden wird.

Was passiert, wenn Sie 429 auf der WEEX API erhalten

Die Anfrage schlägt mit HTTP-Status 429 fehl, und weitere Anfragen bringen eine 10s-Sperre ein. Die Seite für Zugriffsbeschränkungen von WEEX stellt die Verpflichtung klar: Wenn Sie einen 429 erhalten, müssen Sie das Anfragen stoppen und dürfen die API nicht missbrauchen.

Zehn Sekunden klingen überlebbar. In der Praxis sind es die schlimmsten zehn Sekunden, die Sie haben werden, weil Ratenbegrenzungen während Volatilität erreicht werden – genau in dem Moment, in dem ein Hedge platziert oder ein Stop bewegt werden muss. Die richtige Haltung ist ein clientseitiger Token-Bucket, der aus den Live-exchangeInfo-Werten mit etwa 20% Spielraum bemessen ist, plus exponentielles Backoff bei jedem 429, der doch durchrutscht. Sofortiges erneutes Versuchen verwandelt eine 10-sekündige Sperre in eine rollierende.

Einen Bot bauen, der unter den WEEX API-Limits bleibt

Die Lösung für ein knappes IP-Gewichtungsbudget ist architektonisch, nicht taktisch: Hören Sie auf, nach allem zu pollen, was ein Stream liefern kann.

Der Spot-WebSocket von WEEX läuft unter wss://ws-spot.weex.com/v3/ws/public und wss://ws-spot.weex.com/v3/ws/private, mit eigenen separaten Limits – 300 Verbindungsanfragen pro IP pro 5 Minuten, maximal 100 gleichzeitige Verbindungen pro IP, 100 Kanäle pro Verbindung und 240 Abonnement-Operationen pro Stunde pro Verbindung. Das ergibt 10.000 Kanalplätze pro IP, was mehr Marktdaten sind, als fast jede Strategie benötigt, und nichts davon berührt Ihr REST-Gewicht.

Die Heartbeat-Regel ist hier wichtig. Der Server sendet ping und erwartet ein PONG; Verbindungen, die mehr als 10 Mal nicht antworten, werden beendet. Ein Client, der nur bei Socket-Schließung neu verbindet und nie bei verpassten Pongs, wird auf einem toten Stream sitzen, während seine Logik leise veraltete Preise handelt.

Ein praktisches Setup auf WEEX sieht so aus:

1. Erstellen Sie einen API-Schlüssel unter Konto → API-Management und binden Sie eine IP-Whitelist. Ungebundene Schlüssel sind die häufigste Ursache dafür, dass ein kompromittiertes Konto lange genug überlebt, um wichtig zu sein.
2. Rufen Sie exchangeInfo beim Start auf, lesen Sie rateLimits und bemessen Sie Ihren Token-Bucket aus der Antwort – niemals aus einer Konstante in Ihrer Konfigurationsdatei.
3. Verschieben Sie alle Marktdaten auf WebSocket. Reservieren Sie REST für Kontostatus, Orderplatzierung und Abgleich.
4. Trennen Sie die beiden Budgets im Code. Ein Limiter für IP-Gewichtung (einschließlich Stornierungen und Abfragen), ein zweiter für die Orderanzahl. Ein einziger gemeinsamer Limiter wird entweder Ihren Orderfluss unnötig drosseln oder Ihr Gewicht überschreiten.
5. Verwenden Sie Batch-Order-Endpunkte, wo die Strategie es erlaubt. Sie zählen immer noch gegen ORDERS, aber sie reduzieren Round-Trips und Latenz.
6. Gleichen Sie nach einem Timer ab, nicht bei jeder Ausführung. Positions- und Saldoabfragen sind Gewichtung-1-Endpunkte, die sich schnell summieren, wenn sie pro Ereignis ausgelöst werden.

Wenn Sie noch entscheiden, ob ein API-gesteuerter Ansatz überhaupt passt, deckt die Übersicht von WEEX zur API-Handelsunterstützung die Entscheidung zwischen REST und WebSocket ab, bevor Sie sich auf eine Architektur festlegen.

Was am wichtigsten ist

Von allem oben Genannten bestimmt eine Zahl das Design: die Live-Futures-IP-Gewichtungszulage von 500 pro 10 Minuten. Sie ist restriktiv genug, dass jede REST-Polling-Marktdatenschleife disqualifiziert ist, was bedeutet, dass die WEEX API-Ratenbegrenzungsregeln nicht wirklich ein Drosselungsproblem sind, das abgestimmt werden muss – sie sind ein Signal, dass die Plattform Streaming-Clients erwartet. Bauen Sie von Anfang an so, und die 429er hören größtenteils auf, ein Thema zu sein.

Überprüfen Sie jede Zahl hier gegen exchangeInfo, bevor Sie live gehen. Limits sind Betriebsparameter, und Börsen ändern sie ohne viel Vorankündigung.

FAQ

1. Was ist das WEEX API-Ratenlimit?

WEEX erzwingt zwei Limits: ein REQUEST_WEIGHT-Budget pro IP-Adresse für alle Endpunkte außer Orderplatzierung, und ein ORDERS-Budget pro Konto für Einzel- und Batch-Orderplatzierung. Stand 27. Juli 2026 gibt der Live-Futures-exchangeInfo-Endpunkt 500 Gewichtung pro 10 Minuten und 300 Orders pro Minute zurück. Lesen Sie den Endpunkt, anstatt einer veröffentlichten Zahl zu vertrauen, einschließlich dieser.

2. Ist das WEEX API-Ratenlimit pro IP oder pro API-Schlüssel?

Pro IP für gewichtete Endpunkte – WEEX gibt an, dass diese Limits auf IP basieren, nicht auf API-Schlüssel oder UID. Orderplatzierung ist die Ausnahme: sie ist pro Konto (userId) limitiert. Mehrere Schlüssel von einem Server auszuführen, multipliziert Ihre Gewichtungszulage nicht.

3. Was bedeutet HTTP 429 auf WEEX und wie lange ist die Sperre?

429 bedeutet, dass Ihre Anfragefrequenz das Limit überschritten hat. WEEX wendet eine 10-sekündige Sperre an und erwartet, dass Sie das Senden von Anfragen stoppen, anstatt sofort erneut zu versuchen.

4. Zählen Stornierungsanfragen für Orders zum Order-Ratenlimit?

Nein. Nur Einzel- und Batch-Orderplatzierung fallen unter das ORDERS-Limit. Das Stornieren und Abfragen von Orders ist durch IP-Gewichtung ratenbegrenzt, weshalb stornierungsintensive Strategien das IP-Budget zuerst erschöpfen.

5. Wie überprüfe ich mein verbleibendes WEEX API-Kontingent?

Lesen Sie die Antwort-Header. X-REMAINING-WEIGHT-1M zeigt das IP-Gewicht, das in der aktuellen Minute übrig ist, und X-ORDER-REMAINING-10S und X-ORDER-REMAINING-1M zeigen die Orderkapazität, die für Ihr Konto übrig ist.

6. Was sind die WEEX WebSocket-Limits?

300 Verbindungsanfragen pro IP pro 5 Minuten, bis zu 100 gleichzeitige Verbindungen pro IP, maximal 100 Kanäle pro Verbindung und 240 Abonnement-Operationen pro Stunde pro Verbindung. Verpassen Sie mehr als 10 Server-Pings und die Verbindung wird geschlossen.

7. Warum schlägt meine WEEX API-Anfrage selbst bei geringem Volumen fehl?

Überprüfen Sie Fehler 40008, bevor Sie Drosselung annehmen. Signierte Anfragen sind 30 Sekunden gültig, daher erzeugt eine Serveruhr, die mehr als 30 Sekunden von der Zeit der Börse abweicht, ständige Ablehnungen, die einem Ratenbegrenzungsproblem ähneln. Fehler 40018 deutet stattdessen auf eine IP-Whitelist-Nichtübereinstimmung hin.

Risikowarnung

Krypto-Assets sind volatil und API-gesteuerter Handel kann zu teilweisem oder totalem Verlust von Geldern führen. Automatisierte Systeme verstärken dieses Risiko: Ein ratenbegrenzter oder getrennter Client kann versagen, einen Stop zu platzieren, eine veraltete Quote zu stornieren oder eine gehebelte Position zu schließen, während sich der Markt dagegen bewegt, und eine 10-sekündige Sperre während eines Volatilitätsspikes reicht aus, um einen handhabbaren Drawdown in eine Liquidation zu verwandeln. Futures-Positionen tragen Hebelrisiko und können vollständig liquidiert werden. API-Schlüssel tragen Verwahrungs- und Betriebsrisiken – ein nicht auf der Whitelist stehender oder überberechtigter Schlüssel kann verwendet werden, um ein Konto zu leeren oder zu missbrauchen, also beschränken Sie Berechtigungen, binden Sie eine IP-Whitelist und gewähren Sie niemals Auszahlungsrechte an einen Handelsbot. Ratenbegrenzungen, Endpunktgewichtungen und Vertragsparameter können sich ohne Vorankündigung ändern; überprüfen Sie sie gegen Live-Endpunkte, bevor Sie Kapital einsetzen. Nichts hier ist eine Anlageberatung.