API (Application Programming Interface)

Wat is een API?

API staat voor Application Programming Interface. Het is de afgesproken manier waarop het ene stuk software met het andere praat: een contract dat zegt "stuur je vraag in deze vorm, dan krijg je het antwoord in dat formaat terug". De software aan de andere kant hoef je nooit vanbinnen te zien.

Denk aan een stopcontact. Je steekt de stekker erin en je toestel werkt, zonder dat je iets moet weten van het elektriciteitsnet erachter. Vaste vorm, voorspelbaar resultaat. Of denk aan een ober: je bestelt van de menukaart, de keuken blijft gesloten terrein, en je bord komt netjes aan tafel.

Elke moderne koppeling tussen systemen loopt over een API. Je boekhoudpakket dat facturen doorgeeft aan je rapportering, je webshop die voorraad checkt in je ERP, je CRM dat een mail triggert: telkens praat software met software volgens zo'n contract.

Hoe werkt een web-API in de praktijk?

De API's waar je in een datacontext mee te maken krijgt zijn bijna altijd web-API's. Ze werken via HTTP, hetzelfde protocol als je browser. Je stuurt een verzoek naar een URL en de server stuurt een antwoord terug.

Stel dat je facturen wil ophalen uit je boekhoudpakket. Je stuurt een verzoek naar een adres zoals api.voorbeeldpakket.be/v1/facturen?vanaf=2026-01-01. De server controleert wie je bent, zoekt de facturen op en stuurt ze terug als JSON: een leesbaar tekstformaat met veldnamen en waarden, het standaardformaat voor web-API's.

Elk antwoord bevat ook een statuscode. 200 betekent gelukt, 404 betekent dat het adres niet bestaat, 429 betekent dat je te veel verzoeken na elkaar stuurde.

Vrijwel elke API wil eerst weten wie je bent. De twee gangbare manieren: een API-sleutel, een lange code die jouw applicatie identificeert zoals een badge, en OAuth, waarbij je een applicatie toestemming geeft om namens jou te werken zonder je wachtwoord te delen.

REST, webhooks en GraphQL

Binnen de wereld van web-API's kom je een paar namen telkens opnieuw tegen.

REST is de dominante stijl. Elk ding krijgt een eigen adres (een klant, een factuur, een bestelling) en je gebruikt standaard HTTP-werkwoorden om ermee te werken: GET om op te halen, POST om aan te maken, PUT of PATCH om aan te passen, DELETE om te verwijderen. Als een leverancier "een API" heeft, is het in de praktijk meestal een REST-API.

Webhooks draaien de richting om. Bij een gewone API vraag jij en antwoordt het systeem. Bij een webhook stuurt het systeem zelf een bericht naar jouw adres zodra er iets gebeurt: een nieuwe bestelling, een betaalde factuur. Strikt genomen is een webhook geen API, maar de twee horen bij hetzelfde verhaal: webhooks vertellen je dat er iets veranderd is, de API laat je de details ophalen.

GraphQL is een querytaal waarbij jouw applicatie exact opgeeft welke velden ze wil terugkrijgen.

SOAP is de oudere, XML-gebaseerde stijl. Je komt hem nog tegen in oudere systemen, nieuwe API's gebruiken hem zelden nog.

Wat betekenen API's voor je datastrategie?

Elke connector in een ETL-tool of integratieplatform is in wezen een stuk software dat tegen de API van één leverancier praat. Wie zijn boekhoudpakket, CRM en webshop wil samenbrengen in een data warehouse, doet dat via de API's van die drie systemen. Geen API betekent geen automatische koppeling.

Daarom is de API-vraag een aankoopcriterium. Bij elke nieuwe softwarekeuze loont het om vooraf te checken: heeft dit pakket een gedocumenteerde API, en zit die toegang in ons abonnement? Een pakket zonder API wordt vroeg of laat een eiland: data die er alleen met exports en handwerk uit raakt.

Twee praktische realiteiten duiken op zodra je echt data begint op te halen. API's geven grote datasets terug in pagina's, bijvoorbeeld 100 records per verzoek met een verwijzing naar de volgende pagina. En de meeste API's hanteren rate limits: een maximum aantal verzoeken per minuut of per dag. Een eerste volledige lading van vijf jaar verkoophistoriek kan daardoor uren duren, terwijl de dagelijkse sync daarna in minuten klaar is.

API versus export versus rechtstreekse databasetoegang

Een API is niet de enige manier om data uit een systeem te krijgen. De twee alternatieven duiken in elke KMO op, en het verschil zit in drie dingen: stabiliteit, veiligheid en versheid.

API versus bestandsexport

De exportknop geeft je een momentopname. Het bestand is verouderd op het moment dat het gemaakt is, iemand moet eraan denken om het opnieuw te trekken, en de kolommen kunnen bij een software-update stilletjes veranderen. Exportbestanden zwerven ook rond in mailboxen en gedeelde mappen, buiten elk toegangsbeheer.

Een API haalt de actuele stand op, op elk moment en zonder handwerk. De structuur van het antwoord is gedocumenteerd, en wijzigingen worden bij een degelijke leverancier aangekondigd via versies. Toegang verloopt via een sleutel die je kan beperken en intrekken.

API versus rechtstreekse databasetoegang

Rechtstreeks in de database van een pakket kijken klinkt aantrekkelijk: alles staat erin. Maar de interne tabellen zijn geen contract. De leverancier mag ze bij elke update hertekenen zonder iemand te verwittigen, en dan valt je koppeling om. Je ziet ook alles, inclusief data waar je toegang eigenlijk beperkt zou moeten zijn, en zware queries kunnen het pakket zelf vertragen. Bij cloudsoftware krijg je die toegang sowieso zelden.

De API is de voordeur: de leverancier stelt bewust open wat stabiel en veilig gedeeld kan worden, en documenteert hoe. Dat gaat trager dan rechtstreeks in de database duiken, maar je koppeling valt niet om bij elke update.

API-documentatie leren lezen

Je vindt de documentatie van een API meestal op de website van de leverancier, onder "Developers", "API reference" of "Integraties". Goede documentatie heeft telkens dezelfde onderdelen:

• Authenticatie: hoe je een sleutel aanmaakt en meestuurt.

• Endpoints: de lijst van adressen en welke data elk adres teruggeeft of aanvaardt.

• Voorbeelden: een voorbeeldverzoek met het bijhorende antwoord, veld per veld.

• Foutcodes en limieten: wat je terugkrijgt als iets misloopt en hoeveel verzoeken je mag sturen.

Je hoeft niet te programmeren om hier iets aan te hebben. Wie kan nalezen welke velden een endpoint teruggeeft, kan zelf inschatten of de rapportering die je voor ogen hebt haalbaar is, en stelt scherpere vragen aan wie de koppeling bouwt.

Waar moet je op letten bij het gebruik van API's

Versies en breaking changes
Leveranciers brengen nieuwe versies van hun API uit (v1, v2) en zetten oude na verloop van tijd stop. Een koppeling die vandaag draait kan volgend jaar stilvallen als niemand de aankondigingen opvolgt. Abonneer je op de changelog of nieuwsbrief van je belangrijkste leveranciers.

Limieten en kosten
Rate limits bepalen hoe snel je data binnenkrijgt, en sommige leveranciers rekenen per verzoek of reserveren API-toegang voor duurdere abonnementen. Ontwerp je syncs incrementeel: haal alleen op wat veranderd is sinds de vorige keer, in plaats van elke nacht alles opnieuw binnen te trekken.

Credentials-beheer
Een API-sleutel geeft toegang tot bedrijfsdata en hoort dus in een wachtwoordkluis, niet in een script of een mail. Geef elke koppeling een eigen sleutel met zo weinig mogelijk rechten, en trek sleutels in zodra een tool of medewerker vertrekt.

FAQ over API's

1. Heeft mijn boekhoudpakket een API?
De meeste cloudpakketten wel. Zoek op de website van je leverancier naar "API", "developers" of "integraties". Oudere desktoppakketten hebben er vaak geen; dan blijft een geplande export soms de enige weg.

2. Moet ik kunnen programmeren om met API's te werken?
Nee. Integratieplatformen en kant-en-klare connectors doen het technische werk. Begrijpen wat een API kan en waar de limieten zitten volstaat om de juiste vragen te stellen.

3. Is data ophalen via een API veilig?
Veiliger dan de alternatieven, op voorwaarde dat je je sleutels goed beheert. Je geeft geen wachtwoord uit handen, je kan de toegang beperken tot alleen lezen, en je kan een sleutel intrekken zonder iets anders te breken.

4. Wat is het verschil tussen een API en een connector?
De API is wat de leverancier aanbiedt, de connector is de software die ermee praat. Een connector voor je CRM is dus gebouwd bovenop de API van dat CRM.