Wat zijn de API-beperkingen van Ibkr?
De Interactive Brokers (IBKR) API kent specifieke beperkingen, voornamelijk gericht op het beheer van historische dataverzoeken om de systeembelasting te reguleren. Gebruikers kunnen maximaal 50 gelijktijdige open historische dataverzoeken indienen. Het overschrijden van deze limieten of het aanvragen van te veel data kan leiden tot throttling, waardoor verzoeken vertraagd worden, en zelfs tot een ontkoppeling van de API-client.
De API van Interactive Brokers (IBKR) is ontworpen om een efficiënte en stabiele handelsomgeving te waarborgen, wat betekent dat er duidelijke technische en functionele beperkingen zijn ingesteld. Deze beperkingen zijn vooral merkbaar bij het opvragen van historische data, een veelvoorkomende activiteit voor algoritmische handelaren en analisten.
Een van de belangrijkste beperkingen is het maximum van 50 gelijktijdige open historische dataverzoeken. Dit betekent dat uw API-client op elk willekeurig moment niet meer dan vijftig actieve aanvragen voor historische data mag hebben. Het is cruciaal om dit aantal te monitoren en te beheren binnen uw applicatie om problemen te voorkomen.
Bij het indienen van historische dataverzoeken is het essentieel om deze zo efficiënt mogelijk samen te stellen. Verzoeken moeten zodanig worden geformuleerd dat ze slechts enkele duizenden bars tegelijk retourneren. Het aanvragen van te grote datasets in één keer kan de API overbelasten, wat resulteert in vertragingen en potentiële onderbrekingen van uw datafeed.
Interactive Brokers implementeert een mechanisme genaamd een "soft slow" om clientverzoeken te load-balancen. Dit betekent dat wanneer het systeem merkt dat er te veel verzoeken binnenkomen, het de snelheid van de responsen geleidelijk zal vertragen in plaats van direct te weigeren. Echter, als de belasting aanhoudt en de limieten structureel worden overschreden, kan dit leiden tot throttling en uiteindelijke ontkoppeling van de API-client. Een ontkoppeling vereist handmatige herverbinding en kan uw handelsstrategieën ernstig verstoren.
Een specifieke nuance betreft de manier waarop bepaalde dataverzoeken worden geteld. Historische dataverzoeken voor BID_ASK data tellen als twee afzonderlijke verzoeken tegen de limiet van 50 gelijktijdige verzoeken. Dit is een belangrijke overweging bij het ontwerpen van strategieën die afhankelijk zijn van deze specifieke datatypes, aangezien ze de beschikbare capaciteit sneller verbruiken.
Veel gebruikers zoeken naar manieren om API-beperkingen te omzeilen om sneller of meer data te verkrijgen. Het is echter belangrijk te benadrukken dat de API-beperkingen van Interactive Brokers niet te omzeilen zijn. Deze limieten zijn ingebouwd in het systeem om de stabiliteit en eerlijkheid van de dienstverlening voor alle gebruikers te garanderen. Pogingen tot omzeiling kunnen leiden tot ernstige beperkingen of zelfs opschorting van de API-toegang.
Om efficiënt met de IBKR API te werken en throttling te voorkomen, kunnen de volgende richtlijnen helpen:
- Beperk gelijktijdige verzoeken: Zorg dat uw applicatie nooit meer dan 50 open historische dataverzoeken tegelijkertijd heeft. Implementeer een wachtrij en een mechanisme om verzoeken sequentieel te verwerken.
- Optimaliseer data-omvang: Splits grote historische data-aanvragen op in kleinere segmenten die elk slechts enkele duizenden bars retourneren. Vraag bijvoorbeeld data op per dag of per week in plaats van een heel jaar in één keer.
- Houd rekening met BID_ASK: Als u BID_ASK data opvraagt, weet dan dat deze dubbel tellen. Pas uw gelijktijdige verzoeklimiet hierop aan om onverwachte overschrijdingen te voorkomen.
- Implementeer vertragingen: Voeg opzettelijke vertragingen toe tussen opeenvolgende verzoeken, vooral na het ontvangen van een "soft slow" signaal, om de API de tijd te geven om te herstellen.