In het kort
Een API-koppeling laat twee softwaretoepassingen met elkaar communiceren via een afgesproken interface. De ene toepassing kan bijvoorbeeld klantgegevens opvragen of een order doorgeven; de andere geeft een antwoord terug. De koppeling bepaalt welke actie wordt gevraagd en wat er met dat antwoord gebeurt. Niet iedere API biedt dezelfde functies, en gegevens worden niet vanzelf in beide richtingen gelijkgehouden. Controleer daarom eerst wat je wilt uitwisselen en wat beide systemen daadwerkelijk ondersteunen.
Wat betekent API en wat doet de koppeling?
API staat voor application programming interface. De API-definitie van MDN beschrijft een interface waarmee software met een toepassing kan communiceren. Het gaat om functies en regels die beschikbaar worden gesteld, bijvoorbeeld om informatie te lezen of een handeling uit te voeren. Een API is dus een toegang tot bepaalde mogelijkheden van een systeem, niet automatisch toegang tot de hele database of tot alle functies die je op een scherm ziet.
De koppeling is de software die die mogelijkheden gebruikt voor jouw proces. Vergelijk het met een bestelformulier: de API bepaalt welke velden en handelingen beschikbaar zijn; de koppeling vult het juiste verzoek in en verwerkt de reactie. Een systeem kan een prima API hebben terwijl jouw gewenste actie ontbreekt. Vraag daarom niet alleen of een pakket een API heeft, maar of de benodigde gegevens en acties ermee bereikbaar zijn.
Hoe werkt een API-koppeling: verzoek en antwoord
Veel zakelijke koppelingen gebruiken een web-API via HTTP. Daarbij stuurt de koppeling een verzoek naar een bepaald adres van de toepassing, vaak een endpoint genoemd. Het verzoek benoemt een actie en kan gegevens bevatten. De toepassing antwoordt met een uitkomst, zoals gevonden informatie, een aangemaakt record of een fout. De HTTP-uitleg van MDN beschrijft dit onderscheid tussen een request en een response. Niet iedere API werkt via HTTP; hier bespreken we deze veelgebruikte vorm.
Vier begrippen helpen bij een gesprek met een leverancier. Het endpoint is het adres voor een functie. De payload is de meegestuurde inhoud. Authenticatie laat het systeem vaststellen namens wie de aanvraag wordt gedaan. De response is het antwoord dat de koppeling moet verwerken. Je hoeft die onderdelen niet zelf te programmeren om te kunnen vragen welke actie wordt uitgevoerd en welk resultaat een medewerker daarna ziet.
Een antwoord ontvangen is nog niet hetzelfde als een afgerond bedrijfsproces. Sommige toepassingen verwerken een opdracht later. Een koppeling moet daarom weten of een record alleen is ontvangen, al is aangemaakt of nog op verdere verwerking wacht. Spreek de betekenis van die uitkomsten af en laat het resultaat in het doelsysteem zien. Daarmee voorkom je dat een technisch bericht als zakelijke bevestiging wordt uitgelegd.
Een fictief voorbeeld: van order naar conceptfactuur
Stel dat een installatiebedrijf een goedgekeurde order in zijn bedrijfssoftware heeft staan. De administratie wil daarvoor een conceptfactuur in het boekhoudpakket klaarzetten. Dit is een fictief uitlegvoorbeeld. De order heeft nummer ORD-104, een klantnummer, omschrijving, afgesproken bedrag en een verwijzing naar de goedkeuring. De koppeling moet eerst vaststellen welke informatie het boekhoudpakket nodig heeft en of die gegevens beschikbaar zijn.
Vervolgens vertaalt de koppeling de velden. Een klantnummer in het ordersysteem is niet vanzelf hetzelfde als het relatienummer in de boekhouding. Ook kunnen bedragen anders worden vastgelegd, bijvoorbeeld inclusief of exclusief btw. Leg zulke betekenissen vooraf vast. In dit voorbeeld wordt alleen een concept klaargezet; een medewerker controleert en verstuurt de factuur. Een technische verbinding mag die zakelijke bevoegdheid niet stilzwijgend veranderen.
Het boekhoudpakket geeft bijvoorbeeld conceptnummer FAC-208 terug. Bewaar dan de relatie tussen ORD-104 en FAC-208. Zo kan een medewerker het juiste concept terugvinden en kan de koppeling controleren of dezelfde order al is verwerkt. Bepaal ook wat gebeurt bij een latere orderwijziging: mag het concept veranderen, moet iemand eerst controleren of is een andere vervolgactie nodig? De beschikbare API-functies en je procesafspraken bepalen samen het antwoord.
Wanneer start de uitwisseling: polling of webhook?
Een API-koppeling kan op verschillende momenten starten. Bij polling vraagt software periodiek of er nieuwe of gewijzigde gegevens zijn. Bij een webhook stuurt een systeem een melding wanneer een gekozen gebeurtenis plaatsvindt. De uitleg over webhooks verdiept wat er na zo’n melding gebeurt en hoe je dubbele of gemiste verwerking controleert. De webhook-uitleg van GitHub maakt dit verschil zichtbaar: zelf navragen tegenover een gebeurtenismelding ontvangen. Welke mogelijkheid beschikbaar is, moet je in de documentatie van jouw systemen controleren; niet elk pakket levert dezelfde gebeurtenissen of API-functies.
Een webhook kan de aanleiding zijn om daarna via een API meer gegevens op te halen. De twee vormen kunnen dus samenwerken. Kies het startmoment vanuit het werk: moet een planner een wijziging snel zien, of is een periodieke administratieve verwerking voldoende? Vraag ook hoe gemiste meldingen worden ontdekt. Een gebeurtenismelding bewijst op zichzelf niet dat het andere systeem de wijziging heeft ontvangen en toegepast.
Een bestaande connector, maatwerk of een bestand?
Een bestaande connector kan de benodigde API-uitwisseling al ondersteunen. Controleer dan nog steeds welke gegevens, acties en uitzonderingen inbegrepen zijn. Een logo van beide pakketten op een integratiepagina vertelt weinig over de exacte werking. Een automatiseringsplatform kan eveneens API-functies gebruiken en een deel van het programmeerwerk overnemen. De veldbetekenis, rechten en afspraken over fouten blijven jouw verantwoordelijkheid om af te bakenen.
Een bestandsexport kan passen wanneer gegevens af en toe worden overgezet en een medewerker de controle uitvoert. Maatwerk komt in beeld wanneer beschikbare connectors je noodzakelijke route niet afdekken. Begin daarbij met het proces, zoals uitgewerkt in de uitleg over procesautomatisering. Het doel is een bruikbare uitwisseling; een API-koppeling is een mogelijke technische vorm. Kies die vorm pas nadat je weet welke informatie wanneer nodig is.
Wat gebeurt er als een verzoek mislukt?
Een koppeling moet onderscheid maken tussen ontbrekende informatie, onvoldoende rechten en een tijdelijk onbereikbaar systeem. Die situaties vragen verschillende reacties. Een verplicht klantnummer moet bijvoorbeeld worden aangevuld; een tijdelijke storing kan aanleiding zijn voor later opnieuw proberen. Ook kan een aanbieder grenzen stellen aan het aantal aanvragen. Vraag hoe de koppeling zulke grenzen respecteert en hoe een medewerker ziet welke uitwisseling nog openstaat.
Bij opnieuw proberen kan de eerste actie al zijn uitgevoerd terwijl het antwoord verloren ging. Dan kan een tweede verzoek onbedoeld een tweede record maken. Sommige API’s bieden hiervoor idempotentiesleutels: dezelfde actie krijgt een herkenbare sleutel voor herhaalde pogingen. Stripe documenteert zo’n voorziening voor zijn eigen API. Dat is een concreet voorbeeld, geen eigenschap die je bij iedere leverancier mag aannemen. Controleer de ondersteuning en de geldende voorwaarden in de documentatie.
Laat in het ordervoorbeeld zien wat er gebeurt wanneer de verbinding wegvalt na het aanmaken van het concept. De gewenste uitkomst is dat ORD-104 naar één juist concept verwijst, of dat de situatie zichtbaar voor controle wordt klaargezet. Leg ook vast wie de fout beoordeelt en wie opnieuw verwerken mag starten. Een automatische herhaling zonder deze controle kan dezelfde fout meerdere keren uitvoeren.
Welke vragen stel je vóór je een koppeling laat maken?
Beschrijf één uitwisseling in gewone taal: wanneer een order is goedgekeurd, moeten deze gegevens in dit andere systeem beschikbaar komen voor deze medewerker. Vraag daarna welke API-functie daarvoor wordt gebruikt, welke informatie verplicht is, welk systeem per veld leidend blijft en hoe de uitkomst wordt teruggevonden. Laat de leverancier de route tonen met fictieve gegevens, inclusief een ontbrekend gegeven en een herhaald verzoek.
Begrens de toegang tot de benodigde handelingen en spreek af wie technische toegang beheert en intrekt. Neem daarnaast de prijs van eventuele API-toegang, inrichting, beheer en aanpassingen mee in de scope. Vraag wat gebeurt als een pakket zijn API wijzigt. Voor een CRM-route werkt de gids over CRM-integraties de eigenaarschap- en acceptatieafspraken verder uit. Voor het vergelijken van voorstellen kun je de controlepunten voor softwareoffertes gebruiken.
Kies een eerste route die je kunt controleren
Begin met één concrete overdracht tussen bestaande systemen. Noteer het bronrecord, de benodigde gegevens, de gewenste actie en het bewijs in het doelsysteem. Een API-koppeling heeft geen universele prijs of gegarandeerde tijdwinst: beschikbare functies, inrichting en beheer bepalen hoeveel werk nodig is. Wil je bedrijfssoftware op maat laten aansluiten op je huidige pakketten, bespreek dan deze eerste route met Softora. Neem de gebruikte systemen en een fictief voorbeeld mee, zodat de mogelijkheden en grenzen gericht onderzocht kunnen worden.
Over deze uitleg
Deze uitleg is opgesteld door Softora met hulp van AI. De technische begrippen zijn gecontroleerd aan de genoemde originele documentatie, geraadpleegd op 11 oktober 2026. Het installatiebedrijf, de order en de conceptfactuur zijn fictieve uitlegscenario’s. De keuzevragen en diagrammen zijn een eigen praktische uitwerking.
