Een order komt binnen in de webshop. Iemand typt hem over in het ERP-systeem, en aan het eind van de maand klopt de voorraad net niet. Als je een API-koppeling laat maken tussen die systemen, verdwijnt dat overtypwerk: gegevens gaan automatisch van het ene pakket naar het andere, op het moment dat het nodig is. Dat scheelt tijd, en het scheelt vooral fouten.
Een API-koppeling in het kort
Een API-koppeling is software die twee systemen automatisch gegevens laat uitwisselen. Dat gaat via hun API: een vaste ingang die een pakket biedt voor andere software. Denk aan een CRM dat nieuwe klanten doorzet naar de boekhouding, of een klantportaal dat statussen ophaalt uit het ERP. Zo ontstaan minder handwerk, minder fouten en actuele gegevens in elk systeem.
API staat voor Application Programming Interface. De API legt vast welke gegevens een systeem deelt, in welk formaat en met welke rechten. De koppeling is de code die daar gebruik van maakt. Die code bepaalt wat er wanneer wordt opgehaald of verstuurd, en wat er gebeurt als iets misgaat.
Dat laatste deel wordt vaak onderschat. Gegevens van A naar B sturen kost weinig moeite. Een koppeling die blijft werken als een systeem een uur onbereikbaar is, of als een leverancier zijn API aanpast, vraagt vakmanschap.
Soorten koppelingen en manieren van integreren
Er bestaat niet één type koppeling. De juiste vorm hangt af van het aantal systemen, de hoeveelheid data en hoe snel die data moet doorkomen.
De drie meest gebruikte manieren om systemen te verbinden:
- Directe koppeling: twee systemen praten rechtstreeks met elkaar. Dat is overzichtelijk bij één of twee verbindingen, maar wordt al snel een kluwen als er meer systemen bijkomen.
- Standaardconnector of koppeltool: een kant-en-klare verbinding die een pakket of een integratieplatform aanbiedt. Voor eenvoudige, gangbare stromen is dat vaak genoeg.
- Eigen integratielaag: alle koppelingen lopen via één centrale laag die jullie zelf in handen hebben. Dat is de meest robuuste vorm als je meerdere systemen koppelt of als systemen in de loop der jaren wisselen.
Het nut van zo’n aparte laag zie je bij Swishfund, waarvoor we sinds 2018 de techniek onder MKB-financiering bouwen. De koppelingen met onder meer de KvK, Companies House en PSD2-rekeninginzage zitten daar in een eigen API-hub. Daardoor kon de bankkoppeling drie keer worden vervangen zonder dat het aanvraagformulier hoefde te veranderen.
Naast de vorm kies je ook het moment van uitwisselen. Bij realtime uitwisseling stuurt een systeem direct een seintje als er iets verandert (een zogeheten webhook). Bij periodieke uitwisseling worden gegevens op vaste momenten in één keer overgezet, bijvoorbeeld elke nacht. Realtime is nodig als iemand direct verder moet met de gegevens. Voor rapportages volstaat een nachtelijke run meestal.
Wanneer een koppeling loont en wanneer niet
Niet elke handmatige stap rechtvaardigt een koppeling. We adviseren te kijken naar hoe vaak de handeling voorkomt en wat een fout kost.
Een koppeling loont vaak als:
- dezelfde gegevens dagelijks of wekelijks in meerdere systemen worden ingevoerd;
- een fout bij het overtypen gevolgen heeft voor klanten, facturen of rapportages aan toezichthouders;
- medewerkers wachten op gegevens die al in een ander systeem staan;
- jullie willen groeien zonder dat het administratieve werk in dezelfde mate meegroeit.
Soms is het eerlijke advies om het niet te doen. Komt de handeling een paar keer per jaar voor, dan wegen de bouw en het onderhoud zelden op tegen de tijdwinst. Biedt het pakket al een ingebouwde koppeling die het proces dekt, dan is die vaak de verstandigste keuze. En wordt een van de systemen binnenkort vervangen, dan is een eenmalige datamigratie naar het nieuwe systeem meestal beter dan een koppeling met een pakket dat verdwijnt.
Zo verloopt het maken van een koppeling
Een goede koppeling begint niet met code, maar met het proces dat hij moet ondersteunen. Wie eerst snapt hoe de gegevens door de organisatie lopen, bouwt een koppeling die past bij hoe er gewerkt wordt.
De stappen in volgorde:
- Proces en datastromen in kaart brengen. Welke systemen zijn betrokken, waar zitten de handmatige tussenstappen, en welk systeem is leidend voor welk gegeven?
- De API’s beoordelen. Is er een API, hoe goed is die gedocumenteerd, is er een testomgeving en hoeveel verzoeken per minuut staat de leverancier toe?
- Velden op elkaar afstemmen. Bepaal per veld waar het heen gaat en in welk formaat. Datums, btw-codes en adressen zijn klassieke struikelblokken.
- Bouwen in kleine stappen. Begin met de belangrijkste stroom, laat die werken en breid daarna uit.
- Testen met realistische data. Testdata gedraagt zich netter dan de praktijk. Test daarom met echte, waar nodig geanonimiseerde gegevens voordat de koppeling live gaat.
- Live gaan en monitoren. Vanaf dag één moet zichtbaar zijn of berichten aankomen, en wie een melding krijgt als dat niet zo is.
Checklist voor een betrouwbare API-koppeling
De checklist hieronder kun je gebruiken om een koppeling te beoordelen, of je hem nu zelf laat bouwen of een bestaande koppeling onder de loep neemt. Hij volgt de levensloop van een koppeling: voorbereiding, bouw en beheer.
Voor de bouw
In deze fase leg je de basis. Fouten die hier ontstaan, zijn later het lastigst te herstellen.
- Doel en eigenaar: het is duidelijk welk proces de koppeling ondersteunt en wie binnen jullie organisatie eigenaar is van de data.
- Bron van waarheid: per gegeven is vastgelegd welk systeem leidend is, bijvoorbeeld het CRM voor adressen en het ERP voor prijzen.
- Toegang en documentatie: er is een testomgeving en de limieten van de API zijn bekend.
- Veldkoppeling: elk veld heeft een bestemming en een afgesproken formaat.
- Timing: de keuze tussen realtime en periodiek is gemaakt op basis van het proces, niet op basis van wat technisch het makkelijkst is.
Tijdens de bouw
Hier bepaal je hoe de koppeling zich gedraagt als het tegenzit. Die momenten komen altijd, dus het gaat erom dat de koppeling er goed op is voorbereid.
- Foutafhandeling: als een systeem niet reageert, gaat er niets verloren en weet iemand ervan.
- Herhaalpogingen en wachtrijen: mislukte berichten worden bewaard en later opnieuw aangeboden.
- Dubbele verwerking voorkomen: een order die twee keer binnenkomt, wordt één keer geboekt.
- Beveiliging: sleutels staan veilig opgeslagen en de koppeling heeft alleen de rechten die hij nodig heeft.
- Aparte laag: de koppeling zit los van de rest van de applicatie, zodat jullie een systeem kunnen vervangen zonder alles om te bouwen.
Na livegang
Een koppeling is nooit af. Leveranciers passen hun API’s aan, processen veranderen en de hoeveelheid data groeit.
- Monitoring en meldingen: storingen worden gesignaleerd voordat een gebruiker ze opmerkt.
- Logboek: het is terug te zien wat er wanneer is uitgewisseld.
- API-wijzigingen volgen: nieuwe versies van leveranciers worden op tijd verwerkt.
- Documentatie en eigendom: de code en de documentatie zijn van jullie en een andere partij kan ze overnemen.
- Vast aanspreekpunt: er is één partij die de koppeling kent en verantwoordelijk is voor beheer en doorontwikkeling.
Dit zijn ook precies de onderdelen waarop wij API-koppelingen bouwen: met foutafhandeling, herhaalpogingen, wachtrijen en monitoring als vast onderdeel, niet als extra optie.
Beveiliging, privacy en eigenaarschap
Een koppeling is een deur tussen systemen, en die deur moet je goed afsluiten. Zeker als er persoonsgegevens doorheen gaan, speelt de AVG een directe rol.
Een API-sleutel werkt als een wachtwoord voor software. Bewaar hem nooit in een mailtje of spreadsheet en geef hem alleen de rechten die de koppeling nodig heeft. Gaan er persoonsgegevens over de lijn, beperk je dan tot de velden die het proces nodig heeft. Leg ook vast wie de gegevens verwerkt. Wij sluiten standaard een verwerkersovereenkomst af met klanten van wie we persoonsgegevens verwerken.
Na livegang blijft beveiliging onderhoudswerk. Bij de servers die wij beheren betekent dat wekelijks onderhoud, dagelijkse monitoring en het direct doorvoeren van kritieke updates.
Let ook op eigenaarschap. Een koppeling die alleen de bouwer kan onderhouden, maakt jullie afhankelijk. Bij ons zijn de code, content en data van de klant en dat blijven ze. We gebruiken gangbare technologie, zoals Laravel en Node.js, zodat er geen lock-in ontstaat.
Waar de kosten van een koppeling van afhangen
Een vaste prijs voor ‘een koppeling’ bestaat niet, omdat geen twee koppelingen hetzelfde zijn. De kosten hangen vooral af van een handvol factoren.
De belangrijkste factoren op een rij:
- Kwaliteit van de API: een goed gedocumenteerde API met testomgeving scheelt veel uitzoekwerk.
- Aantal systemen en stromen: één richting is eenvoudiger dan gegevens die heen en weer gaan.
- Datakwaliteit: rommelige of dubbele gegevens moeten eerst worden opgeschoond.
- Eisen aan snelheid en betrouwbaarheid: een bedrijfskritische realtime stroom vraagt meer dan een nachtelijke export.
- Beheer na oplevering: monitoring, updates en aanpassingen aan nieuwe API-versies lopen door zolang de koppeling draait.
Zet die kosten af tegen wat de koppeling oplevert: uren die niet meer aan overtypen opgaan, minder herstelwerk en snellere doorlooptijden. Bespaarde tijd is pas bespaard geld als duidelijk is waar de vrijgekomen uren naartoe gaan. Bekijk daarom niet alleen hoeveel tijd een koppeling scheelt, maar ook wat het team met die tijd gaat doen.
Van losse koppeling naar samenhangend datalandschap
De eerste koppeling lost vaak één knelpunt op. Daarna volgt meestal de vraag hoe alle systemen samen een betrouwbaar beeld geven.
Bij Soli Infratechnik groeide de software in tien jaar uit tot een platform met meer dan 20 koppelingen met systemen van derden, voor monteurs, onderaannemers en de planning. Bij Stichting DOEN vult het portfolio op de fondsensites zichzelf vanuit NetSuite en Optimy. Daardoor hoeft niemand projecten twee keer in te voeren.
Wie koppelingen goed opzet, legt ook de basis voor dashboards en rapportages die op actuele gegevens draaien. Vaak volgt dan de stap naar interne tools die bedrijfsprocessen automatiseren. Daarin komen de gegevens uit verschillende systemen samen op één werkplek.
Veelgestelde vragen
Wat kost het om een API-koppeling te laten maken?
Dat hangt af van de kwaliteit van de API, het aantal systemen, de staat van de data en de eisen aan betrouwbaarheid. Reken ook de lopende kosten mee voor monitoring en onderhoud. Een goede inventarisatie vooraf geeft een realistische begroting.
Kan ik zelf een API-koppeling maken?
Voor eenvoudige stromen tussen gangbare pakketten kan een standaardconnector of koppeltool volstaan. Gaat het om bedrijfskritische processen, persoonsgegevens of meerdere systemen, dan zijn foutafhandeling, beveiliging en monitoring doorslaggevend. Dan loont het om met een softwarepartner te werken.
Wat is een API-sleutel?
Een API-sleutel is een unieke code waarmee een systeem zich bij een ander systeem aanmeldt, vergelijkbaar met een wachtwoord. Je maakt hem meestal aan in de beheeromgeving van het pakket waarmee je wilt koppelen. Bewaar hem veilig en geef hem zo min mogelijk rechten.
Wat gebeurt er als een leverancier zijn API wijzigt?
Leveranciers kondigen grote wijzigingen meestal vooraf aan en ondersteunen oude versies nog een tijd. Het beheer van de koppeling moet die aankondigingen volgen en de koppeling op tijd bijwerken. Een aparte integratielaag beperkt de aanpassing tot de koppeling zelf.
Een koppeling die jaren blijft werken
Of je een API-koppeling laat maken, hangt af van hoe vaak de handeling voorkomt, wat een fout kost en hoe lang de systemen nog meegaan. Kies je ervoor, let dan vooral op wat er gebeurt als het tegenzit: foutafhandeling, monitoring en een partij die de koppeling na oplevering blijft beheren.
Wil je eerst weten waar jullie datastromen staan? Bij Data & integraties brengen we in de Data (warehouse) scan in één week alle systemen, koppelingen en handmatige tussenstappen in kaart. Je krijgt de risico’s erbij en een plan dat geordend is op impact.