← Alle Insights
8 Min. Lesezeit · Infrastruktur · Januar 2030

API-Edge-Cases bei Brokern: was Sie aus der Doku nie erfahren.

Jede Broker-API hat eine offizielle Doku — und eine zweite, ungeschriebene, die man erst durch Schaden lernt. Rate-Limits, die niedriger sind als dokumentiert. Reject-Codes, die nirgends erklärt werden. Partial-Fills, die als Done markiert sind. Hier die wichtigsten Edge-Cases aus zehn Jahren Live-Trading-Bots.

Wenn ich neue Trader berate, ist die häufigste Frage: „Welcher Broker hat die beste API?" Die ehrliche Antwort: keiner. Sie haben alle ihre Eigenheiten, und jede einzelne wird Ihren Bot irgendwann beißen. Was hilft, ist defensive Programmierung als Default — und ein Katalog typischer Stolpersteine.

Rate-Limits: meistens niedriger als dokumentiert.

Broker veröffentlichen Rate-Limits typischerweise als „X Requests pro Minute" oder als „Weight-Score". Die Realität:

Schutz: Token-Bucket-Rate-Limiter clientseitig, eingestellt auf 70–80 % des dokumentierten Limits. Plus: 429-Response als Backoff-Trigger behandeln, nicht als reines Logging.

Order-Reject-Reasons: kryptisch und uneinheitlich.

Wenn eine Order abgelehnt wird, sollte die API klar sagen warum. Die Realität:

Mein Vorgehen: zentrale Reject-Handler-Funktion mit einem manuell gepflegten Mapping von Code/Message zu Handlungsklasse — „Retry erlaubt", „Position-Check nötig", „Strategie pausieren", „Sofort-Alert". Jeder neue Reject-Code löst einen Telegram-Alert aus, dann erweitere ich das Mapping.

Partial-Fills, die als Done markiert sind.

Klassischer Bug, vor allem bei IBKR und MT5: eine Limit-Order wird zu 80 % gefüllt, der Rest verfällt, die Order wechselt in Status Filled oder Cancelled. Wer naiv aus dem Order-Status auf die Position schließt, hat ein Problem — geplant: 100 Stück long, real: 80.

Schutz: nach jedem Order-Done-Event nicht den Order-Status vertrauen, sondern die tatsächliche Position abfragen. Bei Diskrepanz: Reconciliation aktivieren. Das gilt auch für FX und Crypto, wo Partial-Fills bei Marktorder seltener sind, aber bei Limit-Orders mit IOC oder GTD-Flag durchaus vorkommen.

Disconnects ohne Notification.

Eine Verbindung kann abreißen, ohne dass die API es Ihnen mitteilt. Sie senden weiter Orders, die im Nichts verschwinden, oder Sie warten auf Quotes, die nie kommen. Bei IBKR TWS passiert das z. B. nach dem täglichen Auto-Restart (typisch 23:45–00:15 Uhr ET) — die Socket-Connection bleibt offen, aber alle Subscriptions sind weg.

Schutz: Heartbeat-Mechanismus auf Anwendungsebene. Pro Verbindung ein „last event received"-Timestamp. Wenn länger als X Sekunden nichts kommt (je nach Marktphase 5–60 s), aktiv pingen — wenn das fehlschlägt, hartes Reconnect mit Resubscribe und Position-Reconciliation.

Verzögerte Account-Updates nach Trades.

Nach einem Trade ist die neue Position oft nicht sofort in /account oder /positions sichtbar. Typische Verzögerungen:

Konsequenz: wenn Ihr Bot direkt nach einem Trade die Account-Position abfragt, um die nächste Order zu sizen, rechnet er mit veralteten Daten. Schutz: lokales Position-Tracking führen, das Sie aus Order-Fill-Events selbst aktualisieren. Die Broker-Position-API nur als Reconciliation alle X Minuten heranziehen.

Maintenance-Windows ohne Vorwarnung.

Selbst große Broker führen Wartungen ohne ausreichende Ankündigung durch. Binance ist hier berüchtigt: Spot-Markt geht für 30 Minuten in „No Trading"-Mode, API antwortet mit -1003 oder einfach mit leeren Responses. Bei IBKR ist der tägliche Server-Restart-Slot dokumentiert (Mitternacht ET), aber ungeplante Wartungen kommen ohne Email.

Schutz: jeder Bot muss eine Strategie für „Markt vorübergehend nicht erreichbar" haben. Mein Default: nach 3 aufeinanderfolgenden Fail-Responses Strategie pausieren (keine neuen Orders), bestehende Stop-Loss-Orders aber halten, alle 60 s Probe-Request senden. Erst nach 3 erfolgreichen Probes wieder aktiv.

Token-Expiry mitten in der Session.

OAuth-basierte APIs (Alpaca OAuth, einige Banken-APIs) und Session-basierte Logins (Binance User-Stream listenKey, IBKR-Login) haben begrenzte Lebensdauer:

Schutz: zentraler Token-Manager mit pro-aktivem Refresh, lange bevor das Token abläuft. Faustregel: refresh bei 50 % der Token-Lifetime. Nie warten, bis ein Call wegen abgelaufenem Token fehlschlägt.

Time-Zone-Bugs.

Zeitzonen sind eine eigene Klasse von Schmerz:

Schutz: alles in UTC intern speichern. Konvertierung nur an UI-Grenzen. Plus: explizite Tests rund um DST-Wechsel.

Numerische Precision.

FX-Quotes haben 5 oder 8 Nachkommastellen. Crypto-Quotes manchmal 12. JSON-Parser in Python und JavaScript machen daraus standardmäßig float — verlustbehaftet. Wer Stop-Levels auf 0.000000001 setzt und das durch JSON jagt, findet Stops bei 0.00000000099999... wieder, mit netten Reject-Errors.

Schutz: Decimal in Python verwenden, niemals float für Preise und Quantities. JSON-Parser mit parse_float=Decimal konfigurieren. Auf Datenbankebene NUMERIC(20,10) statt DOUBLE.

Meine Praxis: defensive Programmierung als Default.

Alles, was ich oben aufgezählt habe, fließt in einen Wrapper, den ich pro Broker einmal baue und dann wiederverwende. Die Komponenten:

Klingt nach viel Overhead — ist es auch. Aber es ist der Unterschied zwischen einem Bot, der drei Wochen live läuft und dann „komische Sachen macht", und einem, der zwei Jahre 24/7 läuft, ohne dass ich nachts geweckt werde.

Sie schreiben einen eigenen Bot gegen IBKR, Binance, Alpaca oder einen anderen Broker und wollen typische API-Fallen vermeiden? Erstgespräch buchen — ich schaue Ihr API-Layer durch und zeige die kritischen Punkte.