07 okt 2026 API testen: zo bewaak je je businesslogica, niet alleen je endpoints

In het kort: Bij API testen test je de laag waarmee systemen met elkaar praten, zonder via het scherm te gaan. Het is de snelste en stabielste plek om bedrijfsregels en koppelingen te testen. Test regels en berekeningen op API-niveau, test in de UI wat de gebruiker ziet, en houd daarboven een paar end-to-end-scenario’s.

Bijna elk team dat we spreken heeft API-tests. Veel minder teams gebruiken ze waar ze het sterkst in zijn. De API-tests controleren of een endpoint antwoordt. De bedrijfsregels worden via het scherm getest: kortingen, kredietlimieten, de status van een order. Die UI-tests zijn traag en gaan stuk zodra er een knop verschuift. Terwijl het meeste wat in een release misgaat, tussen systemen gebeurt en niet op het scherm. Met API testen bewaak je precies dat deel.

Wat is API testen?

Bij API testen stuur je verzoeken rechtstreeks naar de API van een applicatie en controleer je de antwoorden. Een API (application programming interface) is de set afspraken waarmee systemen berichten uitwisselen. Je webwinkel vraagt het voorraadsysteem hoeveel stuks er nog zijn. Je CRM stuurt een nieuwe klant door naar de financiële administratie. Een API-test slaat het scherm over en voert dat gesprek zelf. Hij stuurt bijvoorbeeld “maak een order aan voor klant 123 met deze vijf producten”. Daarna controleert hij het antwoord: de juiste status, de juiste velden, de juiste bedragen, en een duidelijke foutmelding bij verkeerde invoer. Omdat er geen browser bij komt kijken, draaien API-tests in seconden in plaats van minuten. Ze gaan ook minder vaak stuk, omdat ze niet afhangen van de opmaak van een pagina. IBM zet de gebruikelijke soorten op een rij, van functionele tests tot performance en beveiliging.

Wat test je op API-niveau en wat in de UI?

Die keuze maken de meeste teams nooit bewust. Ze kiezen eerst een tool en schrijven daarna de tests waar die tool goed in is. Bij klanten zien we vaak API-tests en UI-tests naast elkaar, zonder plan voor welke laag wat controleert. Op sommige plekken wordt dan dubbel getest, op andere plekken niet. Een eenvoudige vuistregel helpt.

De UI-test hoeft dan alleen te controleren of het scherm de uitkomst goed toont. Twintig varianten van de regel zelf horen daar niet. Zo blijft je UI-testset klein, en dat is belangrijk: UI-tests zijn het trage en kwetsbare deel. In onze vergelijking van Playwright en Selenium lees je meer over die UI-laag.

Hoe test je businesslogica via een API?

Neem één bedrijfsregel en test de randen, niet alleen het pad waarop alles goed gaat. Stel, de regel is: orders boven €10.000 moeten door een manager worden goedgekeurd. Goede API-tests voor die regel zien er zo uit:

1. Net onder de grens. Een order van €9.999,99 gaat direct door, met de status “bevestigd”.
2. Precies op de grens. €10.000,00. Betekent “boven” dat dit bedrag goedkeuring nodig heeft of niet? Hier zitten de bugs, en vaak moet de business hier zelf nog een keuze maken.
3. Net boven de grens. €10.000,01 krijgt de status “wacht op goedkeuring” en de juiste goedkeurder.
4. Foute invoer. Een negatief bedrag of een ontbrekende klant geeft een duidelijke foutmelding, geen vastgelopen server.
5. Het vervolg. Na goedkeuring via de API verandert de status en gaat de order door naar het volgende systeem.

Elke test zet eerst zijn eigen data klaar, zoals een klant en producten met vaste prijzen. Dan hangt de uitkomst niet af van wat er toevallig in de testomgeving staat. Vijf kleine tests als deze draaien in een paar seconden. Via het scherm kosten dezelfde controles minuten, en ze breken zodra de orderpagina verandert. Dit is het deel dat onze consultants het vaakst onderbenut zien. Er zijn wel API-tests, maar die controleren of het endpoint antwoordt, niet of de logica erachter klopt.

Hoe houd je koppelingen in je regressietest?

Een nieuwe koppeling wordt meestal één keer zorgvuldig getest, op het moment dat hij live gaat. Daarna verdwijnt hij uit beeld. Een halfjaar later past iemand aan één kant een veld aan, en krijgt het andere systeem ongemerkt verkeerde data. Bij klanten zien we het vaak: nieuwe koppelingen worden één keer gevalideerd en komen nooit in de regressie- of sanitytests terecht. Drie gewoontes voorkomen dat.

• Elke nieuwe koppeling krijgt minstens één geautomatiseerde API-test in de nachtelijke run, op de dag dat hij live gaat.
• Test de afspraak, niet alleen de verbinding. Controleer of velden, formaten en statussen zijn wat de andere kant verwacht. Dat heet contract testing. Met tools als Pact leggen beide kanten vast wat ze van elkaar verwachten, en je krijgt een waarschuwing zodra een van beide die afspraak breekt.
• Gebruik een vervanger waar het andere systeem er niet toe doet. Een nagebootste externe dienst die altijd hetzelfde antwoordt, houdt je tests stabiel. Houd een paar tests tegen de echte koppeling, zodat je merkt als die verandert.

Zo blijven koppelingen onderdeel van je regressietest, in plaats van een eenmalige controle op de dag van livegang.

Welke API-tests en tools heb je nodig?

De meeste teams hebben eerst drie soorten nodig: functionele tests voor bedrijfsregels, contracttests voor koppelingen en tests op foute invoer. Performance- en beveiligingstests volgen zodra de basis elke nacht draait. Kies je tools vanuit je team en je architectuur, niet vanuit een lijstje. Postman is laagdrempelig en prima om een API te verkennen. REST Assured en Karate passen bij teams die tests als code naast de applicatie willen. Pact is gemaakt voor contract testing. Belangrijker dan de tool zijn twee vragen: wie onderhoudt deze tests, en draaien ze automatisch bij elke release? Vaak zien we dat tools zonder onderbouwde keuze zijn gekozen. Zo eindigen teams met drie tools en geen strategie.

Wat betekent dit voor je team?

Pak je vijf belangrijkste bedrijfsregels. Kijk per regel waar hij vandaag getest wordt: op API-niveau, in de UI, of alleen met de hand voor een release. Verplaats de controles van de regel naar de API, houd de UI-tests voor wat de gebruiker ziet, en zet elke koppeling in de nachtelijke run. Zo krijg je een compacte testset die meer risico afdekt in minder tijd.

Die testset opzetten is het makkelijke deel. Hem bij elke release bijwerken, ook als er een koppeling bijkomt, is het werk dat meestal blijft liggen. Daar helpen we teams bij. Met Test Automation as a Service bouwen en draaien we je geautomatiseerde regressietests samen met je team, van API-tests tot de paar end-to-end-scenario’s daarboven. We halen tot 70% van het handmatige regressietesten weg, voor teams die hun regressietests nog met de hand doen. Je tests draaien elke nacht, en wij houden ze betrouwbaar. Je krijgt een stabiele testset waar je team op kan vertrouwen, die niet van één persoon afhangt en je team geen extra werk geeft. Wil je eerst de teststrategie op orde? Dan beginnen onze testers daar samen met je.

Veelgestelde vragen

Kun je API’s testen zonder te programmeren?

Om te beginnen wel. Met tools als Postman stuur je verzoeken en controleer je antwoorden zonder veel code. Wil je de tests elke nacht automatisch draaien en onderhoudbaar houden, dan helpt wat scriptwerk. De meeste API-testcode is kort en goed leesbaar.

Wat is het verschil tussen API testen en UI testen?

Bij API testen controleer je de berichten tussen systemen, zonder scherm. Bij UI testen controleer je wat de gebruiker in de browser of app ziet en doet. API-tests zijn sneller en stabieler. UI-tests zitten dichter op de echte gebruikerservaring. Je hebt ze allebei nodig, voor verschillende dingen.

Wat is contract testing?

Met contract testing controleer je of twee systemen het nog eens zijn over hoe ze met elkaar praten. Beide kanten leggen vast wat ze sturen en verwachten. Een test waarschuwt zodra een wijziging die afspraak breekt. Zo vind je koppelingsproblemen voor de release in plaats van in productie.

Is Postman genoeg om API’s te testen?

Om een API te verkennen en voor eenvoudige controles vaak wel. Voor een grote testset die elke nacht in je pipeline draait, stappen veel teams over op tests als code. Anderen draaien hun Postman-collecties vanaf de commandoregel. Het belangrijkste is dat de tests automatisch draaien en dat iemand ze onderhoudt.