Veel ondernemers typen dezelfde gegevens twee keer in. Een bestelling in de webshop, daarna handmatig in de boekhouding. Een reservering in de agenda, daarna nog eens in het kassasysteem. Dat kost uren per week. Erger nog: er sluipen fouten in. Een verkeerd overgetypt bedrag merk je pas bij de btw-aangifte.
De oplossing is een koppeling tussen systemen. In vaktaal heet dat een API. Het klinkt technischer dan het is.
Een verhuurbedrijf van aanhangers liep hier flink tegenaan. Ze hadden een reserveringssysteem en een aparte website. Elke boeking werd met de hand overgezet. Bij drukte ging dat mis en stond een aanhanger dubbel geboekt. Twee klanten op zaterdagochtend voor dezelfde kar, dat wil je niet.
Ik heb hun reserveringssysteem via een API aan de site gekoppeld. De beschikbaarheid komt nu live uit het systeem. Een boeking op de site landt direct in de agenda. Dubbele boekingen zijn sindsdien verdwenen. De eigenaar schat dat hij vier uur per week terugkreeg.
Wat is een API?
API staat voor Application Programming Interface. Het is een afgesproken manier om gegevens uitwisselen tussen twee systemen. De ene partij biedt functies of gegevens aan. De andere partij vraagt die op volgens vaste regels. Zo hoeven beide systemen elkaars binnenwerk niet te kennen.
Vergelijk het met een restaurant. Jij zit aan tafel met een menukaart. De keuken kun je niet in, en dat hoeft ook niet. De ober neemt je bestelling op en brengt je eten. De ober is in dit verhaal de API.
Een API geeft je verzoek door en brengt het antwoord terug.
Hoe werkt een API in de praktijk?
Een API-gesprek bestaat altijd uit twee delen. Eerst gaat er een verzoek heen. Daarna komt er een antwoord terug.
Het verzoek
Je stuurt een verzoek naar een endpoint. Dat is simpelweg een webadres met een functie. Je geeft daarbij aan wat je wilt. Ophalen, toevoegen, wijzigen of verwijderen. Vaak stuur je een sleutel mee ter identificatie.
Het antwoord
De server stuurt een antwoord terug met een statuscode. Code 200 betekent gelukt. Code 404 betekent niet gevonden. De gegevens zelf komen meestal in JSON binnen. Dat formaat is compact en makkelijk te verwerken.
Soorten API’s die je tegenkomt
REST
De REST API is veruit de meest gebruikte vorm. Het werkt met gewone webadressen en HTTP-methodes. Simpel, leesbaar en breed ondersteund. De meeste koppelingen die ik bouw zijn REST.
GraphQL
Bij GraphQL vraag je precies op wat je nodig hebt. Je krijgt dus geen overbodige velden mee. Dat scheelt data en laadtijd. De opzet is wel wat complexer.
SOAP
SOAP is de oudere garde, gebaseerd op XML. Je ziet het nog bij banken en overheden. Het is streng en uitgebreid gedocumenteerd. Voor kleine projecten is het meestal te zwaar.
Webhooks
Een webhook werkt precies andersom. Jij vraagt niets, maar krijgt bericht bij een gebeurtenis. Denk aan een melding zodra een betaling binnenkomt.
API’s binnen WordPress
WordPress heeft een eigen REST API ingebouwd. Daarmee kun je berichten en pagina’s opvragen. Een externe app kan zo je content tonen. Dat is de basis van headless WordPress.
Ook WooCommerce heeft een uitgebreide API. Daarmee kun je bijvoorbeeld voorraadbeheer koppelen aan een webwinkel. Zo’n koppeling loopt via een plugin of via maatwerkcode. Welke keuze past, hangt af van de complexiteit.
Beveiliging: waar ik altijd op let
Een API is een deur naar je gegevens. API beveiligen is dus geen bijzaak.
Sleutels in een omgevingsvariabele, niet in je code.
Beperk rechten tot precies wat nodig is.
Stel een limiet in op het aantal verzoeken.
Ik test een koppeling altijd eerst in een staging omgeving. Live experimenteren met betaalgegevens doe je niet. Een koppeling neem ik daarna mee in het periodieke onderhoud. API’s veranderen namelijk, meestal zonder dat jij het merkt.
Wanneer heb je een API nodig?
Niet elk bedrijf heeft een koppeling nodig. Ik kijk naar drie signalen.
Je typt dezelfde gegevens in twee systemen over.
Je klanten wachten op informatie die ergens anders al staat.
Fouten ontstaan door handmatig kopieren en plakken.
Herken je twee van de drie? Dan verdient systemen koppelen zich vaak snel terug.
Samengevat
Een API is de ober tussen twee systemen. Hij neemt je verzoek aan en brengt het antwoord terug. Goed opgezet bespaart dat uren handwerk per week. Slecht beveiligd is het een risico. Neem de tijd om het netjes te doen.
Meer vragen over API
Dit zijn de vragen die ik hierover het vaakst krijg. Ik werk ze los uit.
Wat is een API in gewone taal?
Wat kost een API-koppeling gemiddeld?
Hoe koppel je je website aan je boekhoudpakket?
Is een API-koppeling veilig genoeg voor klantgegevens?
Wanneer heeft een bedrijf een API-koppeling nodig?
Wat gebeurt er als een API-koppeling stukgaat?
Wat kost een API-koppeling?
Dat kan zeker, en het is de meest gemaakte fout. Het gaat mis als je bij elk bezoek live data ophaalt. Je pagina wacht dan op een server die jij niet beheert. Is die traag, dan is jouw site traag.
Ik los dat vrijwel altijd op met een tussenlaag. De gegevens worden periodiek opgehaald en lokaal bewaard. Je bezoeker krijgt de opgeslagen versie te zien. Dat gaat razendsnel.
Hoe vaak je ververst, hangt af van je situatie. Voorraadstanden ververs ik elk kwartier. Openingstijden één keer per dag. Reserveringsbeschikbaarheid soms wel live, maar dan met een korte time-out.
Stel altijd een maximale wachttijd in. Reageert de andere partij niet binnen drie seconden? Dan toont je site de laatst bekende gegevens. Meer hierover lees je bij cache.
Meet het effect ook echt. Zet je laadtijd voor en na de koppeling naast elkaar. Zie je meer dan een halve seconde verschil, dan is er werk.
Vertraagt een API-koppeling mijn website?
Dat hangt vooral af van de documentatie aan de andere kant. Dat klinkt saai, maar het is echt de bepalende factor. Een moderne REST-koppeling met heldere documentatie kost me vaak een dag. Denk aan een boekhoudpakket of een reserveringssysteem van deze tijd.
Wordt het een oud systeem zonder documentatie? Dan loopt het snel op. Ik moet dan uitzoeken hoe het werkt, met vallen en opstaan. Reken op meerdere dagen en een onzekere uitkomst.
Er zijn nog twee kostenposten die mensen vergeten. De eerste is testen. Een koppeling die 95 procent van de tijd werkt, is niet af. De tweede is beheer. API’s veranderen, dus je koppeling vraagt aandacht.
Ik maak daarom altijd eerst een korte verkenning. Een halve dag onderzoek voorkomt een dure verrassing. Kijk ook even naar endpoint om de techniek te begrijpen.
Vraag altijd vooraf om de documentatie. Kan de leverancier die niet leveren? Reken dan op minstens het dubbele aantal uren.
Wat gebeurt er als de leverancier zijn API wijzigt?
Dat gebeurt, en vaker dan je zou willen. Meestal kondigt een leverancier het netjes aan. Er komt dan een nieuw versienummer, bijvoorbeeld van v2 naar v3. De oude versie blijft dan nog een tijd werken.
Soms gaat het minder netjes. Een veld verandert van naam of verdwijnt zonder bericht. Je koppeling stopt dan stilletjes met werken. Het vervelende is dat je site gewoon blijft draaien. Alleen de gegevens kloppen niet meer.
Daarom bouw ik altijd een controle in. Klopt het antwoord niet met wat ik verwacht? Dan krijg ik een melding per mail. Zo weet ik het voordat jouw klant het merkt.
Neem koppelingen ook mee in je periodieke onderhoud. Vier keer per jaar controleren scheelt een hoop gedoe. Een kapotte voorraadkoppeling kost je binnen een week echte omzet.
Leg vast welke versie je gebruikt. Zet dat in je documentatie, niet alleen in je hoofd. Bij een storing scheelt dat zo een paar uur zoekwerk.
Is een API-koppeling veilig?
Een API is een deur naar je gegevens. Die deur kan prima op slot, mits je het goed doet. Ik houd me aan een vast lijstje.
Alle verkeer loopt versleuteld via HTTPS. Sleutels sla ik nooit op in de code zelf, maar in een omgevingsvariabele. Zo staan ze niet in je back-ups en niet in versiebeheer.
Rechten beperk ik tot het minimum. Heeft de koppeling alleen voorraadgegevens nodig? Dan geef ik geen toegang tot klantgegevens. Veel leveranciers bieden daar aparte sleutels voor.
Verder stel ik een limiet in op het aantal verzoeken. Dat beschermt tegen misbruik en tegen een fout in je eigen code. En ik test elke koppeling eerst in een staging omgeving.
Gaat het om betaalgegevens of persoonsgegevens? Dan hoort er ook een verwerkersovereenkomst bij. Dat is geen techniek, maar wel verplicht.
Log tot slot elk verzoek dat misgaat. Zo zie je patronen voordat er echt iets fout gaat. Bewaar die logs niet langer dan nodig is.
Heeft mijn bedrijf een API-koppeling nodig?
Lang niet elk bedrijf heeft er een nodig. Ik kijk naar drie signalen en die zijn behoorlijk nuchter.
Signaal één: je typt dezelfde gegevens in twee systemen over. Bestellingen, adressen, uren, het maakt niet uit. Handwerk dat elke week terugkomt is een koppeling waard.
Signaal twee: je klanten wachten op informatie die al ergens staat. Denk aan beschikbaarheid, levertijd of de status van een order. Zij bellen jou, terwijl het systeem het antwoord al weet.
Signaal drie: er ontstaan fouten door overtypen. Een verkeerd bedrag of een dubbele boeking. Die fouten kosten vaak meer dan de koppeling zelf.
Herken je twee van de drie? Dan is het het onderzoeken waard. Herken je er geen? Dan zou ik het laten. Een koppeling die niets bespaart, is alleen maar extra onderhoud. Kijk anders eerst naar een webhook, dat is vaak eenvoudiger.
Reken het ook even door. Bespaart de koppeling twee uur per week? Dan verdient hij zich binnen een jaar ruimschoots terug.
Loop jij tegen dubbel werk aan tussen twee systemen? Beschrijf het kort via het formulier hieronder. Ik kijk of een koppeling mogelijk is en wat die ongeveer kost. Blijkt het niet rendabel, dan zeg ik dat gewoon. Vermeld je plaats, dan weet ik of we het ook op locatie kunnen bespreken.
Waar kan ik je mee helpen?
Ook bekend als: Application Programming Interface, koppeling, integratie
