Ein Trading-Bot lebt vollständig von der API seiner Börse: Marktdaten rein, Orders raus, Kontostand abgleichen. Diese Verbindung fühlt sich unbegrenzt an — ist sie aber nicht. Jeder Anbieter deckelt, wie viele Anfragen ein Client in einem Zeitfenster stellen darf. Für den Betreiber ist das keine Fußnote in der Dokumentation, sondern eine Betriebsgrenze mit direkten Folgen: Ein Bot, der sein Request-Budget nicht kennt, verliert im entscheidenden Moment die Verbindung zu seinem eigenen Konto.
Warum Börsen überhaupt drosseln
Rate Limits sind kein Schikane-Instrument, sondern Selbstschutz der Infrastruktur. Eine Börse bedient tausende Clients gleichzeitig; ohne Grenzen könnte ein einzelner fehlerhafter Bot — etwa eine Endlosschleife, die im Millisekundentakt den Kontostand abfragt — die Antwortzeiten für alle verschlechtern. Die Drosselung verteilt die Kapazität fair und hält das System stabil. Für Bot-Betreiber bedeutet das: Die Grenze ist legitim, dokumentiert und nicht verhandelbar. Die einzige Frage ist, ob der eigene Bot sie respektiert oder gegen sie läuft.
Wie Rate Limits typischerweise aufgebaut sind
- Request-Gewichte: Nicht jede Anfrage zählt gleich. Ein einfacher Preisabruf kostet wenig Budget, ein kompletter Orderbuch-Snapshot deutlich mehr. Gezählt wird oft ein gewichtetes Punktekonto pro Zeitfenster.
- Order-Limits: Für das Platzieren und Stornieren von Orders gelten meist eigene, engere Grenzen — pro Sekunde, Minute und Tag.
- IP- vs. Key-Limits: Manche Grenzen gelten pro IP-Adresse, andere pro API-Key oder Konto. Mehrere Bots hinter derselben IP teilen sich unbemerkt ein Budget.
- Stream-Limits: Auch WebSocket-Verbindungen sind begrenzt — in Anzahl, Abonnements und Reconnect-Frequenz.
- Eskalationsstufen: Erst Fehlercodes wie HTTP 429, bei Wiederholung temporäre Sperren von IP oder Key.
Der gefährlichste Moment: Stress trifft Limit
Im Normalbetrieb reißt kaum ein solide gebauter Bot sein Limit. Kritisch wird es genau dann, wenn der Markt hektisch wird: Der Kurs springt, der Bot will Stops nachziehen, Orders stornieren, Positionen prüfen — und gleichzeitig bricht vielleicht die WebSocket-Verbindung, worauf die Software mit schnellen Reconnects und Daten-Nachladungen reagiert. Alle diese Aktionen zahlen auf dasselbe Budget ein. Das Ergebnis ist eine bittere Ironie: Ausgerechnet in der Phase, in der Kontrolle am wichtigsten wäre, sperrt sich der Bot durch sein eigenes Anfrageverhalten aus. Ein Kill-Switch, der wegen Rate-Limit-Sperre keine Stornierung mehr durchbekommt, ist keiner.
Ein Rate Limit ist wie ein Notausgang mit Drehkreuz: Im Alltag fällt es nicht auf — aber wenn alle gleichzeitig hindurchwollen, entscheidet die Planung davor, ob man durchkommt. Deshalb gehört das Budget in das Design des Bots, nicht in die Fehlerbehandlung.
Throttling und Backoff als Designprinzip
Der saubere Umgang beginnt clientseitig, bevor die Börse eingreifen muss. Ein lokaler Budget-Zähler bildet die dokumentierten Grenzen im Bot nach und bremst Anfragen, bevor das Limit erreicht ist — viele APIs liefern den aktuellen Verbrauch sogar in den Antwort-Headern mit. Kommt es doch zu einem 429, gilt Exponential Backoff mit Jitter: Nach jedem Fehlversuch wächst die Wartezeit deutlich, eine kleine Zufallskomponente verhindert, dass viele Clients synchron erneut anfragen. Genauso wichtig ist die Priorisierung: Wenn das Budget knapp wird, haben sicherheitsrelevante Aktionen — Orders stornieren, Positionen schließen — Vorrang vor Komfortabfragen wie Statistiken oder redundanten Kontoständen. Und wer Marktdaten per Stream statt per Dauer-Polling bezieht, entlastet das Budget strukturell; die Abwägung dazu steht im Beitrag WebSocket vs. REST.
Grenzen des Themas
Rate-Limit-Disziplin macht einen Bot robuster, aber nicht profitabler: Sie verhindert eine Klasse von Betriebsausfällen, sagt jedoch nichts über die Qualität der Strategie aus. Zudem ändern Börsen ihre Grenzen und Gewichtungen regelmäßig — ein Bot, der heute sauber unter dem Limit läuft, kann nach einem API-Update darüber liegen. Die Limits gehören deshalb in das Monitoring und in jeden Review, nicht in einen einmal gesetzten Konfigurationswert, den nie wieder jemand ansieht.
Dieser Beitrag dient ausschliesslich der Information und Bildung. Er ist keine Anlageberatung und keine Handelsempfehlung. Automatisierter Handel ist mit erheblichen Risiken bis hin zum Totalverlust verbunden; auch ein technisch sauber gedrosselter Bot schützt nicht vor Marktverlusten.