API, oftewel Application Programming Interface. Het klinkt technisch maar het idee erachter is eenvoudig: het is een manier waarop verschillende (software) systemen met elkaar ‘afspreken’ om informatie uit te wisselen. Door deze afspraken kunnen verschillende applicaties met elkaar communiceren.
Denk aan je webshop die de voorraad van een product ophaalt, of de weer app van Apple die wereldwijd de weersomstandigheden kan ophalen. In al die gevallen praten systemen met elkaar via een duidelijke “taal”: de API.
TLDR/In’t kort
- API = Application Programming Interface:
- Application betekent in deze context om het even welke software met een specifieke functie of doel
- Interface verwijst naar een ‘afspraak’ (gestandaardiseerde manier) die bepaalt hoe twee applicaties met elkaar praten via verzoeken (requests) en antwoorden (responses)
- Je gebruikt API’s om systemen veilig en gestructureerd te koppelen (bv. Webshop x Voorraadservice).
- Een API Call kent twee stappen: Request (verzoek) en Response (antwoord)
- Web-API’s werken meestal via HTTP en antwoorden vaak in JSON (gestructureerde data)
- Waarvoor worden API’s gebruikt? Door systemen met elkaar te laten communiceren, door middel van een API, moet er minder handmatig werkt gebeuren, worden er minder fouten gemaakt, en verlopen je werkprocessen sneller
API betekenis en definitie
Een API (Application Programming Interface) is een set duidelijke regels die beschrijven hoe een programma gegevens kan opvragen of acties kan uitvoeren bij een ander programma. Je hoeft de interne werking van de verschillende programma’s niet te kennen.
De API maakt het mogelijk dat beide systemen met elkaar ‘communiceren’ en haalt zo de nodige data op. Je stuurt een verzoek naar een afgesproken “adres” (endpoint) en krijgt een antwoord.
API: waar staat dat voor?
- Application: Eender welke software met een bepaald doel (bv. weer app, facturatie en boekhoud software, …)
- Programming: ontwikkelaars gebruiken het om software te laten communiceren
- Interface: de afspraken/regels (protocol) die bepalen hoe verzoeken & antwoorden eruitzien.

Waarom gebruiken we een API?
We leggen het uit aan de hand van enkele analogieën.
Analogie 1:
Stel, je wil een reservatie bij je favoriete restaurant last minute aanpassen van 2 naar 4 personen. Je belt het restaurant op en je krijgt een medewerker aan de lijn. Zij zet je even in wacht om alles te checken en enkele tijd later krijg je het antwoord “Ja, dat kan”.
Zo werkt een API eigenlijk ook: Jij doet een verzoek (request) en krijgt een antwoord (response)
Stel je nu voor dat het restaurant niet bereikbaar is en dat ze geen medewerkers tewerkgesteld hebben. Dan zou je al deze zaken zelf moeten uitzoeken:
- Het totale aantal tafels beschikbaar in het restaurant
- Hoeveel mensen er op hetzelfde tijdstip als jou gereserveerd hebben
- Hoeveel obers er die avond werken
- Het aantal koks en de beschikbare ingrediënten
Al deze zaken zou je in overweging moeten nemen om te beslissen of je de 2 extra personen aan je reservering kan toevoegen. Dat is onbegonnen werk en al deze gegevens zijn hoogstwaarschijnlijk zelfs niet publiekelijk beschikbaar.
Ter verduidelijking, in deze analogie:
- Is het restaurant een applicatie die een specifieke dienst levert (jouw eten geven)
- Ben jij een applicatie en wil je met een groep vrienden bediend worden.
- De medewerker die jij aan de lijn krijgt is de API van het restaurant. Het is de interface waarlangs je communiceert en verzoeken doet. Je hoeft de interne keuken (in dit geval kan je dat vrij letterlijk nemen) niet te kennen.
Analogie 2:
De weer-app op je telefoon heeft zelf geen weerstation. Ze haalt de data op bij een weer-dienst via hun API. Die API zegt exact hoe je de huidige temperatuur of een 7-daagse voorspelling opvraagt (bv. via een URL met parameters), en welk formaat je terugkrijgt (bv. JSON). Je app hoeft dus enkel “netjes te vragen”; de rest gebeurt achter de schermen.
Schematische voorstelling van hoe een API werkt
In afbeelding 1 schetsen we een situatie op de werkvloer door te werken zonder API’s. Een medewerker wil de facturaties van de afgelopen 2 weken bijwerken en opent daarvoor Excel. Hij kopieert alle nodige gegevens en plakt ze op de voorbestemde plaatsen in de facturatie applicatie. Dit is een tijdsintensieve opdracht en door het manuele werk gebeuren er af en toe fouten.

In afbeelding 2 schetsen we een situatie met API. De applicaties communiceren nu met elkaar. “Als jij bij mij gegevens X,Y,Z opvraagt, antwoord ik met werkuren, materiaalkost en totale prijs”. Door de tussenkomst van de API hoeft de medewerker niet alles zelf manueel te doen. Dit bespaart tijd, versnelt de processen en reduceert de gemaakte fouten.

Hoe werkt een API? Met voorbeeld
De meeste moderne koppelingen verlopen via web-API’s. Dat zijn API’s die verzoeken ontvangen en antwoorden teruggeven via het internet, meestal in JSON. Het patroon is telkens hetzelfde: request → response.
De bouwstenen van een web-API-verzoek (hoe API gebruiken / API invullen):
- Endpoint (URL-adres): het exacte “eindpunt” waar je je vraag naartoe stuurt, bv. /products/123/stock.
- Methode (HTTP-methode): GET (informatie ophalen), POST (aanmaken), PUT/PATCH (bijwerken), DELETE (verwijderen).
- Headers: extra info, zoals Authorization (laat zien wie je bent en dat je toegang hebt): <API-key>of Accept (in welk formaat wil je antwoord?): application/json.
- Body (payload): de inhoud die je meestuurt (bv. nieuwe gegevens bij een POST).
Het antwoord (response) bevat:
- Statuscode: bv. 200 OK (gelukt), 404 Not Found (niet gevonden), 401 Unauthorized (geen toegang), 500 (serverfout).
- Headers + Body: meestal JSON met de data waar je om vroeg
Voorbeeld: een webshop controleert de voorraad (web-API)
Stel, je webshop wil tonen of een product nog op voorraad is. De webshop (client) vraagt dat op bij een voorraadservice (server) via een GET-verzoek naar een endpoint.
Request

Response – succesvol (200 OK)

Response – product niet gevonden (404 not found)

Moet de medewerker voor elke voorraad controle de API opnieuw activeren?
Nee. Zodra de koppeling actief is, controleert de webshop zelf de voorraad op de momenten dat het nodig is (bijv. wanneer iemand een productpagina opent of op “in winkelmand” klikt).
Het resultaat wordt even onthouden, zodat je niet voor elke bezoeker opnieuw dezelfde vraag stelt aan het voorraadsysteem.
Vaak draait er ook automatisch op de achtergrond een update die meerdere producten tegelijk bijwerkt. In sommige opzetten krijgt de webshop zelfs een seintje van het voorraadsysteem zodra de voorraad wijzigt. Zo blijft alles actueel zonder dat iemand er handmatig moet achter zitten.
Een slimme inzet van API’s is noodzakelijk in je digitale transformatie. Het bespaart je tijd en vermindert gemaakte fouten.
Woordenlijst met meest gebruikte termen voor API’s
- API (Application Programming Interface)
Een set afspraken (regels) waardoor twee softwaresystemen netjes met elkaar kunnen praten. Denk aan je webshop die via een API de voorraad ophaalt bij een voorraadsysteem.
- Endpoint
Het exacte “adres” (URL) waar je een verzoek naartoe stuurt.
Voorbeeld: https://api.winkel.be/v1/products/123/stock.
- Request
Het verzoek dat je naar een API stuurt: bevat o.a. de URL, methode, optionele headers en soms een body.
Voorbeeld: “Geef mij de voorraad van product 123”.
- Response
Het antwoord van de API op je request. Bevat een statuscode, eventuele headers en meestal data (bv. in JSON). Voorbeeld: { “product_id”: 123, “stock”: 7 }.
- HTTP Method (GET/POST/PUT/PATCH/DELETE)
Zegt wat je wil doen: Informatie ophalen (GET), aanmaken (POST), bijwerken (PUT/PATCH), verwijderen (DELETE).
Voorbeeld: GET voor voorraad opvragen, POST voor bestelling aanmaken.
- Status Code
Kort cijfer dat aangeeft wat er gebeurde. Veelvoorkomend:
200 OK (gelukt), 201 Created, 404 Not Found, 401 Unauthorized, 500 Server Error.
- Headers & Body
Headers = extra info bovenaan (bv. wie je bent, in welk formaat je praat). Body = inhoud die je meestuurt (bv. nieuwe ordergegevens bij POST).
Voorbeeld-headers: Authorization: Bearer , Content-Type: application/json.
- Authentication (API Key / Token / OAuth)
Manier om te bewijzen wie je bent en wat je mag. Vaak via een API key of Bearer token; grotere platforms gebruiken soms OAuth 2.0.
Voorbeeld: Authorization: Bearer abc123….
- JSON (JavaScript Object Notation)
Veelgebruikt, leesbaar dataformaat voor verzoeken/antwoorden.
Voorbeeld: { “product_id”: 123, “stock”: 7 }.
- Webhook
“Seintje” dat de server zelf naar jouw adres stuurt zodra er iets gebeurt (push), i.p.v. dat jij steeds moet vragen (pull).
Voorbeeld: bij voorraadwijziging stuurt het voorraadsysteem direct een bericht naar jouw webshop om de stand bij te werken.
Nog niet helemaal mee met wat een API is en hoe het werkt? Dan raden we je aan om heldere video van Exponent te kijken en jezelf te verdiepen in al hun content over Application Programming Interfaces.
Veelgestelde vragen
1) Is een API hetzelfde als een plugin?
Nee. Een plugin voegt extra functies toe binnen hetzelfde systeem (bv. je CMS). Een API laat twee verschillende systemen met elkaar praten. Je gebruikt een API dus voor koppelingen tussen toepassingen.
2) Heb ik programmeerkennis nodig om API’s te gebruiken?
Niet altijd. Sommige software biedt gebruiksvriendelijke (no-code) integraties. Voor maatwerk of specifieke flows is een developer of IT-partner wel handig, maar je hoeft de techniek erachter niet tot in detail te kennen.
3) Wat is een API-key
Een API-key is een unieke sleutel—zoals een wachtwoord—die je meestuurt om te bewijzen dat jij toegang mag vragen. Vaak vind je zo’n key in het accountgedeelte van je software.
4) Zijn API’s gratis?
Vaak zit API-toegang inbegrepen bij je licentie. De ontwikkeling van de koppeling (analyse, bouwen, testen) kost tijd/geld. Sommige leveranciers beperken het aantal “API-calls” of bieden premium-formules.
5) Wat is het verschil tussen webhook en API?
Een API wordt meestal bevraagd door de client (pull). Een webhook is push: de server stuurt zelf een bericht wanneer er iets gebeurt (bv. “bestelling betaald”). Beide concepten vullen elkaar vaak mooi aan