Wat zijn 'Rate Limits' en hoe voorkom je een IP-ban?
Je zit lekker te coderen aan je Python trading bot, je backtest draait als een zonnetje en dan ineens: error. Of erger: je IP-adres is geblokkeerd.
Het voelt oneerlijk, maar het gebeurt vaker dan je denkt. Rate limits zijn de onzichtbare hekken die brokers zoals Interactive Brokers, Alpaca of Binance optrekken rond hun API’s.
Ze beschermen de infrastructuur tegen overbelasting. Begrijp je deze limieten niet, dan kost je dat tijd, geld en soms zelfs toegang tot je account. Dit is je stappenplan om slim te blijven draaien zonder tegen een muur op te lopen.
Stap 1: Ken je materiaal – wat heb je nodig?
Voordat je code schrijft, verzamel je de juiste tools. Een Python-omgeving met de juiste packages is essentieel.
- Python 3.9 of nieuwer op je machine.
- Voorbeeld-brokers: Interactive Brokers TWS API, Alpaca API, Binance Spot API.
- Pakketten: requests, ib_insync, alpaca-trade-api, python-binance, time, ratelimit.
- Een API-sleutel en een secret, bewaard in een .env-bestand.
- Een simpele testbot die 1 trade per minuut doet, max 10 trades per uur.
Zonder die basis loop je vast op simpele dingen. Reken op een uur voorzetten om je omgeving te installeren en te testen.
Een veelgemaakte fout is het verkeerd opslaan van je API-sleutels. Gebruik nooit hardcoded strings in je code; dat is een open uitnodiging voor problemen.
Stap 2: Begrijp wat rate limits zijn en waarom ze bestaan
Rate limits zijn maximumaantallen verzoeken per tijdseenheid die je naar een API mag sturen. Denk aan 120 requests per minuut bij Alpaca, of 1200 requests per minuut bij Binance.
Rate limits zijn geen straf; ze zijn een afspraak over hoe je de infrastructuur deelt.
Ze beschermen de broker tegen overbelasting en oneerlijke verkeersstromen. Een veelgemaakte fout is denken dat meer requests altijd beter zijn. Dat is niet zo.
Je bot kan sneller zijn dan de markt, en de broker kan je dan blokkeren om stabiliteit te garanderen.
Houd rekening met limieten per endpoint: marktdata heeft vaak andere limieten dan order endpoints. Stel een persoonlijke limiet in: bijvoorbeeld 80% van de officiële broker-limiet. Als Alpaca 120/minuut toestaat, plan dan max 96/minuut. Dit geeft je een veiligheidsmarge voor bursts en onverwachte spikes.
Stap 3: Monitor en meet je verkeer
Je kunt pas sturen wat je meet. Implementeer een simpele teller die per endpoint bijhoudt hoeveel verzoeken je verstuurt.
Log elke call met een timestamp en endpoint naam. Gebruik een decorator of wrapper rond je API-functies.
Bijvoorbeeld een ratelimit-decorator die je bot pauzeert zodra je 80% van je limiet bereikt. Test met een backtest van 10.000 candles; tel hoeveel calls je doet per minuut. Veelgemaakte fouten: vergeten dat websockets apart tellen, of niet meten bij live trading. Een backtest kan er soepel uitzien, maar live draaien kan anders zijn. Plan een meting van 5 minuten live met kleine bedragen om je verkeer te valideren.
Stap 4: Implementeer wachtrijen en backoff
Een wachtrij is je vriend. Gebruik een queue die verzoeken netjes afwerkt, één voor één.
Bijvoorbeeld een asyncio.Queue in Python, met een worker die maximaal 5 verzoeken per seconde verstuurt.
Voeg exponential backoff toe bij fouten. Als je een 429 “too many requests” krijgt, wacht je eerst 1 seconde, dan 2, dan 4, tot een maximum van 60 seconden. Dit voorkomt dat je direct opnieuw botst tegen de limiet.
Veelgemaakte fouten: te agressief retryen, of geen timeout instellen. Zet een timeout van 10 seconden per request. Voorbeeld in Python: gebruik een try/except rond je request en log elke fout met een duidelijke boodschap.
Stap 5: Kies de juiste endpoints en optimaliseer je calls
Gebruik batch endpoints waar mogelijk. Bij Binance kun je meerdere symbolen in één call opvragen.
Bij Alpaca kun je historische data in grotere blokken ophalen. Vermijd calls die je niet nodig hebt. Cache data die niet vaak verandert, zoals kalenderinformatie of static referentiedata. Let hierbij ook op de verborgen kosten van API trading, zoals data fees. Bijvoorbeeld een korte cache van 5 minuten voor de handelskalender van Interactive Brokers.
Dit bespaart calls en verlaagt je risico op een ban. Veelgemaakte fouten: continue dezelfde data opvragen zonder caching, of onnodige diepte in orderboeken ophalen. Plan je data-strategie: welke data heb je echt nodig, en hoe vaak?
Stap 6: Handel fouten netjes af en voorkom een IP-ban
Een IP-ban is het gevolg van herhaaldelijk overschrijden van limieten of het sturen van ongeldig verkeer. Als je een ban krijgt, stop direct met alle verzoeken.
Neem contact op met de broker support, leg uit wat er gebeurde en bied aan om bijvoorbeeld je limietorder via de API aan te passen.
Voorkom een ban door je bot te voorzien van een kill-switch. Als je meer dan 3 fouten in 5 minuten krijgt, pauzeer dan 10 minuten. Log elke actie, zodat je later kunt analyseren wat er misging.
Veelgemaakte fouten: doorgaan met retryen zonder pauze, of vergeten om je IP-adres te whitelisten bij de broker. Controleer of je broker IP-whitelisting ondersteunt, en vraag dit aan bij een zakelijk account.
Stap 7: Test je setup met een backtest en live simulatie
Run een backtest die 10.000 candles verwerkt, met een bot die 1 trade per minuut doet. Controleer of je onder de limiet blijft.
Gebruik een simulator die echt API-calls maakt, niet alleen lokale data. Voer een live test uit met kleine bedragen, bijvoorbeeld €50 tot €100 per trade. Monitor de call-count per minuut en voorkom problemen door rate limiting als je te dicht bij de limiet komt.
Veelgemaakte fouten: alleen in backtest testen, of vergeten dat live marktdata meer calls kan genereren.
Plan een test van minimaal 30 minuten live om je verkeerspatroon te valideren.
Verificatie-checklist
- Je Python-omgeving draait met de juiste packages en API-sleutels.
- Je kent de officiële rate limits van je broker per endpoint.
- Je persoonlijke limiet is ingesteld op 80% van de broker-limiet.
- Je meet en logt elk API-verzoek met timestamp en endpoint.
- Je hebt een wachtrij en backoff-strategie geïmplementeerd.
- Je gebruikt batch endpoints en caching waar mogelijk.
- Je bot heeft een kill-switch en pauzeert bij herhaalde fouten.
- Je hebt een backtest en live simulatie gedraaid en gevalideerd.
Met deze stappen blijf je binnen de limieten en voorkom je een IP-ban. Je bot blijft soepel draaien, je risico beheerst, en je kunt je focussen op wat telt: strategie verbeteren en winstgevendheid.