Hoe ga je om met API downtime tijdens belangrijke markt-events?
Stel je voor: het is 15:30 uur, de Fed-voorzitter begint te praten, en je Python-bot draait op volle toeren. Je hebt net een shortpositie geopend op de NASDAQ-futures. En dan… stilte.
De API-verbinding van je broker hapert, je bot krijgt geen data meer, en je zit vast zonder stop-loss te kunnen plaatsen.
Je hartslag schiet omhoog. Dit is de nachtmerrie van elke algoritmische trader. API-downtime tijdens cruciale markt-events is niet alleen vervelend, het kan je portfolio in een paar minuten verwoesten.
Maar er is een plan. Je kunt je voorbereiden, je bot bouwen om te falen, en je risico’s beheren zodat je nooit meer met lege handen staat. Laten we samen een ijzersterk protocol opbouwen.
Wat je nodig hebt: de basis voor een crash-proof setup
Voordat we beginnen, zorg dat je de juiste tools en accounts hebt.
Zonder deze basis bouw je op drijfzand. Je hebt een live broker-account nodig met een stabiele API.
Denk aan Interactive Brokers (IBKR) voor hun TWS API, of een crypto-exchange als Binance of Kraken voor hun REST- en WebSocket-APIs. Een demo-account volstaat niet voor deze stappen, je hebt toegang tot echt geld of paper trading nodig dat live data simuleert. Een tweede broker is essentieel voor redundancy. Open een tweede account bij een andere broker, bijvoorbeeld als je primary broker Interactive Brokers is, neem dan een secondary bij TradeStation of een crypto-exchange.
Je hebt minimaal €500 nodig op elk account om actief te kunnen handelen.
Een derde broker voor data-only (bijvoorbeeld een aparte datafeed van Polygon.io of een crypto-exchange) is een bonus, maar niet verplicht voor beginners. Je Python-omgeving moet stabiel zijn. Gebruik Python 3.10 of nieuwer.
Installeer een virtuele omgeving met venv of conda. Belangrijke libraries: ib_insync voor IBKR, ccxt voor crypto-exchanges, pandas voor data, numpy voor berekeningen, requests voor HTTP-calls, en websockets voor real-time data.
Je hebt ook een backtesting-framework nodig, zoals backtrader of vectorbt, om je bot te testen onder stressvolle omstandigheden.
Een tweede computer of Raspberry Pi is geen overbodige luxe. Je bot draait op je hoofd-machine, maar een lichte backup-pi draait een simpele versie die alleen data logt en alerts stuurt. Zorg voor een stabiele internetverbinding, bij voorkeur met een ethernet-kabel en een 4G-backup via je telefoon.
Tot slot: een monitoring-tool zoals prometheus of een simpel Telegram-alertscript. Je wilt direct weten als er iets misgaat.
Stap 1: Monitor je API-verbinding realtime
Je bot moet constant checken of de API leeft. Maak een heartbeat-functie die elke 5 seconden een lichtgewicht call doet, zoals het ophalen van de serverstatus of een specifieke ticker. Voor IBKR gebruik je ib_insync en check je ib.isConnected().
Voor crypto-exchanges via ccxt roep je exchange.fetch_ticker('BTC/USDT') aan. Als deze call faalt of langer dan 2 seconden duurt, trigger je een alarm.
Bouw een eenvoudige status-checker in Python. Gebruik een loop die de heartbeat elke 5 seconden uitvoert en de responstijd logt in een CSV-bestand.
Voeg een tweede check toe: een ping naar de broker’s server via subprocess.call(['ping', '-c', '1', 'broker.com']). Als de ping faalt, weet je dat het netwerkprobleem is, niet alleen de API. Sla de logs op in een mapje /logs/ met een datum-prefix, bijvoorbeeld 2024-10-15_heartbeat.csv.
Veelgemaakte fout: te veel calls maken, wat je account rate-limits raakt. Binance limiteert bijvoorbeeld tot 1200 requests per minuut voor REST, en IBKR heeft een soft-limit van 100 calls per seconde.
Test je heartbeat op een demo-account om te zien hoe snel je limiet bereikt is. Tijdsindicatie: bouw deze stap in 1-2 uur, test hem vervolgens 24 uur op een demo-account.
Stap 2: Bouw een fallback-mechanisme voor orderuitvoering
Als je API down is, wil je niet dat je bot open posities houdt zonder controle. Implementeer een fallback naar een tweede broker via de beste broker API's voor algoritmische trading.
Schrijf een wrapper-functie execute_order() die eerst je primary broker probeert. Als die faalt na 3 pogingen (elke poging 2 seconden wachten), schakelt de functie automatisch naar je secondary broker.
Voorbeeld in Python: gebruik ccxt voor meerdere exchanges. Initialiseer twee exchanges: primary = ccxt.binance() en secondary = ccxt.kraken(). In je order-functie probeer je primary.create_order(...).
Bij een fout (bijvoorbeeld HTTP 503), vang de error op met try-except en probeer secondary.create_order(...). Log elke switch in een order_log.csv met timestamp, orderdetails, en welke broker is gebruikt.
Test dit met kleine bedragen: plaats een limietorder van 0.01 BTC op beide brokers en simuleer een API-fout door je primary API-key tijdelijk te invaliden. Controleer dat de order op de secondary terechtkomt binnen 5 seconden. Veelgemaakte fout: vergeten om order-id’s te synchroniseren, waardoor je bot later dubbele orders plaatst. Los op door elke order een uniek ID te geven en betrouwbare brokers met gratis API te vragen om deze te bevestigen.
Tijdsindicatie: bouw en test deze stap in 3-4 uur. Zorg dat je fallback ook werkt voor stop-loss en take-profit orders, niet alleen voor entries.
Gebruik voor IBKR de ib_insync Order-objecten en bouw een tweede TWS-verbinding voor je secondary broker. Voor crypto is ccxt vaak voldoende.
Stap 3: Risicomanagement bij downtime: position sizing en stop-loss
API-downtime betekent dat je geen nieuwe orders kunt plaatsen, dus je risico’s moeten vooraf zijn afgedekt.
Gebruik een vast risicopercentage per trade: maximaal 1-2% van je totale kapitaal. Bereken je position size met een simpele formule: risico / (entry_price - stop_price). Voor een account van €10.000 en 1% risico (€100) op een trade met €5 marge tussen entry en stop, is je positie 20 aandelen (€100 / €5). Implementeer een time-based stop: als je bot geen data krijgt na 30 seconden, sluit dan automatisch 50% van je positie via een marketorder op de secondary broker.
Voor IBKR gebruik je ib.placeOrder(contract, market_order) op de tweede verbinding. Voor crypto: secondary.create_market_order('sell', symbol, amount).
Dit voorkomt dat je vastzit tijdens een flash crash. Test dit onder simulatie: draai je bot op een demo-account en blokkeer tijdelijk de primary API via je firewall (bijvoorbeeld met ufw op Linux: sudo ufw deny out 443 voor je primary IP).
Meet hoe lang het duurt voordat je bot reageert en hoeveel verlies je maakt. Streef naar < 1 minuut tot actie en < 0.5% verlies per incident. Veelgemaakte fout: te strakke stops instellen, waardoor je bot te snel sluit tijdens normale volatiliteit.
Pas je stops aan op basis van ATR (Average True Range), bijvoorbeeld 1.5x ATR voor je stop. Tijdsindicatie: deze stap duurt 2-3 uur voor implementatie en 4-6 uur voor testen onder verschillende marktcondities (rustig, volatiel, event-driven). Gebruik een backtesting-tool zoals vectorbt om historische downtime te simuleren door data-gaps in te voegen.
Stap 4: Data-backup en redundante datastromen
API-downtime treft niet alleen orderuitvoering, maar ook data. Zonder data kan je bot geen beslissingen nemen.
Bouw een tweede datafeed naast je primary. Gebruik voor IBKR de reqHistoricalData call, maar voeg een tweede bron toe via ccxt voor crypto, of een aparte data-provider zoals alpaca voor aandelen.
Sla lokale data op in een SQLite-database. Elke minuut schrijf je de laatste candle naar market_data.db met tabel candles (timestamp, symbol, open, high, low, close, volume). Als je API down is, schakel je over op deze lokale data voor je bot-logic.
Gebruik een eenvoudige query: SELECT * FROM candles WHERE symbol = ? AND timestamp > ? om de laatste 10 candles op te halen.
Test dit door je primary datafeed te onderbreken en te kijken of je bot nog trades kan uitvoeren op basis van lokale data. Meet de latency: lokale data moet binnen 1 seconde beschikbaar zijn. Check de snelheid van API-executie om te zien welke broker de laagste latency biedt. Veelgemaakte fout: niet synchroniseren van data tussen bronnen, wat leidt tot verkeerde signalen. Los op door timestamps te vergelijken en alleen de meest recente candle te gebruiken.
Tijdsindicatie: bouw deze stap in 2-3 uur, test met een volatiele marktperiode (bijvoorbeeld tijdens een earnings-call).
Zorg dat je database niet groeit tot meer dan 1 GB per maand; archiveer oude data wekelijks.
Stap 5: Alerts en handmatige interventie
Automatisering is top, maar soms moet je zelf ingrijpen. Zet een alert-systeem op via Telegram of email.
Gebruik een library zoals python-telegram-bot om een bericht te sturen zodra je heartbeat faalt: "API downtime gedetecteerd op Binance, tijd: 15:30:22". Stuur ook een alert als je fallback broker activeert, met de orderdetails.
Bouw een handmatige kill-switch. Een simpele knop in een web-interface (gebruik Flask voor een lichtgewicht server) of een Telegram-commando dat alle posities sluit op beide brokers. Test dit door een live trade te plaatsen en de kill-switch te activeren; controleer dat alle posities binnen 10 seconden gesloten zijn. Veelgemaakte fout: alerts die te laat aankomen door trage internetverbinding.
Los op door een tweede kanaal toe te voegen, zoals SMS via een dienst als Twilio (kosten €0.05 per bericht).
Tijdsindicatie: 1-2 uur voor implementatie, 1 uur voor testen. Zorg dat je kill-switch ook werkt als je primary broker down is, door hem op je secondary te baseren.
Verificatie-checklist
- Heartbeat-check draait elke 5 seconden en logt responstijden. Test: 24 uur op demo-account.
- Fallback-mechanisme activeert na 3 pogingen en switcht binnen 5 seconden. Test: simuleer API-fout met firewall.
- Risicomanagement: position sizing op 1-2% risico, time-based stop na 30 seconden downtime. Test: backtest met data-gaps.
- Data-backup: lokale SQLite-database met minuut-candles, switch binnen 1 seconde. Test: onderbreek primary datafeed.
- Alerts via Telegram/SMS actief, kill-switch test binnen 10 seconden. Test: plaats een live trade en activeer handmatig.
- Geen rate-limits overschreden: monitor requests per minuut (max 1200 voor Binance, 100/sec voor IBKR).
- Documenteer je setup: logfiles bijhouden en wekelijks reviewen.