Wat is een API? Uitleg voor ondernemers, met de vragen die je moet stellen

Laatst bijgewerkt: 6 augustus 2026, Redactie AI voor Bedrijven. Onderzoek afgerond op 6 augustus 2026.

Op 1 januari 2026 werd een technisch begrip in België plots juridisch relevant. Sinds die datum moeten alle btw-plichtige Belgische bedrijven hun B2B-facturen elektronisch uitwisselen via het Peppol-netwerk. Een pdf per e-mail volstaat niet meer. Peppol is niets anders dan een gestandaardiseerde koppeling tussen boekhoudsystemen, en dat maakt de vraag “wat is een API” ineens een ondernemersvraag in plaats van een IT-vraag.

In het kort: een API is een afgesproken manier waarop twee programma’s met elkaar praten. Het ene programma vraagt iets, het andere antwoordt in een vast formaat. Denk aan de kelner tussen jou en de keuken, of aan een stopcontact waar elk apparaat met dezelfde stekker op past. Voor jou als ondernemer betekent een API: minder overtypen, minder fouten, en een leverancier aan wie je acht scherpe vragen moet stellen.

Samenvatting in het kort

• Een API (Application Programming Interface) laat twee softwarepakketten automatisch gegevens uitwisselen, zonder dat iemand iets overtypt.
• Je hebt er meestal een nodig bij dagelijks terugkerend werk, realtime voorraad of prijzen, en wettelijke uitwisseling zoals Peppol.
• Bij een handvol records per maand is een CSV-export goedkoper dan een koppeling. Eerlijk is eerlijk.
• Belgische B2B-facturatie via Peppol is verplicht sinds 1 januari 2026. In Nederland is B2B-e-facturatie niet verplicht, wel moeten decentrale overheden e-facturen kunnen ontvangen.
• De kosten zitten in vier posten: bouwen, licentie of verbruik, onderhoud bij wijzigingen, en de kost van storingen.
• Veiligheid vertaal je via de OWASP API Security Top 10 uit 2023 naar kmo-taal: aparte sleutels, limieten, en oude koppelingen intrekken.
• Je kunt met tools als Zapier, Make of n8n koppelingen maken zonder programmeren.
• AI-tools praten met je systemen via API’s, en je betaalt per verzoek. Een limiet instellen is geen luxe.

Wat is een API in simpele woorden?

Een API is een afsprakenlijst tussen twee programma’s: wat mag je vragen, hoe vraag je het, en hoe ziet het antwoord uit. Je hoeft niet te weten hoe het andere systeem intern werkt, net zoals je niet in de keuken hoeft te staan om een bord op tafel te krijgen.

De twee vergelijkingen die het snelst blijven hangen:

• De kelner. Jij zegt wat je wil, de kelner brengt je vraag naar de keuken en komt terug met het resultaat. Jij ziet de keuken nooit. De kelner is de API.
• Het stopcontact. Elk apparaat met dezelfde stekker past erop. Dat is precies wat een standaard zoals Peppol doet: het maakt boekhoudpakketten onderling uitwisselbaar, ook als ze intern volstrekt verschillend zijn.

Een API verkoopt geen gegevens. Hij regelt de manier waarop je erom vraagt en wat je terugkrijgt.

Waarom je dit als ondernemer moet snappen: bijna elke keuze die je maakt over software, van je webshop tot je facturatiepakket, bepaalt of je later nog kunt koppelen. Software zonder bruikbare API is een gesloten doos. Je gegevens zitten erin, maar je krijgt ze er niet vlot uit.

Hoe werkt een API precies?

Een API werkt in vier stappen: jouw systeem stuurt een verzoek naar een adres, het andere systeem controleert of je mag, zoekt de gegevens op, en stuurt een antwoord terug in een vast formaat. Dat hele rondje duurt normaal minder dan een seconde.

De begrippen die je in elke offerte en elke handleiding tegenkomt, in gewone taal:

Zo klein kan een antwoord zijn, in JSON:

{ "klantnummer": 4512,
  "naam": "Bakkerij De Groot",
  "openstaand": 1249.50 }

Drie regels, en je boekhouding weet precies wat er openstaat. Dat is de hele truc: gegevens komen niet als een lap tekst binnen, maar in vakjes die een computer feilloos kan verwerken.

Veelgemaakte denkfout: ondernemers verwachten dat een API “de gegevens ziet zoals ik ze zie”. Dat is niet zo. Een API levert velden, geen schermen. Vraag je leverancier dus altijd welke velden beschikbaar zijn, niet of “de gegevens” beschikbaar zijn.

Is een API hetzelfde als een database?

Nee. Een database is de opslagplaats, een API is de balie ervoor. De database bewaart je klanten en facturen. De API bepaalt wie welk stuk mag opvragen, in welke vorm, en hoe vaak. Zonder API zou elk extern programma rechtstreeks in je archief moeten graaien.

Dat verschil is geen semantiek, het is een beveiligingsprincipe. Een API kan zeggen: je mag de naam en het factuurbedrag zien, maar niet het rekeningnummer. Een rechtstreekse databasekoppeling kan dat veel moeilijker. Als een leverancier voorstelt om “gewoon rechtstreeks in de database te lezen”, is dat een rood vlaggetje. Vraag waarom er geen API is.

Wil je zien hoe database en API in de praktijk samenkomen, dan is wat is Supabase een goed voorbeeld: je krijgt daar een database én automatisch een API erbovenop.

Wat zijn voorbeelden van API’s, en welke bedrijven gebruiken ze?

Vrijwel elk bedrijf dat online iets doet gebruikt al API’s, meestal zonder het te weten. Een betaalknop, een verzendlabel, een adrescontrole en een e-facturatiekoppeling zijn allemaal API’s. In België is Peppol sinds 2026 zelfs een wettelijk verplicht voorbeeld geworden.

Concrete voorbeelden die je zelf herkent:

• Betalen in je webshop. De betaalprovider krijgt een verzoek met het bedrag en meldt terug of de betaling gelukt is.
• Verzendlabels. Je pakketdienst geeft een trackingnummer terug zodra de zending is aangemeld.
• Bedrijfsgegevens ophalen. De KVK biedt API’s aan waarmee je op basis van een KVK-nummer een basisprofiel of jaarrekening kunt opvragen, zodat je klantgegevens niet handmatig hoeft in te typen. Zie developers.kvk.nl.
• E-facturatie via Peppol. Je boekhoudpakket stuurt de factuur via een toegangspunt naar het pakket van je klant, in een standaardformaat. Meer achtergrond op peppol.org.
• Contactformulieren zonder eigen server. Zie Web3Forms voor een contactformulier zonder backend: je formulier stuurt een verzoek naar een API en die mailt het door.
• Software uitrollen. Ontwikkelplatformen praten onderling via API’s. Wie ooit een website liet bouwen, kwam waarschijnlijk in aanraking met wat is GitHub en wat is Vercel, die precies zo aan elkaar hangen.

Ook overheden werken zo. De Nederlandse overheid werkt met een gemeenschappelijke API-strategie en ontwerpregels voor REST-API’s, zodat verschillende instanties op dezelfde manier gegevens uitwisselen. De voortgang daarvan staat op digitaleoverheid.nl.

Belangrijk onderscheid voor Nederlandse ondernemers: e-facturatie tussen bedrijven onderling is in Nederland niet verplicht. Wel geldt dat decentrale overheden e-facturen moeten kunnen ontvangen en verwerken, dus als je aan een gemeente of provincie levert, is het relevant. Europese wetgeving ViDA (VAT in the Digital Age) verplicht e-facturatie vanaf 2030 voor grensoverschrijdende btw-transacties binnen de EU. Over andere Nederlandse einddata lopen de bronnen uiteen, dus leg die vraag bij je boekhouder.

API tegenover webhook tegenover Zapier tegenover CSV: wat is het verschil?

Er zijn vier manieren om gegevens tussen systemen te krijgen, en ze verschillen in richting, snelheid en kostprijs. Een API vraagt actief op, een webhook wordt gebeld zodra er iets gebeurt, een tussenlaag zoals Zapier of Make regelt het zonder programmeren, en een CSV-export is handwerk in bulk.

Een webhook is dus de omgekeerde richting van een API-verzoek: in plaats van elke vijf minuten vragen “is er al een nieuwe order”, laat je het andere systeem jou bellen. Dat scheelt verzoeken, dus geld, en het is sneller. Nadeel: als jouw kant even offline is, kan een melding verloren gaan. Vraag je leverancier dus altijd of er automatisch opnieuw geprobeerd wordt.

Voor de tussenlaag hebben we drie platforms onderzocht en vergeleken: onze review van Zapier voor wie het simpel wil, onze review van Make.com voor wie visueel wil bouwen met meer stappen, en onze review van n8n voor wie zelf wil hosten en de data in eigen huis wil houden. Volgens de documentatie van alle drie reken je af per uitgevoerde actie of taak, wat betekent dat een drukke maand ook een duurdere maand is.

Wanneer heb je een API nodig en wanneer juist niet?

Je hebt een API nodig zodra iemand in je bedrijf structureel gegevens overtypt, of zodra de wet je verplicht om gestandaardiseerd uit te wisselen. Je hebt er géén nodig bij kleine volumes, eenmalige migraties, of als je leverancier de koppeling al kant-en-klaar in het pakket heeft zitten.

Wel een koppeling, in deze gevallen:

• Iemand typt dagelijks of wekelijks dezelfde gegevens van systeem A naar systeem B over.
• Je hebt realtime voorraad of prijzen nodig, bijvoorbeeld tussen webshop en kassa.
• Er is een wettelijke uitwisseling in het spel, zoals Peppol voor Belgische B2B-facturatie sinds 1 januari 2026.
• Het gaat om honderden records per maand of meer, waarbij handmatig werk gegarandeerd fouten oplevert.
• Fouten zijn duur: verkeerde adressen, dubbele facturen, verkeerde voorraadstanden.

Geen koppeling, in deze gevallen:

• Het gaat om een handvol records per maand. Exporteren en importeren is dan simpelweg goedkoper dan bouwen en onderhouden.
• Het is een eenmalige migratie. Voor één verhuizing bouw je geen permanente brug.
• Je leverancier heeft de integratie al standaard beschikbaar. Betaal niet voor maatwerk dat al bestaat.
• Het proces verandert de komende maanden nog. Een koppeling op een wankel proces bouwen betekent twee keer betalen.

Beslisregel die in de praktijk goed werkt: vermenigvuldig de minuten handwerk per week met het uurloon van wie het doet, tel er de kost van fouten bij op, en zet dat naast de bouwkost plus twee jaar onderhoud. Komt de terugverdientijd boven de achttien maanden uit, dan is een tussenlaag of een export bijna altijd de betere keuze.

Wat kost een koppeling en waar zitten de verborgen kosten?

Een koppeling kost je op vier plaatsen geld: eenmalig bouwen, terugkerende licentie of verbruik, onderhoud wanneer de leverancier zijn API wijzigt, en de kost van storingen. Die laatste twee vergeten ondernemers bijna altijd bij het vergelijken van offertes.

De vier kostenposten, met wat je precies moet navragen:

1. Eenmalige bouwkosten. Ontwerp, bouwen, testen en in productie zetten. Vraag om een prijs per koppelrichting, niet per “project”: een koppeling die alleen leest is veel goedkoper dan een die ook wegschrijft.
2. Licentie, abonnement of verbruik. Sommige API’s zijn gratis, andere werken met een abonnement plus een bedrag per bevraging. De KVK-API’s zijn daarvan een helder voorbeeld: een vast maandbedrag plus een klein bedrag per bevraging, naast open data-API’s zoals Basisprofiel en Jaarrekeningen. Bij een tussenlaag betaal je per taak.
3. Onderhoud bij wijzigingen. API’s krijgen nieuwe versies. Soms is een wijziging onschuldig, soms is het een breaking change: een veld verdwijnt of verandert van naam en jouw koppeling valt stil. Vraag hoe vaak dat historisch gebeurde en hoeveel aankondiging je krijgt.
4. De kost van storingen. Wat kost het je als de koppeling drie dagen stilstaat tijdens je drukste week? Dat is een reëel bedrag in euro, in gemiste orders en in inhaalwerk.

Zo vergelijk je twee offertes eerlijk: vraag beide partijen om dezelfde drie getallen op papier. Eenmalige bouwkost, verwachte maandkost bij jouw volume, en het uurtarief voor onderhoud plus een schatting van het aantal onderhoudsuren per jaar. Zonder dat derde getal vergelijk je appels met peren.

Een gratis testomgeving verlaagt de kostprijs merkbaar, want je bouwer hoeft niet met echte gegevens te experimenteren. De KVK biedt bijvoorbeeld een gratis testomgeving met fictieve gegevens waarvoor je je niet hoeft te registreren, wat het proefdraaien vrijwel kosteloos maakt.

Wat zijn de voordelen van een API, en de nadelen?

De voordelen van een API zijn tijdwinst, minder fouten, actuelere gegevens en de mogelijkheid om later van pakket te wisselen. De nadelen zijn afhankelijkheid van een derde partij, terugkerende kosten en een nieuw beveiligingsrisico dat je moet beheren.

Voordelen:

• Geen dubbel werk meer: één keer invoeren in plaats van drie keer overtypen.
• Minder typefouten, dus minder correctiewerk en minder discussies met klanten.
• Actuele cijfers: voorraad en openstaande facturen zijn geen momentopname van gisteren.
• Schaalbaarheid: honderd orders per dag kost evenveel handwerk als tien.
• Uitwisselbaarheid: een pakket met een open API kun je later vervangen zonder alles te herbouwen.

Nadelen, en die noemen we net zo hard:

• Je bent afhankelijk van de beschikbaarheid en de keuzes van je leverancier.
• Er komt een terugkerende kost bij, in licentie of in verbruik.
• Elke koppeling is een extra deur, en elke deur moet je op slot kunnen doen.
• Bij een storing is de oorzaak vaak lastiger te vinden: ligt het bij systeem A, B, of bij de koppeling?

REST tegenover SOAP tegenover GraphQL: welke stijl API krijg je?

REST is de meest gebruikte stijl en werkt met adressen die je opvraagt via het web. SOAP is de oudere, strengere stijl die je vooral nog bij banken, verzekeraars en overheidssystemen tegenkomt. GraphQL laat je in één verzoek precies vragen welke velden je wil. Voor jou als ondernemer bepaalt de keuze vooral de bouwtijd, niet het resultaat.

Vuistregel: als je twee pakketten kunt kiezen en het ene heeft een REST-API met goede documentatie en het andere alleen SOAP zonder testomgeving, kies dan het eerste. Niet omdat REST beter is, maar omdat je bijna elke bouwer in Nederland en België vlot met REST kunt laten werken. Dat drukt je uurprijs en je afhankelijkheid van één specialist.

Kun je een API gebruiken of maken zonder programmeren?

Ja, voor de meeste kmo-situaties kun je API’s gebruiken zonder één regel code, via een tussenlaag als Zapier, Make of n8n. Een eigen API laten maken is wel echt bouwwerk, maar platformen die automatisch een API rond je database leggen maken dat een stuk goedkoper dan vroeger.

Gebruiken zonder programmeren, stap voor stap:

1. Bepaal welke twee tools moeten praten en wat de trigger is, bijvoorbeeld “nieuwe order in de webshop”.
2. Kies een tussenlaag en zoek of er kant-en-klare blokjes zijn voor beide tools. Zo niet, dan kun je vaak alsnog een generieke API-stap gebruiken.
3. Maak een aparte API-sleutel aan in elk systeem, met alleen de rechten die deze koppeling nodig heeft.
4. Test met één record in de testomgeving, niet met een echte klantorder.
5. Zet een meldingsmail aan bij mislukte stappen, zodat je stille fouten opmerkt.
6. Documenteer op één A4 wat de koppeling doet, wie de sleutels beheert en wat je moet doen als het stopt.

Een eigen API laten maken doe je in drie situaties: je hebt eigen software waar anderen op moeten aansluiten, je wil je gegevens ontsluiten voor je eigen app of portaal, of je verkoopt data als dienst. Voor de eerste twee gevallen is een platform waarbij de API automatisch meekomt met je database vaak het snelste pad. Vraag altijd om documentatie én een sandbox als onderdeel van de oplevering, niet als extra.

Veelgemaakte fout: een koppeling laten bouwen zonder dat iemand in je eigen organisatie begrijpt wat ze doet. Als de bouwer verdwijnt, is de koppeling een zwarte doos. Eis één pagina uitleg in gewone taal, plus een lijst van alle sleutels en waar ze staan.

Hoe test je een API voordat je er echt op vertrouwt?

Je test een API altijd eerst in een sandbox met nepgegevens, dan met één echt record, dan met een dag echte volumes. Pas daarna zet je het handwerk stop. Wie die tussenstappen overslaat, ontdekt de fouten op het moment dat ze het duurst zijn.

Een testchecklist die je zelf kunt aflopen, zonder technische kennis:

• Werkt de koppeling met verkeerde invoer? Vraag om een test met een ontbrekend btw-nummer of een rare tekenset.
• Wat gebeurt er bij dubbel verzenden? Krijgt de klant dan twee facturen, of herkent het systeem het duplicaat?
• Wat gebeurt er bij een storing aan de andere kant? Wordt het opnieuw geprobeerd, en hoe vaak?
• Word je gewaarschuwd bij mislukking, of loopt het stil door?
• Loop je tegen de rate limit aan bij een piekdag? Laat een piek van drie keer je gemiddelde volume nabootsen.
• Klopt de vertaling van velden? Laat tien records handmatig naast elkaar leggen, veld per veld.

Laat de leverancier de resultaten schriftelijk vastleggen. Een testverslag van één pagina is bij een dispuut later goud waard.

Veilig werken met API’s: wat moet je zeker afspreken?

De vier risico’s die kmo’s het hardst raken staan in de OWASP API Security Top 10 uit 2023. Kort samengevat: iemand kan gegevens van een andere klant opvragen, inloggen zonder recht, je kosten laten ontploffen, of via een vergeten koppeling binnenkomen. Alle vier zijn met simpele afspraken sterk te beperken.

De vier punten, vertaald naar wat het voor jouw bedrijf betekent:

• API1:2023 Broken Object Level Authorization. Iemand verandert één nummer in het verzoek en ziet de gegevens van een andere klant. Voor een kmo: een klant die per ongeluk de factuur van zijn concurrent ziet. Vraag expliciet of er per verzoek gecontroleerd wordt of deze gebruiker dit specifieke record mag zien.
• API2:2023 Broken Authentication. De controle op wie je bent is te zwak of te makkelijk te omzeilen. Voor een kmo: een uitgelekte sleutel geeft volledige toegang. Vraag hoe lang sleutels geldig blijven en of tweefactor mogelijk is op het beheerderaccount.
• API4:2023 Unrestricted Resource Consumption. Geen limiet, dus een fout of aanval kan je systeem platleggen of je rekening laten ontploffen. Voor een kmo: een script in een lus dat in één nacht duizenden betaalde verzoeken afvuurt. Vraag om een harde limiet én een waarschuwing per e-mail.
• API9:2023 Improper Inventory Management. Vergeten oude koppelingen die nog openstaan. Voor een kmo: de sleutel van dat marketingbureau van drie jaar terug werkt nog steeds. Houd een lijst bij van elke koppeling en elke sleutel.

De volledige lijst staat op de OWASP API Security Top 10 uit 2023.

Praktische regels die niets kosten:

• Stuur sleutels nooit via e-mail of WhatsApp. Gebruik een wachtwoordmanager met deelfunctie.
• Eén aparte sleutel per koppeling, zodat je er één kunt intrekken zonder de rest te breken.
• Roteer sleutels op een vast moment, bijvoorbeeld jaarlijks bij je verzekeringsevaluatie.
• Geef alleen leesrechten als er niets weggeschreven hoeft te worden.
• Test altijd eerst in de sandbox, nooit rechtstreeks op je echte administratie.
• Houd een logboek bij: wie vroeg wat, wanneer.
• Trek sleutels onmiddellijk in wanneer een leverancier of medewerker vertrekt.

En de AVG. Een koppeling verplaatst persoonsgegevens naar een andere partij, en die partij is dan verwerker. Dat betekent drie dingen: je hebt een verwerkersovereenkomst nodig, je neemt de koppeling op in je verwerkingsregister, en je controleert waar de servers staan. Deel bovendien nooit meer velden dan nodig. Als de koppeling alleen een naam en een e-mailadres nodig heeft, stuur dan geen geboortedatum mee. Dat is dataminimalisatie, en het is meteen je goedkoopste beveiligingsmaatregel.

AI en API’s: waarom een limiet geen luxe is

AI-tools praten met je eigen systemen via API’s, en bij vrijwel elke aanbieder betaal je per verzoek of per verwerkte hoeveelheid tekst. Dat maakt een harde limiet en een waarschuwing bij overschrijding geen extraatje, maar een basisvoorwaarde voordat je live gaat.

Hoe dat er in de praktijk uitziet: je laat een AI-model inkomende e-mails samenvatten en in je CRM zetten. Er zitten dan minstens drie API’s in het spel, die van je mailbox, die van het AI-model, en die van je CRM. Loopt er iets in een lus, dan tikt de teller van het AI-model door zonder dat iemand het merkt. Dat is precies risico API4:2023 uit de OWASP-lijst, maar nu met een factuur eraan vast.

Wat je daarom vooraf regelt:

• Een maandelijkse bestedingslimiet bij de AI-aanbieder, plus een e-mailwaarschuwing op bijvoorbeeld 50 en 80 procent.
• Een test met honderd berichten voordat je duizenden berichten aanzet.
• Een aparte sleutel per automatisering, zodat je één ding kunt uitzetten zonder alles stil te leggen.
• Een afspraak over wat er met je gegevens gebeurt: worden ze gebruikt om modellen te trainen, en waar staan de servers? Dit is een AVG-vraag, niet een technische vraag.

Voor het aan elkaar knopen gebruiken de meeste kmo’s een automatiseringstool. Wie zelf wil hosten en de gegevens in eigen beheer wil houden, kijkt naar n8n. Wie het liefst zo min mogelijk instelt, komt bij Zapier terecht. Onze bevindingen per platform staan in onze toolcatalogus.

De acht vragen die je aan je softwareleverancier stelt

Stel deze acht vragen vóór je een contract ondertekent, niet nadat de koppeling stilvalt. Ze kosten je tien minuten en ze onthullen in één gesprek of een pakket echt open is of alleen in de brochure.

1. Heeft dit pakket een open API, of moet ik per koppeling betalen? Vraag naar de prijsstructuur: vast, per bevraging, of per koppelpartner.
2. Is er publieke documentatie en een gratis testomgeving? Als je die niet zonder verkoopgesprek kunt inzien, weet je al iets.
3. Wat gebeurt er bij een storing? Wie merkt het eerst, hoe word ik verwittigd, en hoe snel reageer je? Vraag naar de afspraken op papier.
4. Hoe word ik gewaarschuwd bij wijzigingen aan de API? Hoeveel maanden aankondiging bij een breaking change, en hoe lang blijft de oude versie werken?
5. Wat zijn de limieten? Hoeveel verzoeken per minuut en per dag, en wat gebeurt er precies als ik daarboven kom?
6. Wie is eigenaar van de gegevens? Laat dit letterlijk in het contract staan.
7. Kan ik mijn gegevens er weer volledig uit halen als ik vertrek? In welk formaat, binnen welke termijn, en tegen welke kost? Dit is je exit en dus je onderhandelingspositie.
8. Welke verwerkersovereenkomst hoort erbij, en waar staan de servers? Vraag naar de subverwerkers, want die staan er niet altijd spontaan bij.

Een leverancier die op vraag 7 begint te aarzelen, vertelt je meer over de komende vijf jaar dan zijn hele demo.

Conclusie: wat doe je nu?

Wat is een API? Een afspraak tussen twee programma’s, niets meer en niets minder. Maar die afspraak bepaalt of je gegevens vrij kunnen bewegen of vastzitten in één pakket. In België is dat sinds 1 januari 2026 geen theorie meer: zonder werkende Peppol-koppeling kun je je B2B-facturen niet meer wettelijk uitwisselen. In Nederland zijn de verplichtingen anders, maar de logica is dezelfde.

Drie concrete stappen voor deze week:

1. Maak een lijst van elke bestaande koppeling en elke API-sleutel die in je bedrijf actief is, met wie hem beheert. Dat dekt meteen risico API9:2023 af.
2. Kies één proces waar iemand structureel overtypt en reken met de keuzehulp hierboven uit of een koppeling zich binnen achttien maanden terugverdient.
3. Leg de acht vragen op tafel bij je huidige softwareleverancier. Je hoeft niets te kopen om te weten of je vastzit.

Wil je weten waar in jouw bedrijf een koppeling of een AI-automatisering het snelst tijd en geld bespaart, doe dan de gratis AI-scan. Ben je al een stap verder en zoek je concrete software, dan vind je de tools die we onafhankelijk onderzochten en vergeleken in onze toolcatalogus, telkens met de voor- en nadelen op een rij.

Bronnen

• OWASP API Security Top 10, editie 2023, geraadpleegd 6 augustus 2026
• KVK Developer Portal, API’s en testomgeving, geraadpleegd 6 augustus 2026
• Digitale Overheid, voortgang digitaal zakendoen, geraadpleegd 6 augustus 2026
• OpenPeppol, over het Peppol-netwerk, geraadpleegd 6 augustus 2026