WEEX API-Fehlercodes entschlüsselt: 40001 bis 43011 schnell beheben

Die meisten WEEX API-Fehler bedeuten nicht das, was die Nachricht besagt. Ein 40009 API validation failed bedeutet fast nie, dass Ihr Schlüssel schlecht ist — es bedeutet meist, dass der Signatur-String in der falschen Reihenfolge zusammengesetzt wurde. Ein 40102 Trading pair configuration does not exist bei einem Paar, das offensichtlich existiert, bedeutet meist, dass Sie ein Futures-Symbol an die Spot-Domain gesendet haben. Den Code wörtlich zu nehmen, macht aus einer zehnminütigen Fehlerbehebung einen ganzen Nachmittag.

Dies ist eine Arbeitsreferenz für die WEEX API-Fehlercodes, auf die eine Live-Integration tatsächlich stößt, gruppiert nach der Ebene, die ausgefallen ist, anstatt nach Nummer. Jeder Code unten stammt aus der WEEX API-Fehlercodeliste, wie sie am 27. Juli 2026 veröffentlicht wurde; die Regeln für Signatur, Timing und Ratenbegrenzung stammen aus der WEEX Spot-API-Dokumentation vom selben Datum. Beide ändern sich, also prüfen Sie dies erneut, bevor Sie live gehen.

Zuerst eine Klärung, da die Suchergebnisse sie vermischen: Dieser Artikel handelt von der WEEX Kryptobörsen-API (api-spot.weex.com und api-contract.weex.com). Sie hat nichts mit Apache Weex zu tun, dem eingestellten mobilen UI-Framework von Alibaba, das den Namen teilt und Fehler wie -1001 zurückgibt. Wenn Ihre Stack-Traces WXSDKInstance erwähnen, sind Sie im falschen Handbuch.

Wie WEEX API-Fehlercodes gruppiert sind

Die offizielle Liste ist eine flache Tabelle. In der Praxis fallen die Codes in sieben Diagnoseebenen, und die Kenntnis der Ebene verrät Ihnen, welche Datei Sie öffnen müssen. Diese Gruppierung ist der schnellste Weg, um die Debugging-Zeit zu verkürzen, da die Ebenen 1–4 Ihren Client betreffen und Ebene 7 überhaupt kein Fehler von Ihnen ist.

Die praktische Regel: Wenn der Code mit 400 beginnt, verdächtigen Sie Ihre Anfrage. Wenn er mit 43 beginnt, verdächtigen Sie Ihre Order-Parameter. Wenn es 429, 40200 oder 40015 ist, verdächtigen Sie nichts und warten Sie ab.

WEEX API-Authentifizierungsfehler: 40001 bis 40018

Dieses Band erzeugt die meisten Support-Tickets und die wenigsten echten Probleme mit Anmeldedaten. Sechs dieser Codes werden durch die Korrektur der Header-Erstellung gelöst, nicht durch die Generierung eines neuen Schlüssels.

Zwei Details sind es wert, verinnerlicht zu werden. Die WEEX Signatur-Konstruktionsregeln definieren den Prehash-String als timestamp + method.toUpperCase() + requestPath + "?" + queryString + body, HMAC-SHA256 mit Ihrem Secret Key, dann Base64. Das ? und der Query-String werden weggelassen, wenn keine Query vorhanden ist. Drei Dinge brechen dies in der Produktion: kleingeschriebenes get, ein Pfad, der den Host enthält, und ein JSON-Body, den Ihre HTTP-Bibliothek nach dem Signieren neu serialisiert — die Schlüsselreihenfolge ändert sich, die Bytes ändern sich, und Sie erhalten 40009.

Das zweite Detail ist eine Namensfalle. Der Fehlertext zitiert Headernamen mit Unterstrichen (ACCESS_KEY, ACCESS_SIGN, ACCESS_TIMESTAMP, ACCESS_PASSPHRASE), während die Signatur-Dokumentation sie mit Bindestrichen schreibt (ACCESS-SIGN, ACCESS-TIMESTAMP). Kopieren Sie die Form aus der Endpunkt-Dokumentation, gegen die Sie integrieren, und loggen Sie die rohen Wire-Header bei Ihrem ersten erfolgreichen Aufruf, anstatt dem Fehler-String oder einem Blog-Schnipsel zu vertrauen.

40005 vs 40008: zwei verschiedene Zeitstempel-Bugs

Diese beiden werden ständig verwechselt, und der falsche Fix verschwendet die meiste Zeit.

40005 Invalid ACCESS_TIMESTAMP ist ein Format-Problem. Der Wert ist keine 13-stellige Millisekunden-Epoche — meist eine 10-stellige Sekunden-Epoche von time.time() in Python oder time() in PHP, oder ein ISO-8601-String. Er schlägt sofort und konsistent bei jeder Anfrage fehl, auch bei der ersten.

40008 Request timestamp has expired ist ein Uhrzeit- oder Latenz-Problem. Das Format ist richtig, aber der Wert ist mehr als 30 Sekunden vom WEEX-Server-Zeitstempel entfernt. Anfragen sind nur 30 Sekunden gültig, und die Signatur wird abgelehnt, wenn der Zeitstempel um mehr als 30 Sekunden von der API-Server-Uhr abweicht — eine Maschine, die zu schnell läuft, scheitert genauso wie eine, die zu langsam läuft.

Uhrdrift in Containern ist die häufigste Ursache für eine Integration, die "gestern noch funktionierte". Wenn Sie NTP auf dem Host nicht kontrollieren können, fragen Sie den Server-Zeit-Endpunkt beim Start ab, speichern Sie das Delta und addieren Sie es zu Ihrer lokalen Uhr für jede Signatur.

Order-Ablehnungen: 43001 bis 43011 und 42002

Sobald die Authentifizierung erfolgreich ist, wandern Fehler zum Matching-Engine. Diese Codes sind günstig zu beheben, aber teuer zu ignorieren, da ein Bot, der eine abgelehnte Order in einer engen Schleife wiederholt, den Ratenbegrenzer trifft und das eigentliche Problem maskiert.

Was erfahrene Trader erwischt, ist 40704 Only query data for the last three months. Das Nachladen der Handelshistorie über 90 Tage hinaus funktioniert nicht über die Standard-Query-Endpunkte, daher muss jeder Abgleich-Job Fills speichern, während sie passieren.

Was einen 429 auf der WEEX API auslöst

Die Zugriffsbeschränkungsregeln setzen ein Standardlimit von 10 Anfragen pro Sekunde, sofern nicht anders angegeben. Das Überschreiten gibt 429 Too Many Requests zurück.

Drei Eigenschaften dieses Limits ändern, wie Sie darum herum designen sollten:

• Authentifizierte Anfragen werden pro API-Schlüssel gezählt, unauthentifizierte pro öffentlicher IP. Zwei Bots mit einem Schlüssel teilen ein Budget. Zwei Bots auf einem Server mit separaten Schlüsseln nicht — aber ihr öffentliches Marktdaten-Polling schon, da dies nach IP gezählt wird.
• Eine Batch-Order über mehrere Paare zählt als eine Anfrage. Wenn Sie ein Grid platzieren oder ein Buch rebalancen, ist Batching keine Mikro-Optimierung; es ist ein 40-facher Durchsatzunterschied.
• Retries zählen. Ein exponentielles Backoff, das bei 429 sofort wiederholt, hält Sie gedrosselt. Backoff mit Jitter und veraltete Orders verwerfen, anstatt sie in die Warteschlange zu stellen.

Ein praktisches Budget: Reservieren Sie etwa 60–70% des Limits für den Order-Flow, lassen Sie den Rest für Guthaben- und Positions-Polling und verschieben Sie alles, was Sie können, auf WebSocket. Orderbuch-Daten über REST sind der häufigste Grund, warum ein gut funktionierender Trading-Bot ratenbegrenzt wird.

Falsche Basis-Domain und IP-Whitelist-Fehler

Zwei Fehler melden sich so schlecht, dass sie einen eigenen Abschnitt verdienen.

40102 Trading pair configuration does not exist bei einem Paar, das Sie handeln sehen, ist meist kein Symbol-Problem. WEEX teilt REST auf https://api-spot.weex.com für Spot und https://api-contract.weex.com für Kontrakte auf. Ein Futures-Symbol, das an die Spot-Domain gesendet wird, löst diesen Fehler aus. Prüfen Sie den Host, bevor Sie das Symbol prüfen.

40018 Illegal IP request bedeutet, dass die aufrufende IP nicht auf der Whitelist des Schlüssels steht. Die unangenehme Seite ist, was dies ohne Ihr Wissen ändert: ein Cloud-Provider, der eine Egress-IP rotiert, ein NAT-Gateway-Failover, ein VPN-Reconnect oder eine IPv6-Adresse, wenn Sie IPv4 gewhitelistet haben. Sie können einen Schlüssel erstellen, der nicht an eine IP gebunden ist, aber für einen Handels-Schlüssel ist das ein Sicherheitsrisiko. Pinnen Sie die IP und überwachen Sie Änderungen.

Breiterer Kontext darüber, wie REST und WebSocket zusammenpassen, wird im WEEX-Wiki-Erklärer darüber behandelt, ob WEEX API-Handel unterstützt.

Ein 5-Minuten WEEX API Triage-Checkliste

Führen Sie dies in der Reihenfolge aus, bevor Sie ein Support-Ticket öffnen.

Wenn jeder Schritt besteht und Aufrufe immer noch fehlschlagen, sind die verbleibenden Codes — 40013, 40015, 40409, 40725, 41101 — diejenigen, für die der WEEX-Support explizit um ein Ticket bittet. Fügen Sie den Anfrage-Zeitstempel, den Endpunkt und den zurückgegebenen Code hinzu. Die vollständige offizielle Referenz ist die WEEX API-Fehlercodeliste.

Was die Fehlercodes über Ihre Integration aussagen

Ranken Sie Ihre Fehler nach Ebene, nicht nach Häufigkeit. Hundert 429er sind ein Durchsatz-Design-Problem, das Sie an einem Nachmittag tunen können. Ein einzelner intermittierender 40009 ist ein Signier-Bug, der Orders im schlimmsten Moment stillschweigend fallen lässt, und es ist derjenige, den es sich lohnt zuerst zu beheben. Integrationen, die auf der WEEX API gesund bleiben, teilen drei Gewohnheiten: sie signieren bei jedem Retry neu, sie vertrauen niemals der lokalen Uhr und sie loggen die Wire-Anfrage anstelle der beabsichtigten Anfrage.

Bereit zu bauen? Erstellen und scopieren Sie Ihre Schlüssel auf der WEEX API-Seite, starten Sie mit einem Read-only-Schlüssel gegen die öffentlichen Endpunkte und fügen Sie Handelsberechtigungen erst hinzu, wenn Ihre Triage-Checkliste sauber durchläuft.

FAQ

1. Was bedeutet Fehler 40009 auf der WEEX API?

API validation failed ist ein Signatur-Mismatch, viel öfter als ein schlechter Schlüssel. Bauen Sie den Prehash-String als timestamp + METHOD + path + ?query + body neu auf, bestätigen Sie, dass die Methode großgeschrieben ist, und stellen Sie sicher, dass Ihre HTTP-Bibliothek den JSON-Body nach dem Signieren nicht neu serialisiert.

2. Warum funktioniert meine WEEX API-Anfrage lokal, scheitert aber mit 40008 in der Produktion?

Fast immer Host-Uhrdrift. Der signierte Zeitstempel muss innerhalb von 30 Sekunden der WEEX-Serverzeit liegen, und Container laufen häufig ohne NTP. Synchronisieren Sie die Host-Uhr oder cachen Sie den Offset vom öffentlichen Server-Zeit-Endpunkt beim Start.

3. Was ist das WEEX API-Ratenlimit?

Der Standard sind 10 Anfragen pro Sekunde, sofern nicht anders angegeben, gezählt pro API-Schlüssel für authentifizierte Aufrufe und pro öffentlicher IP für unauthentifizierte, wie am 27. Juli 2026 dokumentiert. Überschreiten gibt 429 zurück.

4. Kann ich einen WEEX API-Schlüssel ohne IP-Whitelist verwenden?

Ja — WEEX-Support schlägt vor, einen Schlüssel zu erstellen, der nicht an eine IP gebunden ist, wenn 40018 Illegal IP request Sie blockiert. Reservieren Sie das für Read-only-Schlüssel. Ein Handels- oder Auszahlungsschlüssel ohne IP-Beschränkung funktioniert von überall, was ein Sicherheits-Downgrade ist.

5. Warum erhalte ich 40102 für ein Handelspaar, das eindeutig existiert?

Sie rufen wahrscheinlich die falsche Basis-Domain auf. Spot-Anfragen gehen an https://api-spot.weex.com und Kontrakt-Anfragen an https://api-contract.weex.com; ein Futures-Symbol auf dem Spot-Host erzeugt genau diesen Fehler.

6. Ist die WEEX API dieselbe wie das Apache Weex-Framework?

Nein. Die WEEX-Börsen-API ist eine REST- und WebSocket-Handelsschnittstelle. Apache Weex ist ein eingestelltes mobiles UI-Framework mit unabhängigen Fehlercodes wie -1001.

Risikowarnung

Krypto-Assets sind volatil, und der Handel mit ihnen — manuell oder über die WEEX API — kann zu teilweisem oder totalem Verlust Ihrer Mittel führen. Automatisierter Handel fügt Fehlermodi hinzu, die manueller Handel nicht hat: ein unbehandelter Fehlercode kann Positionen offen oder dupliziert lassen, ein ratenbegrenzter Cancel kann fehlschlagen, während ein Fill durchgeht, Uhrdrift kann risikoreduzierende Orders stillschweigend ablehnen, und ein API-Schlüssel ohne IP-Beschränkungen oder Scope-Limits ist ein Anmeldedatum, das ein Angreifer von überall nutzen kann. Futures-Handel auf WEEX beinhaltet Hebelwirkung, die Gewinne und Verluste vergrößert und Liquidation schneller auslösen kann, als ein Bot reagieren kann. Testen Sie mit der kleinsten legalen Ordergröße, verwenden Sie Read-only-Schlüssel, bis Ihre Fehlerbehandlung bewiesen ist, setzen Sie Positions- und Verlustlimits außerhalb Ihrer Handelslogik und gewähren Sie niemals Auszahlungsberechtigungen an einen Schlüssel, der sie nicht benötigt. Nichts hier ist eine Anlageberatung. Wenn Sie wissen möchten, was ist eine Futures-API?, lesen Sie unseren Leitfaden.