Een handelsplatform is gemaakt voor interactie door een gebruiker. Een trading-API is bedoeld voor software die rechtstreeks met systemen van een broker communiceert. Dat verschil lijkt technisch, maar is vooral een keuze over uw werkwijze: wilt u handmatig orders invoeren, of moet eigen software gegevens ophalen, beslissingen verwerken of orders verzenden?
Een API is daarom geen kwaliteitslabel voor actieve beleggers. U heeft hem pas nodig wanneer een concrete workflow zonder die machine-to-machine koppeling niet goed uitvoerbaar is. Wie alleen koersen bekijkt, periodiek handmatig orders plaatst of de functies van een web- of desktopplatform gebruikt, heeft niet automatisch een trading-API nodig.
'Heeft deze broker een API?' is te grof. Een aanbieder kan bijvoorbeeld marktdata ontsluiten zonder orderinvoer toe te staan, of wel orders accepteren maar geen continue datastroom leveren. Ook kunnen verschillende rekeningen, producten of markten verschillende rechten hebben.
| Laag | Wat u ermee wilt doen | Wat u afzonderlijk controleert |
|---|---|---|
| Data-API | Koersen, posities, transacties of referentiedata ophalen | Welke data, actualiteit, historische data, marktdatarechten |
| Order- of trading-API | Orders plaatsen, wijzigen of annuleren | Producten, markten, ordertypes, accountrechten |
| Streaming | Doorlopend updates ontvangen zonder steeds opnieuw te vragen | Welke streams, verbindingslimieten, herstel na onderbreking |
| FIX | Gestandaardiseerde elektronische handelsberichten uitwisselen | Toegang, implementatie, sessie- en berichtondersteuning |
Een data-API kan informatie leveren over bijvoorbeeld rekeningposities, orderstatussen of marktdata. Dat maakt hem bruikbaar voor dashboards, rapportage of analyse. Maar toegang tot data zegt niet dat dezelfde koppeling ook orders mag versturen.
Voor geautomatiseerde orderinvoer moet de broker een handelsfunctie beschikbaar stellen én uw rekening daarvoor autoriseren. Controleer daarom afzonderlijk welke acties zijn toegestaan. 'API beschikbaar' is geen bewijs dat uw gewenste instrumenten, markten en ordertypes programmeerbaar zijn.
Bij een gewone request/response-koppeling vraagt uw software iets op en ontvangt zij een antwoord. Dat past bijvoorbeeld bij het ophalen van een rekeningoverzicht of het verzenden van een order. Voor continu veranderende gegevens kan een streamingverbinding nodig zijn, waarbij updates actief naar uw software worden gestuurd.
Het verschil is praktisch. Een strategie die slechts af en toe een portefeuille uitleest stelt andere eisen dan software die continu marktdata, orderstatussen of meerdere instrumenten volgt. Kijk daarom niet alleen naar de programmeertaal of het protocol, maar naar het communicatiepatroon dat uw workflow nodig heeft.
FIX staat voor Financial Information eXchange en is een familie van standaarden voor elektronische communicatie in de handelsketen. FIX ondersteunt gestandaardiseerde berichten voor onder meer orders, uitvoeringen en marktdata en kent eigen applicatie-, sessie- en technische lagen.
Een REST- of WebSocket-API van een retailbroker is daarom niet automatisch 'FIX'. Omgekeerd betekent FIX-ondersteuning niet dat een aansluiting hetzelfde werkt als een eenvoudige web-API. Toegang, implementatie-eisen en ondersteunde berichten kunnen verschillen. Behandel FIX dus alleen als requirement wanneer uw software of infrastructuur daadwerkelijk zo'n gestandaardiseerde koppeling nodig heeft.
Stel dat een programma eenmaal per kwartier posities controleert en zo nodig orders verstuurt. Een verbroken verbinding betekent niet automatisch dat de vorige order is geannuleerd. Na opnieuw verbinden moet de software de orderstatus daarom eerst opvragen en alleen bij een daadwerkelijk ontbrekende order opnieuw versturen. Anders kan één signaal twee transacties veroorzaken.
Vraag bij de leverancier naar authenticatie, beperkte API-rechten, data-abonnementen, maximumaanvragen per tijdseenheid, orderbevestiging en een praktische noodstop. Een concreet voorbeeld van de scheiding tussen datatoegang, handelssessie en orderrechten staat in de API-documentatie van Interactive Brokers; wat voor uw rekening en juridische entiteit beschikbaar is, moet u afzonderlijk controleren. Geef nooit wachtwoorden of volledige API-sleutels aan onbekende signaaldiensten.
Een API kan de weg tussen uw software en de broker automatiseren. Dat garandeert geen uitvoering, prijs, liquiditeit of snelheid op de markt. Een via API verzonden limietorder blijft een limietorder die onuitgevoerd kan blijven; een marktorder blijft gevoelig voor de beschikbare prijzen op het moment van uitvoering.
Ook een technisch snelle koppeling zegt op zichzelf niets over de kwaliteit van orderuitvoering. Netwerkvertraging, brokerinfrastructuur, handelsplaats, liquiditeit en het ordertype blijven afzonderlijke factoren.
Maak API-toegang alleen een harde brokereis als uw proces zonder directe softwarekoppeling niet uitvoerbaar is. Denk aan een eigen systeem dat orders automatisch moet plaatsen, een portefeuilleproces dat programmatisch meerdere rekeningen uitleest of een toepassing die een continue datastroom nodig heeft.
Gebruikt u software alleen voor analyse en voert u orders daarna handmatig in, dan kan een handels-API overbodig zijn. Misschien heeft u alleen data nodig, of zelfs alleen exportmogelijkheden uit het platform. Dat onderscheid voorkomt dat een technische functie onnodig de hele brokerselectie bepaalt.
Leg vóór het vergelijken één concrete zin vast, bijvoorbeeld: 'Mijn software moet voor deze producten orders kunnen plaatsen en annuleren' of 'Ik heb realtime streamingdata nodig voor deze markten'. Daarmee kunt u veel nauwkeuriger controleren wat een aanbieder werkelijk ondersteunt.
Wilt u eerst de ordermechanismen zelf scherp hebben, lees dan ordertypes en handelsopties. Is API-toegang daarna een expliciete eis, dan kunt u aanbieders gericht naast elkaar leggen in de brokervergelijker. Controleer de actuele technische documentatie altijd bij de aanbieder: endpoints, rechten, limieten en ondersteunde producten veranderen.
