Hoe ga je om met 'ConnectionTimeouts' in je API calls?

Alex de Vries

Quantitatief Analist & Algo-Trading Expert

Een ConnectionTimeout in je API call is als een telefoon die overgaat maar niemand opneemt: je weet dat je verbinding probeert te maken, maar er komt geen reactie terug. In de wereld van algoritmische trading bots is dit een veelvoorkomend probleem dat je live bot stil kan leggen op momenten dat de markt onrustig is.

Je wilt niet dat je bot stilvalt tijdens een volatile candle op de NASDAQ of wanneer de BTC koers plotseling beweegt. Een timeout betekent dat je verzoek naar de broker API niet binnen de verwachte tijd een antwoord krijgt. Dit kan leiden tot gemiste trades, verkeerde posities en dus verlies. Je wilt dit oplossen met een praktische aanpak die je direct kunt toepassen.

Wat je nodig hebt voordat je begint

Je hebt een werkende Python-omgeving nodig, bij voorkeur versie 3.9 of hoger. Gebruik een virtuele omgeving met venv of Conda om je packages gescheiden te houden.

Voor backtesting en live trading is een stabiele internetverbinding essentieel, met een ping naar je broker API die onder de 100 ms blijft.

Een broker API met een stabiele endpoint, zoals Interactive Brokers, Alpaca, Binance of Kraken, is nodig. Je hebt een API key en secret nodig, en voor IBKR een TWS-account met gateway-toegang. Gebruik bibliotheken zoals requests, httpx of aiohttp voor HTTP-calls, en voor IBKR de ib_insync library.

Installeer een logger zoals loguru of structlog voor duidelijke logging. Zorg dat je een fallback broker account hebt voor redundancy. Tijdens development is een testaccount met nep-geld veilig en verstandig. Reken op een uur voor de initiële setup, plus een half uur per extra broker integratie.

• Python 3.9+ en een virtuele omgeving
• requests, httpx of aiohttp
• ib_insync voor Interactive Brokers
• loguru of structlog voor logging
• API keys en een testaccount bij je broker

Stap 1: Begrijp waarom timeouts gebeuren

Een ConnectionTimeout is een netwerkprobleem, niet per se een programmeerfout. Het kan liggen aan je internetverbinding, de broker server, of een te korte time-out instelling.

Bij een REST API geef je een maximum aantal seconden mee voor een response. Bij websockets is er een heartbeat die moet blijven kloppen. Bij IBKR gateways is de socket connectie gevoelig voor onderbrekingen.

Je bot moet weten hoe het moet reageren als er geen antwoord komt.

De oplossing is niet één magische instelling, maar een combinatie van slimme timeouts, retries en backoff. Veelgemaakte fout: een timeout van 0,5 seconden instellen bij een broker die 1 tot 3 seconden nodig heeft voor complexe orderbevestigingen. Of geen retry logic bouwen, waardoor een enkele glitch je bot stillegt. Een andere fout is geen onderscheid maken tussen een netwerkfout en een broker error.

Een timeout is een netwerkfout; een 429 rate limit error is iets anders. Log altijd het exacte fouttype en de endpoint die je aanroept.

Een timeout is geen ramp, het is een seintje dat je bot moet vertragen en herproberen.

Stap 2: Kies de juiste HTTP client en time-out settings

Gebruik requests voor eenvoudige REST calls met een timeout tuple. Zet de connectie timeout op 3 seconden en de read timeout op 10 seconden.

Dat betekent: de verbinding moet binnen 3 seconden tot stand komen, en de server moet binnen 10 seconden een response sturen. Voor meer performance en async gebruik je httpx of aiohttp. Stel een pool limit in om niet te veel parallelle connecties naar dezelfde broker endpoint te openen.

1. Installeer je client: pip install requests of pip install httpx.
2. Stel timeouts in: timeout=(3, 10) voor requests, of timeout=httpx.Timeout(3.0, read=10.0) voor httpx.
3. Beperk concurrency: gebruik een semaphore of pool limit van maximaal 5 tot 10 connecties per endpoint.
4. Test met een trage endpoint: gebruik een testserver of een langzame broker demo om je timeout te valideren.

Voor IBKR met ib_insync zorg je dat de gateway draait en dat je een heartbeat interval instelt van 30 seconden. Specifieke maatvoering: houd connectie timeout tussen 2 en 5 seconden voor de meeste REST APIs.

Read timeout tussen 10 en 30 seconden voor orderbevestigingen. Voor market data streams mag de read timeout korter, maar zorg voor een heartbeat.

Veelgemaakte fout: een read timeout van 60 seconden instellen waardoor je bot vastloopt op een hanging request. Een andere fout is geen timeout instellen, waardoor je bot oneindig blijft wachten.

Stap 3: Bouw retries met exponential backoff

Retries zijn je redding bij tijdelijke netwerkproblemen. Gebruik exponential backoff: na elke mislukte poging wacht je langer, zodat je de broker niet overlaadt.

Zet een maximum aantal retries op 3 tot 5, afhankelijk van je risicotolerantie. Voor transacties zoals plaatsen of annuleren van orders moet je voorzichtig zijn: je wilt geen dubbele orders. Gebruik idempotente keys waar mogelijk, en check je rate limit status voordat je opnieuw stuurt.

1. Defineer een retry functie die een HTTP call uitvoert en bij timeout opnieuw probeert.
2. Stel backoff in: wacht 1 seconde na de eerste mislukking, 2 seconden na de tweede, 4 seconden na de derde.
3. Beperk retries tot 3 voor cancellations, en tot 5 voor market data requests.
4. Log elke retry met endpoint, fouttype en wachttijd.

Specifieke maatvoering: gebruik een jitter van ±0,5 seconden om te voorkomen dat meerdere bots synchroon gaan retryen. Tijd per retry: 1 tot 8 seconden, afhankelijk van de stap.

Veelgemaakte fout: oneindig retries zonder backoff, wat leidt tot rate limits en extra timeouts.

Een andere fout is geen onderscheid maken tussen GET en POST: voor POST-orders controleer je altijd eerst de orderstatus.

Stap 4: Implementeer fallbacks en redundancy

Zorg dat je bot niet afhankelijk is van één broker of één endpoint.

Gebruik een secundaire broker voor dezelfde markt, of een extra data provider. Als de primary endpoint time-outt, switch je naar de fallback voor market data of orders.

1. Configureer een tweede broker API key en endpoint in je config.
2. Bouw een eenvoudige switch-logica: bij 3 timeouts in 1 minuut, activeer fallback.
3. Test de fallback met een simulated market event, bijvoorbeeld een NASDAQ flash crash.
4. Log de switch en herstel momenten voor analyse.

Gebruik een circuit breaker: na een aantal opeenvolgende timeouts blokkeer je de endpoint tijdelijk en schakel je over. Dit voorkomt een cascade van fouten tijdens een marktcrash. Specifieke maatvoering: houd een downtime window van 2 minuten voordat je terugschakelt naar de primary endpoint. Gebruik een watchdog timer die elke 30 seconden de endpoint bereikbaarheid test.

Veelgemaakte fout: geen fallback testen en pas tijdens een live incident erachter komen dat de fallback niet werkt.

Een andere fout is het niet synchroniseren van posities tussen brokers, wat leidt tot dubbele exposure.

Stap 5: Monitor en log tijdens live bots

Goede logging helpt je snel te debuggen. Log elk API verzoek met timestamp, endpoint, parameters en de gebruikte timeout. Log specifiek timeouts en retries met fouttype en duur. Gebruik een dashboard voor real-time monitoring van je bot, bijvoorbeeld met Grafana en Prometheus, of een eenvoudig CSV log dat je in Python analyseert. Stel alerts in bij meer dan 5 timeouts per uur of een retry rate boven de 20 procent.

1. Voeg logging toe aan je API client: request ID, timestamp, response time, fouttype.
2. Meet response times per endpoint en stel een baseline in van 1 tot 3 seconden voor REST.
3. Creëer een alert via email of Slack bij bovengrens van timeouts.
4. Exporteer metrics wekelijks en tune timeouts op basis van gemiddelden.

Specifieke maatvoering: gebruik een log level INFO voor normale calls en WARNING voor retries, ERROR voor falende calls. Houd een rolling window van 24 uur voor je metrics. Veelgemaakte fout: te veel loggen zonder filter, waardoor je het overzicht verliest. Een andere fout is het niet bewaren van request IDs voor troubleshooting met je broker support.

Stap 6: Testen en verificatie

Test je timeout en retry strategie met een testaccount en een gesimuleerde markt.

Gebruik een mock server of een trage broker demo om timeouts te forceren. Draai een backtest met een Python script dat dezelfde API calls maakt als je live bot, en introduceer kunstmatige vertragingen. Valideer dat je bot netjes omgaat met timeouts en optimaliseer je server performance zodat je geen dubbele orders plaatst.

1. Simuleer een timeout door een endpoint tijdelijk te blokkeren of een vertraging van 5 seconden in te voeren.
2. Controleer of je retry logic correct backofft en niet meer dan 3 tot 5 retries doet.
3. Test fallback actie door de primary endpoint uit te schakelen en te switchen naar de secundaire.
4. Voer een live test met een klein bedrag, bijvoorbeeld €10 tot €50, om orderbevestigingen te controleren.

Test ook websockets en IBKR gateways met een heartbeat interval. Specifieke maatvoering: houd een testduur van minimaal 30 minuten met 10 tot 20 API calls per minuut.

Controleer dat je geen timeouts meer hebt na tuning, of dat deze beperkt blijven tot minder dan 5 procent van de calls.

Veelgemaakte fout: alleen in rustige markten testen, waardoor je tijdens volatile momenten alsnog timeouts ervaart. Een andere fout is het niet testen van annuleringen, die gevoelig zijn voor duplicate orders. Blijf kalm bij een live bug als er echt geld op het spel staat.

Verificatie-checklist

• Timeouts zijn ingesteld: connectie 3 seconden, read 10 seconden voor REST.
• Retry logic met exponential backoff is geïmplementeerd tot max 5 pogingen.
• Loggen is actief met request IDs, timestamps en fouttypes.
• Fallback broker of endpoint is geconfigureerd en getest.
• Circuit breaker is actief na 3 timeouts in 1 minuut.
• Alerts zijn ingesteld bij meer dan 5 timeouts per uur.
• Live test uitgevoerd met een klein bedrag en orderbevestigingen gecontroleerd.
• Dashboard of monitoring is zichtbaar voor real-time metrics.

Met deze aanpak ga je rustig en effectief om met ConnectionTimeouts in je API calls. Je bot blijft stabiel, je risico blijft beheersbaar en je kunt je concentreren op je strategie in plaats van op netwerkproblemen.