API koppeling laten maken die uw software verbindt

In de praktijk komen dezelfde categorieën terug: ERP en boekhouding (Exact Online, AFAS, SAP, Dynamics, Twinfield), CRM (HubSpot, Salesforce, Pipedrive), e-commerce en marktplaatsen (Shopify, WooCommerce, Magento, Bol.com), betalingen (Stripe, Mollie, Adyen), verzending en logistiek (SendCloud, vervoerdersportalen) en HR- of urenpakketten. Daarnaast koppelen we veel maatwerksystemen via REST of GraphQL, en oudere systemen via SOAP of databaseviews. Per systeem staan uitgewerkte gidsen op /api-koppelingen. Staat uw pakket er niet tussen, dan is dat zelden een blokkade: wat bepaalt of een koppeling kan is niet de naam van het systeem, maar of gegevens er op een gecontroleerde manier in en uit komen.

Eén richting, één systeem, goede documentatie en een sandbox: dan praten we over één tot drie weken inclusief tests. Tweerichtingsverkeer met conflictregels, of een systeem zonder sandbox waar u alleen op productie kunt proeven, loopt op naar zes tot tien weken. Legacy zonder API is een apart traject, omdat de eerste weken opgaan aan uitzoeken hoe gegevens er betrouwbaar uit komen. We geven pas een planning na een korte inventarisatie waarin we de documentatie doorlopen, testtoegang aanvragen en het datavolume bekijken. Het aanvragen van API-toegang bij een leverancier is trouwens vaker de vertragende factor dan het bouwwerk zelf.

Dan zoeken we een andere gecontroleerde route. In volgorde van voorkeur: een SOAP-service als die er nog is, een databaseview of read-only replica, een geplande export via SFTP of een gedeelde netwerkschijf met CSV- of XML-bestanden, en pas als laatste een gescripte browserroute. Bij bestandsuitwisseling regelen we de dingen die daar altijd misgaan: unieke bestandsnamen, verwerkte bestanden archiveren, half weggeschreven bestanden negeren en detecteren dat een export vandaag niet is geleverd. Soms is de kortste weg vragen: leveranciers bouwen vaker een endpoint dan verwacht als een klant er concreet om vraagt. We helpen bij het formuleren van die aanvraag.

Verkeer altijd over TLS, authenticatie via OAuth 2.0 met de kleinste scope die werkt of API keys per omgeving, en credentials in een secrets manager in plaats van in code, config of een spreadsheet. Sleutels zijn daardoor roteerbaar zonder de koppeling te herbouwen. Voor zorg en finance bouwen we audit trails waarin staat welke gegevens wanneer zijn verstuurd en door welk proces, wat AVG-verantwoording en NEN 7510-eisen praktisch maakt. Verder gelden dataminimalisatie (alleen de velden die de ontvanger nodig heeft), EU-hosting en logging waarin persoonsgegevens gemaskeerd staan. Een koppeling is een deur tussen twee systemen; wie erdoor mag en wat er passeert hoort expliciet vastgelegd te zijn.

Iedere API knijpt op een moment af, en dat gebeurt precies op uw drukste dag. Daarom zetten we geen directe aanroepen tussen systemen maar een wachtrij ertussen. Berichten worden in gecontroleerd tempo verwerkt, blijven staan als de andere kant traag is, en mislukte pogingen worden opnieuw aangeboden met exponentiële backoff: eerst na seconden, dan na minuten. Aanroepen zijn idempotent, zodat een herhaalde poging geen dubbele order of dubbele factuur oplevert. Wat na een aantal pogingen niet slaagt gaat naar een dead letter queue met de originele payload, zodat het handmatig of na een fix opnieuw verwerkt kan worden. Niets verdwijnt stil.

Dit is bijna altijd het echte werk. Twee systemen bewaren zelden hetzelfde: adressen met huisnummer en toevoeging in één veld tegenover drie losse velden, datums als tijdzoneloze tekst tegenover UTC, bedragen in euro's met komma tegenover centen als geheel getal, btw inclusief of exclusief, en klantnummers die in het ene systeem leidend zijn en in het andere niets betekenen. We leggen per veld vast welk systeem de waarheid bevat, hoe we normaliseren en wat er gebeurt bij een waarde die nergens in past. Records die de validatie niet halen komen op een controlelijst, in plaats van stil overgeslagen te worden.

Elke koppeling die wij opleveren heeft een healthcheck die elke vijf minuten controleert of de laatste synchronisatie is gelukt en of de wachtrij niet oploopt. Bij afwijkingen gaat er een melding uit voordat uw klantenservice merkt dat er iets mist. Daarnaast volgen we changelogs en deprecation-berichten van de leveranciers die u gebruikt. Voor breaking changes werken we met een afspraak in de retainer: melden en inplannen binnen een vastgelegde termijn, met spoedbehandeling wanneer een leverancier een endpoint op korte termijn uitzet. Zonder dat vangnet ontdekt u een gebroken koppeling meestal via een klant, en herstelt u de fout plus de achterstand.

Vaak, en zelden door de bestaande koppeling meteen uit te zetten. We bouwen de nieuwe stroom ernaast en laten die eerst meelopen zonder te schrijven: dezelfde gegevens, alleen loggen en vergelijken met wat de oude koppeling doet. Verschillen zijn dan zichtbaar zonder risico voor de operatie. Klopt het beeld enkele dagen tot weken, dan zetten we per gegevensstroom over en houden we de oude route nog even beschikbaar. Bijkomend voordeel: die parallelle periode maakt eindelijk duidelijk wat de oude koppeling precies deed, en bij ongedocumenteerde scripts is dat vaak de belangrijkste ontbrekende kennis.

Eén stroom tussen twee systemen met een nette API blijft doorgaans binnen enkele duizenden euro's, inclusief tests en monitoring. Zodra het om een landschap gaat, bijvoorbeeld webshop, ERP, voorraad en verzending die elkaar allemaal moeten volgen, gaat het niet meer om vier losse koppelingen maar om afspraken over welk systeem waar leidend is; daar zit het meerwerk en dus de investering. Legacy zonder API en tweerichtingsverkeer met conflictregels zijn de twee grootste prijsopdrijvers. Reken naast de bouw op doorlopende kosten voor monitoring en onderhoud. Voor een eerste bandbreedte gebruikt u /calculator; een onderbouwde prijs volgt na de inventarisatie.

Real-time is niet automatisch beter. Voor een voorraadstand die klanten zien, of een betaling die een order moet vrijgeven, wilt u events en webhooks binnen seconden. Voor grootboekregels, dagrapportages of prijslijsten is een batch per nacht rustiger, goedkoper en makkelijker te controleren, omdat u één keer per dag naar één overzicht kijkt. Veel landschappen worden daarom gemengd: realtime waar de gebruiker wacht, batch waar de administratie wacht. We kiezen per gegevensstroom op basis van hoe erg het is als gegevens een uur oud zijn, en hoeveel aanroepen het bronsysteem aankan.

We testen tegen sandboxomgevingen waar die bestaan en werken met geautomatiseerde tests per koppeling, maar de winst zit in de uitzonderingen: een order die tijdens de synchronisatie wordt geannuleerd, een creditnota, een klant die twee keer bestaat, een veld dat leeg blijkt te mogen zijn, een time-out midden in een reeks. Die scenario's spelen we bewust af voordat we live gaan. Waar geen sandbox is, testen we op productie met gemarkeerde testrecords en een beperkte set. Verrassingen volledig uitsluiten kan niemand; wel zorgen dat een verrassing zichtbaar wordt en niet stil doorwerkt in uw administratie.

Elke stroom logt wat erin ging, wat eruit kwam en welke poging het was, met persoonsgegevens gemaskeerd. Loopt een wachtrij op of faalt een healthcheck, dan krijgt het team een melding met de context erbij. Bij een storing kunnen we één stroom pauzeren zonder de rest te raken, een release terugdraaien en na de fix de wachtrij opnieuw laten verwerken. Omdat aanroepen idempotent zijn levert dat geen dubbele boekingen op. Daarna volgt een korte terugkoppeling: wat gebeurde er, wat is de tijdelijke maatregel en welke aanpassing voorkomt herhaling. Retainer-klanten hebben daarvoor vaste responstijden.

Technisch is er geen grens; organisatorisch wel. We beginnen daarom met de stroom die het meeste handmatige overtypwerk wegneemt en breiden daarna uit. Elke koppeling krijgt een eigen module met eigen logging en monitoring, zodat een storing bij één leverancier de rest niet meesleept. Wat bij meer dan een handvol systemen echt bepalend wordt, is een centraal beeld van welk systeem leidend is per gegeven: zonder die afspraak overschrijven systemen elkaars gegevens en is niemand meer zeker van de juiste waarde. Twee systemen of twintig, dezelfde aanpak; alleen de tijd die aan die afspraken gaat verschilt.

Verstandig wanneer volumes laag zijn, de logica simpel is en snelheid belangrijker is dan controle: Make of Zapier zet een eenvoudige stroom in dagen live en dat is soms precies genoeg. Minder verstandig zodra u per maand tienduizenden records verwerkt (prijs per taak loopt op), zodra er echte bedrijfsregels in zitten die u wilt kunnen testen, of zodra een fout geld kost en u traceerbaarheid nodig heeft. Ook belangrijk: kennis in een visuele flow is moeilijk over te dragen en zit in het platform, niet bij u. We adviseren per situatie en bouwen soms een mix: iPaaS voor randstromen, maatwerk voor de kern.