API-integratie: wat is het & hoe werkt het?

Wat is een API?

API staat voor Application Programming Interface. Het is de manier waarop softwaresystemen onderling met elkaar praten — een vaste set afspraken waarmee programma's data kunnen opvragen of versturen, zonder dat er een mens tussen zit.

De makkelijkste analogie is een restaurant. U gaat zitten, krijgt een menukaart en geeft uw bestelling aan de ober. De ober loopt naar de keuken, geeft het door, en komt later terug met het gerecht. U weet niet hoe de keuken werkt en hoeft dat ook niet te weten — u kent alleen het menu en de regels van het bestellen. De ober is in dit verhaal de API: een gestandaardiseerd loket tussen u en de keuken.

Een API heeft geen visuele schil, geen knoppen en geen vormgeving. Het is puur data die over en weer gaat via verzoeken (requests) en antwoorden (responses). In de overgrote meerderheid van moderne software gebeurt dat via het HTTP-protocol — hetzelfde protocol dat uw browser gebruikt om een webpagina op te halen. Daaronder bestaan verschillende stijlen: REST, GraphQL, SOAP en gRPC zijn de bekendste.

Wat is een API-integratie?

Een API-integratie is de koppeling tussen twee of meer systemen via hun API's. Het is het concrete stuk software dat de ene API met de andere praat — automatisch, op vaste momenten of zodra er iets gebeurt.

Het verschil met handmatig werk is groot. Zonder integratie exporteert iemand bestellingen uit de webshop naar Excel, opent vervolgens het boekhoudpakket en typt de gegevens over. Met een integratie verschijnt elke nieuwe bestelling direct in de boekhouding, zonder dat iemand een vinger uitsteekt. Dezelfde data, andere route — en die andere route schaalt mee als uw bedrijf groeit.

Een goede API-integratie is meer dan alleen "data van A naar B". Het regelt ook de uitzonderingen: wat doe je als systeem B even niet bereikbaar is? Wat als dezelfde bestelling per ongeluk twee keer langskomt? Wat als de structuur van een veld verandert? Die randvoorwaarden bepalen of een integratie in productie blijft werken of stilletjes data verliest. Wij behandelen die randvoorwaarden uitgebreid op onze pagina over slimme API-integraties.

Soorten API's: REST, GraphQL, SOAP en meer

Niet elke API werkt hetzelfde. De onderliggende stijl bepaalt hoe een ontwikkelaar met de API werkt — en in welke gevallen die stijl logisch is.

REST API

De facto standaard van het moderne web. REST werkt over HTTP, gebruikt JSON voor data en is goed leesbaar voor mensen. Vrijwel elke SaaS-tool die u kent — HubSpot, Stripe, Shopify, Slack — biedt een REST API aan. Vraagt u iets op via een URL, dan krijgt u een gestructureerd antwoord terug. Eenvoudig in opzet, dekkend voor de meeste use-cases.

GraphQL

Een nieuwer alternatief, oorspronkelijk van Facebook. Bij GraphQL beschrijft de vraag exact welke velden u terug wilt — niet meer, niet minder. Handig bij complexe data-modellen waar u anders veel losse REST-calls nodig zou hebben. Shopify, GitHub en veel headless-CMS-platforms bieden GraphQL aan.

SOAP

De voorganger van REST. SOAP gebruikt XML, is veel strakker gedefinieerd en wordt in moderne contexten weinig nieuw gebouwd. U komt het tegen in enterprise-omgevingen: oude bankensystemen, overheidsdiensten en grote ERP-pakketten. Een SOAP-koppeling is bewerkelijker, maar voor wie met een legacy-systeem moet praten vaak de enige optie.

gRPC

Een binair protocol van Google, ontworpen voor performance-kritische scenario's tussen interne services. U treft het zelden aan in B2B-integraties — vaker binnen het architectuur-skelet van een SaaS-product zelf.

WebSocket

Geen request-response, maar een permanent open verbinding waarover beide kanten op elk moment data kunnen sturen. Onmisbaar voor chat-applicaties, dashboards die live moeten meebewegen of trading-platformen.

Webhooks

Strikt genomen geen API-stijl maar een mechanisme: in plaats van dat u steeds vraagt "is er iets nieuws?", stuurt het bron-systeem een seintje zodra er iets gebeurt. Een bestelling, een betaling, een statuswijziging — direct gepusht naar uw eigen endpoint. Webhooks zijn de standaard voor event-driven integraties.

De keuze tussen deze stijlen is zelden een principiële: u gebruikt wat de vendor aanbiedt. Wel is goed om vooraf te checken wat een SaaS-leverancier ondersteunt voordat u een koppeling belooft. Een ouder pakket dat alleen SOAP biedt, vraagt een ander soort werk dan een moderne tool met REST en webhooks.

Hoe werkt een API-integratie technisch?

Onder de motorkap doorloopt elke API-call dezelfde stappen. Voor besluitvormers is het nuttig om die op hoofdlijnen te kennen — niet om ze zelf te bouwen, maar om de juiste vragen te stellen aan een leverancier.

Authenticatie

Een API moet weten wie er aanklopt. De drie meest gebruikte methodes zijn API-keys (een lange geheime sleutel die in elk verzoek meegaat), OAuth 2.0 (een token-flow waarbij een gebruiker expliciet toestemming geeft) en JWT (een ondertekend token met daarin de identiteit). OAuth is de standaard voor gebruikersgerichte koppelingen; API-keys passen bij server-naar-server.

Request

Het verzoek bestaat uit een HTTP-methode (GET om iets op te halen, POST om iets aan te maken, PUT of PATCH om iets te wijzigen, DELETE om iets te verwijderen), een URL die de resource aanduidt, en een optionele body met data.

Response

Het antwoord bevat een status-code (200 = goed, 4xx = uw fout, 5xx = hun fout) en een payload met de gevraagde of bevestigde data — meestal JSON.

Rate-limits

Vrijwel elke API beperkt het aantal verzoeken per seconde, minuut of dag. Overschrijdt u die limiet, dan krijgt u tijdelijk geen antwoord meer of zelfs een blokkade. Een goede integratie houdt rekening met die plafonds en bouwt vertraging in waar nodig.

Error-handling en retries

Netwerken haperen. Servers gaan kort offline. Een productie-waardige integratie probeert mislukte verzoeken opnieuw, met oplopende tussenpauzes (exponential backoff), en bewaart wat er mislukte zodat het later alsnog kan.

Pagination

Bij grote datasets levert een API niet alles in één keer. U vraagt steeds een "pagina" op (bijvoorbeeld 100 records per keer) totdat u het einde bereikt. Vergeten te pagineren is een klassieke reden waarom een integratie in test prima werkt maar bij echte volumes data mist.

Idempotentie

Een goed ontworpen API laat u hetzelfde verzoek meerdere keren versturen zonder dat het dubbel verwerkt wordt — bijvoorbeeld door een unieke sleutel mee te geven per bestelling. Bij betalingen en orders is dat onmisbaar. Zonder idempotentie betaalt een klant in het slechtste geval twee keer of komt dezelfde factuur dubbel in de boekhouding terecht.

Versionering

SaaS-leveranciers werken hun API regelmatig bij. Meestal blijven oude versies tijdelijk werken, maar verlopen ze op een gegeven moment. Een productie-koppeling let actief op aankondigingen van de vendor en plant het upgrade-pad in — anders staat u een keer met stilgevallen synchronisatie.

Voorbeelden uit de praktijk

Een paar koppelingen die we in de praktijk vaak tegenkomen — herkenbaar voor mkb en scale-up:

• CRM → boekhouding: een nieuwe klant in HubSpot of Pipedrive verschijnt automatisch als contact in Exact, Twinfield of Moneybird. Geen dubbele invoer, geen verkeerde adresvelden.
• Webshop → ERP: een Shopify- of WooCommerce-bestelling stroomt direct in het ERP- of voorraadsysteem (SAP, Magento, Picqer). Voorraad, order-status en facturatie blijven synchroon.
• ATS → payroll: wordt een kandidaat aangenomen in Bullhorn of Recruitee, dan komt het personeelsdossier direct in NMBRS of AFAS te staan.
• WhatsApp → CRM: binnenkomende klantberichten verschijnen als ticket in Zendesk, HubSpot of Freshdesk — inclusief volledige conversatie-historie.
• Calendly → CRM: een geplande afspraak werkt automatisch een lead-stage bij en verstuurt de juiste follow-up.
• Payment-provider → boekhouding: Mollie-, Stripe- of Adyen-betalingen koppelen aan factuur-statussen — een ontvangen betaling sluit direct de openstaande post.

De grootste sprong zit zelden in één enkele koppeling, maar in het samenspel. Drie tot zes systemen die elkaar voeden, in plaats van losse silo's. Wie meer wil zien van hoe wij dat in zetten, kan terecht op onze pagina over integraties als dienst.

Een nuance die in deze lijstjes vaak verdwijnt: niet elke koppeling hoeft realtime te zijn. Voor een boekhoudkoppeling is een nachtelijke batch vaak prima — en goedkoper te bouwen. Voor een betalingsbevestiging in een webshop moet het binnen seconden. Maak die afweging per stroom, niet als blanket-policy voor de hele organisatie.

iPaaS versus maatwerk API-integratie

Een API-integratie hoeft niet altijd maatwerk te zijn. Er bestaan zogeheten iPaaS-platformen (Integration Platform as a Service) die een groot deel van het werk standaardiseren.

iPaaS: Zapier, Make, Workato, n8n

Met een iPaaS klikt u in een visuele editor een koppeling in elkaar: trigger uit systeem A, actie naar systeem B. Voor eenvoudige scenario's is dat snel, goedkoop en zonder code te bouwen. Het is uitstekend voor automatisering van standaardstromen tussen veelgebruikte SaaS-tools.

Maatwerk-integratie: eigen middleware

Zodra de logica complexer wordt — veel mapping per veld, business-regels, fraude-checks, performance-eisen of een eigen ERP — loopt iPaaS tegen grenzen aan. Dan bouwt u (of laat u bouwen) een eigen middleware-laag: een klein stukje software dat de vertaling tussen de systemen verzorgt, monitoring biedt en queueing op zich neemt.

Het is geen of/of-keuze: veel organisaties combineren. Een Zapier-flow voor het eenvoudige werk, maatwerk-middleware voor de bedrijfskritische processen. Het uitgebreide verschil tussen beide benaderingen behandelen we in onze gids over API's versus integratieplatformen.

Voor welke bedrijven is een API-integratie interessant?

De kantelpunten in onze ervaring:

• Mkb met drie of meer losse SaaS-tools: zodra mensen dagelijks data tussen pakketten overtypen, is een koppeling vrijwel altijd terugverdiend.
• Scale-ups in groei: wat met honderd transacties handmatig kan, breekt bij duizend per dag. Integraties zijn een groei-enabler.
• Enterprise met een multi-vendor stack: grote organisaties draaien zelden op één pakket. Integraties houden ERP, CRM, HR, finance en BI in lijn.
• Branche-organisaties en marktplaatsen: wanneer u data uitwisselt met partners, leveranciers of leden, is een API-integratie de schaalbare oplossing voor wat ooit in e-mails en spreadsheets gebeurde.

Wij werken zowel met mkb-bedrijven die hun eerste koppeling overwegen als met enterprises die hun bestaande integratie-landschap willen consolideren. Een achtergrondpagina daarover is onze systeemintegratie-specialist-pagina.

Wat kost een API-integratie?

Er is geen vast prijskaartje, en iedereen die er één noemt zonder eerst de scope te kennen verkoopt u een fabel. Wat we wel kunnen zeggen is hoe de bandbreedte zich opbouwt:

• iPaaS-koppeling: een eenvoudige flow tussen twee bekende SaaS-tools zit aan de laagste kant van het budget. Geen middleware nodig, weinig business-logic, vooral configuratiewerk.
• Maatwerk-koppeling: de kosten schalen met het aantal systemen, de complexiteit van de mapping, hoeveel uitzonderingen er afgehandeld moeten worden en de branche-eisen (financieel, zorg, overheid stellen extra eisen).
• Onderhoud: elke koppeling vraagt onderhoud. API-versies veranderen, leveranciers passen velden aan, en uw eigen processen evolueren. Reken op een doorlopende onderhoudslast — als percentage van de bouwkosten, niet als getal in steen.

De grootste valkuil in de begroting is het vergeten van monitoring en error-handling. Een koppeling "werkend opleveren" is goedkoop; een koppeling die ook over een jaar nog stabiel data verwerkt, vraagt iets meer.

Twee verborgen kostenposten waar mensen niet aan denken: documentatie en kennisborging. Als de bouwer vertrekt en niemand weet meer hoe de mapping in elkaar zit, betaalt u de integratie ergens in de toekomst opnieuw. Vraag bij elke koppeling om een korte technische readme — welke endpoints, welke velden, welke uitzonderingen. Dat document is waardevoller dan een extra feature.

AVG en compliance bij API-integraties

Zodra er persoonsgegevens via een API gaan — namen, e-mailadressen, telefoonnummers, klantnummers, betaalgegevens — geldt de AVG onverkort. Een aantal zaken die u in elke serieuze integratie wilt zien terugkomen:

• DPA met elke partij: een verwerkersovereenkomst met de vendor of het iPaaS-platform dat de data passeert.
• Encryptie in transit: alle verkeer over TLS (HTTPS). Geen plain-HTTP, geen onversleutelde queues.
• Audit-log: wie heeft wat opgevraagd, gewijzigd of doorgestuurd. Bij incidenten of inzage-verzoeken essentieel.
• Data-minimalisatie: stuur alleen door wat u nodig heeft. Niet "voor de zekerheid het hele klantprofiel".
• Bewaartermijnen: als de middleware tijdelijk data buffert, hoort daar een termijn op te zitten.

Voor branches met aanvullende kaders (zorg, finance, overheid) komen daar specifieke eisen bovenop. Een serieuze integratie-partner brengt die proactief ter sprake.

Veelgemaakte fouten bij API-integraties

Vrijwel alle problemen die we tegenkomen vallen onder dezelfde handvol categorieën:

• Geen rate-limit-respect: de integratie ramt verzoeken erin tot de vendor de toegang dichtgooit. Iedereen staat dan stil.
• Geen error-handling: bij een fout wordt er niets gelogd en niets opnieuw geprobeerd. Data verdwijnt in het luchtledige.
• Hardcoded credentials: API-keys in de broncode of in een Git-repository. Eén lek en u draait een security-incident.
• Geen logging of monitoring: u ontdekt een storing pas als een klant belt. Dat is te laat.
• Geen idempotency-keys: bij een hapering raakt dezelfde bestelling dubbel verwerkt — en dat ontdekt u in de boekhouding.
• Te strakke koppeling: een wijziging in het ene systeem breekt direct vijf andere processen. Een goede integratie isoleert dat.

Geen van deze valkuilen is exotisch, en stuk voor stuk vermijdbaar. Het verschil zit in de discipline van wie de koppeling bouwt en in een serieuze test- en monitoring-aanpak.

Een aanvullend punt dat onderschat wordt: testen op productie-achtige data. Een integratie die met drie testklanten werkt, kan op echte volumes alsnog stuklopen op edge-cases — speciale tekens in namen, leeg gelaten velden, klanten die ooit met een afwijkende structuur zijn aangemaakt. Plan een fase in waarin de koppeling parallel meedraait naast het huidige proces voordat u definitief overschakelt.

Zelf doen of uitbesteden?

Niet elke integratie hoeft uitbesteed te worden. Een paar vuistregels:

Zelf doen

U heeft een eenvoudige flow tussen twee SaaS-tools, een in-house developer of een tech-savvy operations-collega, en er staan geen kritieke processen of grote volumes op het spel. Een Zapier- of Make-flow is dan vaak afdoende.

Uitbesteden

Het wordt complexer zodra er meerdere systemen samenkomen, eigen middleware nodig is, AVG-eisen streng zijn, of de koppeling onderdeel wordt van uw kernproces. Dan loont het om een partner in te zetten die het volledige plaatje overziet — van architectuur tot monitoring tot onderhoud.

Tussen die twee uitersten bestaat veel ruimte. Een veelgekozen route is: een externe partij bouwt en documenteert, een interne collega beheert daarna. Welke verdeling bij uw organisatie past hangt vooral af van wat u zelf in huis wilt houden. Meer artikelen over dit soort keuzes vindt u in onze kennisbank.

Veelgestelde vragen

Wat is een API in één zin?

Een API is een afsprakenset waarmee twee softwaresystemen elkaar gestructureerd data kunnen laten opvragen of versturen, zonder dat er een mens tussen zit.

Wat is het verschil tussen een API en een API-integratie?

De API is het loket — de set afspraken die een systeem aanbiedt. Een API-integratie is het concrete stuk software dat het loket van systeem A koppelt aan dat van systeem B, zodat data automatisch heen en weer stroomt.

Wat is het verschil tussen REST en GraphQL?

REST levert per endpoint een vast antwoord (alle velden van een resource). GraphQL laat de vraag bepalen welke velden u terugkrijgt, wat handig is bij complexe data-modellen. REST is de breedste standaard, GraphQL is sterker voor specifieke front-end- of mobile-scenario's.

Hoeveel kost een API-integratie?

Dat hangt af van het aantal systemen, de complexiteit van de business-logic en de eisen rondom compliance en monitoring. Een eenvoudige iPaaS-koppeling zit aan de laagste kant van het spectrum; een productie-waardige multi-systeem-integratie met eigen middleware ligt aanzienlijk hoger. Vraag altijd een scope-gesprek aan voordat u een offerte aanvraagt.

Is een API-integratie AVG-proof?

Op zichzelf niet — dat moet ingericht worden. Met een DPA, TLS-encryptie, audit-logging en data-minimalisatie kan een API-integratie volledig AVG-compliant zijn. De verantwoordelijkheid ligt bij u als verwerkingsverantwoordelijke, samen met uw integratie-partner.

Hoe veilig is een API-integratie?

Veilig zodra de basis goed staat: authenticatie via OAuth 2.0 of veilig beheerde API-keys, TLS op al het verkeer, geen credentials in broncode, rate-limiting tegen misbruik en monitoring op afwijkende patronen. Onveilig zodra een van die elementen ontbreekt.

Hoe begin ik met een API-integratie?

Start met de vraag: welk handwerk doen mensen nu dat eigenlijk geautomatiseerd kan? Inventariseer welke systemen daarbij betrokken zijn, of die een API hebben, en wat het bedrijfsbelang is. Met dat lijstje is een eerste gesprek met een integratie-partner een stuk gerichter — en kunt u zelf inschatten of het via iPaaS of via maatwerk moet.

Hoe lang duurt het bouwen van een API-integratie?

Dat verschilt sterk. Een eenvoudige iPaaS-flow tussen twee gangbare SaaS-tools kan in een paar werksessies staan. Een maatwerk-koppeling met meerdere systemen, mapping per veld, monitoring en compliance-eisen vraagt een traject van meerdere sprints. Doorlooptijd is bijna nooit de bottleneck — duidelijkheid over scope en toegang tot de API-credentials wel.

Wat gebeurt er als een API verandert?

SaaS-leveranciers communiceren API-wijzigingen meestal ruim vooraf. Een goede integratie-partner monitort die aankondigingen, plant de migratie in en test het upgrade-pad. Zonder dat structureel beheer ontdekt u een breaking-change vaak pas op de dag dat de oude versie wordt uitgezet.