Wat kost een API-koppeling? Drie scopes, en waarom de markt factor tien uiteenloopt

Een API-koppeling kost in de Nederlandse markt tussen een paar honderd en enkele tienduizenden euro's, en dat verschil zit vrijwel nooit in de systemen die je koppelt. Het zit in de scope: één richting of twee, één entiteit of vijf, met of zonder foutafhandeling, met of zonder monitoring. Hieronder staan drie benoemde scopes met wat er per scope wordt opgeleverd, zodat je twee offertes eindelijk naast elkaar kunt leggen.

In drie regels: scope A is één richting en één entiteit — orders van de shop naar de boekhouding, meer niet. Scope B is tweerichting met transformatie: velden vertalen, conflicten oplossen, voorraad terugsturen. Scope C is event-driven met meerdere systemen, een wachtrij, herstel en replay. Drie verschillende producten. Dat ze alle drie "een koppeling" heten is de reden dat offertes onvergelijkbaar zijn.

Waarom "een koppeling tussen A en B" geen scope is

Appfront maakt het scherpste punt van de markt: twee koppelingen die allebei "Shopify naar Exact Online" heten kunnen factor tien in prijs schelen (volgens Appfront, bijgewerkt mei 2026). In de zin "koppel systeem A aan systeem B" staat namelijk niets over de dingen die het werk bepalen.

• Welke entiteiten. Alleen orders, of ook klanten, artikelen, voorraad, betalingen, creditnota's en verzendingen? Elke entiteit is een eigen mapping en testset.
• Welke richting. Eenrichting is een vertaling. Tweerichting is een onderhandeling: wijzigen beide kanten hetzelfde veld, dan moet vastliggen wie wint.
• Welke randgevallen. Een order zonder btw-nummer, een onbekend artikel, een deellevering, een retour. Randgevallen zijn geen uitzondering; ze zijn het werk.
• Wat er gebeurt als het misgaat. Zonder retries, wachtrij en alerting krijg je een koppeling die stil faalt — de duurste vorm van goedkoop.
• Wie het daarna beheert. Zonder documentatie, monitoring en overdracht is het een afhankelijkheid, geen oplossing.

De acht variabelen die de prijs bepalen

1. Richting — eenrichting, tweerichting, of tweerichting met een bron van waarheid per veld.
2. Aantal entiteiten — elke extra entiteit is mapping, validatie, testscenario's en documentatie.
3. Transformatie — veld-naar-veld is goedkoop; btw-logica, eenheden, staffelprijzen en samengestelde artikelen niet.
4. Volume en frequentie — honderd berichten per dag stelt andere eisen dan honderdduizend; bij volume krijg je rate limits en wachtrijen.
5. Foutafhandeling — retries met backoff, deduplicatie, dead-letter queue en herstelprocedure. Dit verklaart het verschil tussen een lage en een hoge offerte grotendeels.
6. Authenticatie — een statische API-sleutel is een middag; OAuth met refresh-tokens en meerdere administraties is een eigen onderdeel.
7. Monitoring en alerting — meten is één ding, iemand die de melding krijgt en er iets mee doet is een ander.
8. Overdracht — mapping-document, runbook, toegang tot repository en omgeving.

Scope A — één richting, één entiteit

Eén brontype, één doeltype, één richting: orders uit de webshop naar de boekhouding. Je krijgt een mapping-document met per veld herkomst en bestemming, een testset met de gangbare gevallen, logging van elke poging en een melding als de koppeling er een dag niet doorheen komt. Buiten de scope vallen retouren en creditnota's, historische data, tweerichtingsverkeer en alles wat niet in de mapping staat.

Dit is de scope waarin een bureau eerlijk een laag bedrag kan noemen. Volgens Coding Agency (bijgewerkt 16-04-2026) begint een eenvoudige koppeling bij EUR 500–1.500, met een gerekend voorbeeld van WooCommerce naar Moneybird op EUR 800. Volgens Kriyak (14-07-2026) ligt een eenvoudige eenrichtingskoppeling op EUR 1.000–2.500. Geloofwaardige bedragen — voor precies dít.

Scope B — tweerichting met transformatie

Nu gaat er ook iets terug: voorraad naar de shop, klantgegevens naar het CRM, factuurstatus naar het portaal. Een tweede richting voegt drie dingen toe die in scope A niet bestaan. Conflictregels: wijzigt de voorraad in beide systemen, dan moet vastliggen welk systeem wint. Lusbeveiliging: een wijziging die je terugschrijft mag niet opnieuw een wijziging aan de andere kant triggeren. En transformatie die kan mislukken — een btw-code die niet bestaat, een artikelcode die niet matcht.

Hier komt de eerste serieuze foutafhandeling bij: retries met exponential backoff op de fouten die je mág herhalen, deduplicatie op event-id en een wachtrij met wat het niet haalde. Volgens Kriyak (14-07-2026) kost een tweezijdige koppeling met foutafhandeling EUR 2.500–5.000; Coding Agency rekent voor CRM naar Exact Online EUR 2.200 (bijgewerkt 16-04-2026). Wat er onder foutafhandeling valt, staat in waarom koppelingen stukgaan.

Scope C — event-driven, meerdere systemen

Scope C is geen zwaardere versie van B; het is een ander soort project. Systemen praten niet meer rechtstreeks met elkaar maar leveren events aan een wachtrij, losgekoppeld van de verwerking. Dat is de enige manier om een piek, een storing en een herstelactie te overleven zonder data te verliezen.

• Queue — events worden eerst veilig weggeschreven en pas daarna verwerkt; ontvangen en verwerken falen niet samen.
• Herstel — mislukte berichten belanden in een dead-letter queue met payload, foutmelding en aantal pogingen.
• Replay — een periode opnieuw draaien nadat de oorzaak is gerepareerd. Mag alleen als elke schrijfactie idempotent is.
• Observability — foutratio, wachtrijdiepte, ouderdom van het oudste bericht en verwerkingstijd, met drempel en ontvanger.

Marktbedragen hier: EUR 3.000+ met een multi-systeemvoorbeeld van EUR 5.500 volgens Coding Agency (bijgewerkt 16-04-2026), EUR 10.000+ voor de zwaarste staffel volgens Brixxs (geen datum vermeld), en EUR 15.000–35.000+ voor enterprise volgens Bespoke Automation (geen datum vermeld).

Dezelfde opdracht in drie scopes

Neem één opdracht: "orders van de webshop naar de boekhouding". Zo groeit die van A naar C.

1. Scope A. Nieuwe order wordt een verkoopfactuur. Klant wordt aangemaakt als hij nog niet bestaat, artikelcodes moeten matchen. Mislukt het, dan zie je dat in het log.
2. Scope A plus btw. Buitenlandse verkoop, verlegde btw, een marge-artikel. Iemand moet de btw-logica uitschrijven en per geval testen. Dit is de eerste plek waar offertes uiteenlopen zonder dat de opdracht veranderde.
3. Scope B. Voorraad gaat terug naar de shop, betaalstatus komt terug uit de boekhouding. Conflictregels, lusbeveiliging, retries met backoff, wachtrij.
4. Scope B plus retouren. Creditnota's, deelleveringen en annuleringen: elk een eigen mapping en testscenario, en in de meeste offertes onbenoemd.
5. Scope C. Er komt een marketplace bij en een tweede administratie. Nu wil je events, een dead-letter queue, replay per periode en monitoring met drempels.

Wat de markt zegt, met bron en datum

De bandbreedtes hieronder komen letterlijk van de pagina's van andere partijen. Ze zijn onderling niet vergelijkbaar, en dat is het punt: elk bedrag hoort bij een andere, meestal onbenoemde scope.

Twee bronnen noemen ook een uurtarief en een terugverdientijd: circa EUR 86 per uur volgens Kriyak (14-07-2026) en 2–4 maanden terugverdientijd volgens Coding Agency (bijgewerkt 16-04-2026). Een gemiddelde over deze rij heeft geen zin: je middelt dan scope A met scope C.

Wat er meestal niet in een offerte staat

• Foutafhandeling en retries. Welke HTTP-fouten worden herhaald, met welke wachttijd, en wanneer stopt het? Zonder antwoord laat de koppeling bij de eerste storing berichten vallen.
• Monitoring en alerting. Niet "we loggen alles", maar: welke drempel veroorzaakt een melding, wie ontvangt hem, binnen welke tijd wordt er gereageerd.
• Datamigratie en historie. De koppeling begint bij livegang. Bestaande klanten, openstaande orders en oude facturen zijn een apart project.
• Acceptatietesten met echte data. Drie verzonnen orders bewijzen niets; een export van vorige maand vindt de randgevallen.
• Documentatie en overdracht. Mapping-document, runbook, credentials op een beheerbare plek, toegang tot de repository.
• Rechten en API-kosten van derden. Sommige API's zitten achter een duurder abonnement. Dat is jouw rekening, niet die van het bureau.

Kosten na livegang

Volgens Coding Agency (bijgewerkt 16-04-2026) liggen de doorlopende kosten op EUR 50–200 per maand. Dat is één regel voor vier posten, die zich bij groei elk anders gedragen.

De belangrijkste vraag staat niet in dit rijtje: wie krijgt de melding als het misgaat, en binnen welke tijd wordt er iets mee gedaan? Dat hangt samen met het hostingniveau en de reactietijden eromheen.

No-code of maatwerk?

Zapier, Make en n8n zijn uitstekend voor lage volumes, tijdelijke stromen en processen die je zelf wilt aanpassen. Volgens Brixxs (geen publicatiedatum vermeld) ligt een startbudget voor n8n of Make op EUR 750–3.000, tegenover EUR 2.500–10.000+ voor een maatwerk-API-koppeling. Het omslagpunt ligt bij vier signalen: het volume nadert de rate limits van de andere kant, fouten kosten geld in plaats van tijd, niemand kan het scenario nog lezen, of je hebt eisen aan dataresidentie en audittrail. Zie ook wat automatiseren kost.

Wat als je systeem geen API heeft

Dit is de duurste variabele die bestaat, en hij staat in vrijwel geen prijsopbouw. Elke trede omlaag op deze ladder kost betrouwbaarheid en levert onderhoudslast op.

1. API met webhooks — de andere kant duwt wijzigingen naar jou. Snelst en betrouwbaarst, mits je valideert en dedupliceert.
2. API met polling — jij vraagt periodiek wat er veranderd is. Je betaalt in calls en merkt wijzigingen met vertraging.
3. Database-view — lezen uit een read-only view. Snel gebouwd, maar het datamodel kan zonder aankondiging wijzigen.
4. SFTP- of CSV-drop — bestanden op een afgesproken tijdstip. Voorspelbaar, maar batchgewijs: fouten zie je pas bij de volgende run.
5. RPA of UI-automatisering — een robot bedient de interface. Laatste redmiddel; breekt bij elke schermwijziging.

Vijf vragen die elke offerte vergelijkbaar maken

1. Welke entiteiten, welke richting per entiteit, en welk systeem is bron van waarheid per veld?
2. Welke statuscodes worden herhaald, met welke wachttijd, waar landt een definitief mislukt bericht, en wie krijgt daarvan bericht?
3. Hoeveel testscenario's zitten erin, en welke randgevallen zijn benoemd (retour, deellevering, ontbrekend artikel, afwijkende btw)?
4. Wat lever je op naast werkende code: mapping-document, runbook, monitoring, toegang tot repository en omgeving?
5. Wat kost het na livegang, uitgesplitst in vier posten — en van wie is de koppeling na oplevering? Dat laatste hoort in het contract; wat daarin moet staan lees je in eigenaarschap van broncode.

Twee details die de prijs stiller beïnvloeden

GET, PUT en DELETE zijn per definitie idempotent, POST en PATCH niet (volgens MDN, geraadpleegd 9 september 2026). Daarom levert het opnieuw versturen van een order-POST een tweede factuur op, tenzij er een idempotency key meegaat — Stripe accepteert daarvoor sleutels tot 255 tekens en geeft bij herhaling het opgeslagen resultaat terug (volgens de Stripe-documentatie, geraadpleegd 9 september 2026). Het tweede detail is de rate limit: Shopify hanteert voor de GraphQL Admin API een kostenmodel, geeft HTTP 429 bij overschrijding en adviseert één seconde te wachten (volgens Shopify, geraadpleegd 9 september 2026). Beide mechanismen moeten gebouwd worden, en dat zijn posten.

Hoe wij het aanpakken

We beginnen met een workflow-audit: twee sessies waarin we de huidige stroom vastleggen, entiteiten en richtingen benoemen en de randgevallen ophalen bij de mensen die ze dagelijks tegenkomen. Daaruit komt de scope, en op die scope zetten we een vaste prijs per fase in plaats van een open uurbudget — zie onze prijsopbouw per fase en de pagina over automatisering. Foutafhandeling, monitoring en overdracht zitten daarbij in de scope, niet in een optionele regel eronder. Dat maakt een offerte in eerste instantie hoger dan een offerte zonder die onderdelen, en dat is precies de factor tien waar dit artikel over gaat.