Contracttesten voor API's: voorkom brekende wijzigingen in snelle teams

Waarom brekende API-wijzigingen toch in releases sluipen

De meeste teams eindigen met één API die veel clients bedient: een webapp, een iOS-app, een Android-app en soms ook interne tooling. Zelfs als iedereen het eens is over dezelfde endpoints, gebruikt elke client de API op net iets andere manieren. Het ene scherm verwacht bijvoorbeeld altijd een veld, terwijl een ander het alleen gebruikt als een filter aanstaat.

Het echte probleem ontstaat wanneer deze onderdelen op verschillende momenten worden uitgebracht. Backend-wijzigingen kunnen meerdere keren per dag live gaan, web kan snel deployen en mobiele releases lopen trager door reviewcycli en gefaseerde uitrol. Die kloof veroorzaakt onverwachte breuken: de API is aangepast voor de nieuwste client, maar de mobiele build van gisteren zit nog in de markt en krijgt nu antwoorden die hij niet kan verwerken.

Wanneer dit gebeurt, zijn de symptomen zelden subtiel:

• Een scherm dat plots leeg wordt omdat een veld is hernoemd of verplaatst
• Crashes veroorzaakt door onverwachte nulls of ontbrekende objecten
• "Er is iets kapot" supporttickets met moeilijk reproduceerbare stappen
• Een piek in error logs direct na een backend-deploy
• Hotfix-releases die defensieve code toevoegen in plaats van de kernoorzaak op te lossen

Handmatig testen en QA missen deze problemen vaak omdat de risicovolle gevallen niet op het pad van de gelukkige flow liggen. Een tester controleert misschien of "Create order" werkt, maar probeert geen oudere appversie, een gedeeltelijk ingevuld profiel, een zeldzame gebruikersrol of een antwoord waarbij een lijst leeg is. Voeg caching, feature flags en geleidelijke uitrol toe, en je krijgt nog meer combinaties dan een testplan kan dekken.

Een typisch voorbeeld: de backend vervangt status: "approved" door status: { code: "approved" } om lokalisatie te ondersteunen. De webapp is dezelfde dag bijgewerkt en werkt prima. Maar de huidige iOS-release verwacht nog een string, kan het antwoord niet parsen en gebruikers zien na inloggen een blanco pagina.

Daarom bestaan contracttesten voor API's: niet om QA te vervangen, maar om deze "werkt alleen voor mijn nieuwste client"-wijzigingen op te sporen voordat ze productie bereiken.

Wat contracttesten zijn (en wat niet)

Contracttesten is een manier voor een API-consument (een webapp, een mobiele app of een andere service) en een API-provider (je backend) om overeenstemming te bereiken over hoe ze met elkaar praten. Die overeenkomst is het contract. Een contracttest controleert één eenvoudige vraag: gedraagt de provider zich nog steeds zoals de consument erop vertrouwt, ook na wijzigingen?

In de praktijk zitten contracttesten voor API's tussen unittests en end-to-end tests in. Unittests zijn snel en lokaal, maar ze kunnen mismatches tussen teams missen omdat ze interne code testen, niet de gedeelde grens. End-to-end tests oefenen echte flows over veel systemen, maar ze zijn trager, lastiger te onderhouden en falen vaak om redenen die niets met een API-wijziging te maken hebben (testdata, UI-timing, flakey omgevingen).

Een contract is geen enorm document. Het is een gefocuste beschrijving van de requests die een consument zal sturen en de responses die die moet ontvangen. Een goed contract bevat meestal:

• Endpoints en methoden (bijvoorbeeld POST /orders)
• Vereiste en optionele velden, inclusief types en basisregels
• Statuscodes en de vorm van foutresponses (hoe ziet een 400 eruit vs 404)
• Headers en authenticatieverwachtingen (token aanwezig, content-type)
• Belangrijke defaults en compatibiliteitsregels (wat gebeurt er als een veld ontbreekt)

Hier is een eenvoudig voorbeeld van het soort breuk dat een contracttest vroegtijdig opvangt: de backend hernoemt total_price naar totalPrice. Unittests kunnen nog steeds slagen. End-to-end tests dekken dat scherm misschien niet of falen later op een verwarrende manier. Een contracttest faalt meteen en wijst op de exacte mismatch.

Het helpt om duidelijk te zijn over wat contracttesten niet zijn. Ze vervangen geen performance-, security- of volledige gebruikersreis-tests. Ze vangen ook niet elke logische bug. Wat ze wel doen is het belangrijkste releaserisico in snelle teams verminderen: een "kleine" API-wijziging die stilletjes een client breekt.

Als je backend gegenereerd wordt of vaak verandert (bijvoorbeeld bij het regenereren van APIs in een platform als AppMaster), zijn contracttests een praktisch vangnet omdat ze verifiëren dat klantexpectaties nog steeds gelden na elke wijziging.

Kies een contractbenadering voor web- en mobileteams

Wanneer web en mobiel vaak uitbrengen, is het lastige niet "de API testen". Het lastige is overeenkomen wat niet mag veranderen voor elke client. Daar helpen contracttesten bij, maar je moet wel kiezen wie het contract beheert.

Optie 1: Consumentgestuurde contracten (CDCs)

Bij consumentgestuurde contracten definieert elke client (webapp, iOS, Android, partnerintegratie) wat hij nodig heeft van de API. De provider bewijst vervolgens dat hij aan die verwachtingen kan voldoen.

Dit werkt goed wanneer clients onafhankelijk bewegen, omdat het contract reëel gebruik weerspiegelt, niet wat het backendteam denkt dat gebruikt wordt. Het past ook bij de multi-client realiteit: iOS kan afhankelijk zijn van een veld dat web niet gebruikt, en web kan geven om sorteervolgorde of paginatieregels die mobiel negeert.

Een eenvoudig voorbeeld: de mobiele app vertrouwt erop dat price_cents een integer is. Web toont alleen de geformatteerde prijs, dus het zou niet merken als de backend het naar een string verandert. Een CDC van mobile zou die wijziging vangen vóór release.

Optie 2: Door-provider beheerde schema's

Bij een provider-eigendomsschema publiceert het backendteam één contract (vaak een schema of spec) en handhaaft dit. Consumenten testen tegen die ene bron van waarheid.

Dit is een goede match wanneer de API publiek is of gedeeld wordt met veel consumers die je niet bestuurt, of wanneer je strikte consistentie tussen teams nodig hebt. Het is ook eenvoudiger om mee te beginnen: één contract, één plaats om wijzigingen te reviewen, één goedkeuringspad.

Hier is een snelle keuzehulp:

• Kies CDCs wanneer clients vaak uitbrengen en verschillende delen van de API gebruiken.
• Kies provider-eigendomsschema's wanneer je één stabiel "officieel" contract voor iedereen nodig hebt.
• Gebruik een hybride aanpak wanneer mogelijk: een provider-schema voor de basis, plus CDCs voor een paar hoog-risico endpoints.

Als je bouwt met een platform zoals AppMaster, geldt hetzelfde idee: behandel web- en native mobiele apps als aparte consumers. Zelfs wanneer ze dezelfde backend delen, vertrouwen ze zelden op precies dezelfde velden en regels.

Wat in een API-contract moet staan (zodat het echte breuken opvangt)

Een API-contract helpt alleen als het weerspiegelt waarop je web- en mobiele clients echt vertrouwen. Een fraai spec dat niemand gebruikt zal niet de wijziging vangen die productie breekt.

Begin met echt gebruik, niet met gissingen. Neem de meest voorkomende client-aanroepen (uit je appcode, API-gateway logs of een korte lijst van de teams) en zet die om in contractgevallen: het exacte pad, methode, headers, queryparams en de typische request-bodyvorm. Dit houdt het contract klein, relevant en lastig om over te ruziën.

Neem zowel succes- als foutresponses op. Teams testen contracten vaak op het happy path en vergeten dat clients ook op fouten vertrouwen: de statuscode, de foutvorm en zelfs stabiele foutcodes/berichten. Als een mobiele app een specifieke "email al in gebruik"-melding toont, moet een contract die 409-responsevorm vergrendelen zodat het niet plots een 400 met een ander body wordt.

Besteed extra aandacht aan de gebieden die het vaakst breken:

• Optionele velden vs verplichte velden: een veld verwijderen is doorgaans veiliger dan een optioneel veld verplicht maken.
• Nulls: sommige clients behandelen null anders dan "ontbrekend". Beslis wat je toestaat en houd het consistent.
• Enums: een nieuwe waarde toevoegen kan oudere clients breken die een gesloten lijst verwachten.
• Paginatie: spreek af over parameters en responsevelden (zoals cursor of nextPageToken) en houd die stabiel.
• Datum- en nummerformaten: maak ze expliciet (ISO-strings, integer cents, etc.).

Hoe het contract te representeren

Kies een formaat dat teams kunnen lezen en tooling kan valideren. Veelvoorkomende opties zijn JSON Schema, op voorbeelden gebaseerde contracten of getypte modellen gegenereerd uit een OpenAPI-spec. In de praktijk werken voorbeelden plus een schema-check goed: voorbeelden tonen echte payloads, terwijl schemaregels "veld hernoemd" of "type veranderd" fouten opvangen.

Een eenvoudige regel: als een wijziging een client-update zou forceren, moet het een contracttest laten falen. Die instelling houdt contracten gefocust op echte breuken, niet op theoretische perfectie.

Stapsgewijs: voeg contracttests toe aan je CI-pijplijn

Het doel van contracttesten voor API's is simpel: wanneer iemand de API verandert, moet je CI je vertellen of een web- of mobiele client zal breken voordat de wijziging wordt uitgebracht.

1) Begin met vastleggen waar clients echt op vertrouwen

Kies één endpoint en schrijf de verwachtingen op die in de praktijk belangrijk zijn: vereiste velden, veldtypes, toegestane waarden, statuscodes en veelvoorkomende foutresponses. Probeer niet meteen de hele API te beschrijven. Voor mobiele apps, neem ook verwachtingen van oudere appversies mee, omdat gebruikers niet meteen updaten.

Een praktische manier is een paar echte requests te pakken die clients vandaag doen (uit logs of testfixtures) en die omzetten in herhaalbare voorbeelden.

2) Zet de contracten waar teams ze onderhouden

Contracten falen wanneer ze in een vergeten map leven. Houd ze dicht bij de code die verandert:

• Als één team beide kanten beheert, bewaar contracten in het API-repo.
• Als verschillende teams web, mobiel en API bezitten, gebruik een gedeeld repo dat door de teams wordt beheerd, niet door één persoon.
• Behandel contractupdates als code: gereviewd, geversioneerd en besproken.

3) Voeg checks aan beide zijden in CI toe

Je wilt twee signalen:

• Provider-verificatie bij elke API-build: "Voldoet de API nog aan alle bekende contracten?"
• Consumentchecks bij elke client-build: "Is deze client nog compatibel met het laatst gepubliceerde contract?"

Dit vangt problemen vanuit beide richtingen. Als de API een responseveld verandert, faalt de API-pijplijn. Als een client een nieuw veld begint te verwachten, faalt de clientpijplijn totdat de API het ondersteunt.

4) Bepaal de fail-regel en handhaaf die

Wees expliciet over wat een merge of release blokkeert. Een veelgebruikte regel is: elke contract-brekende wijziging faalt CI en blokkeert het mergen naar de main-branch. Als je uitzonderingen nodig hebt, vereis dan een schriftelijke beslissing (bijvoorbeeld een gecoördineerde releasedatum).

Concreet voorbeeld: een backendwijziging hernoemt totalPrice naar total_amount. Provider-verificatie faalt onmiddellijk, dus het backendteam voegt het nieuwe veld toe terwijl het oude tijdelijk blijft bestaan, zodat zowel web als mobiel veilig kunnen blijven uitbrengen.

Versiebeheer en achterwaartse compatibiliteit zonder teams te vertragen

Snelle teams breken API's meestal door te veranderen wat bestaande clients al gebruiken. Een "brekende wijziging" is alles dat een eerder werkende request doet falen, of de response zo verandert dat de client het niet kan verwerken.

Hier zijn veelvoorkomende brekende wijzigingen (ook als het endpoint nog bestaat):

• Een responseveld verwijderen dat clients lezen
• Het type van een veld veranderen (zoals "total": "12" naar "total": 12)
• Een optioneel veld verplicht maken (of een nieuw verplicht requestveld toevoegen)
• Auth-regels veranderen (een publieke endpoint vereist nu een token)
• Statuscodes of foutvormen veranderen die clients parsen (200 naar 204, of een nieuw foutformaat)

De meeste teams kunnen versieverhogingen vermijden door veiligere alternatieven te kiezen. Als je meer data nodig hebt, voeg dan een nieuw veld toe in plaats van een bestaande te hernoemen. Heb je een beter endpoint nodig, voeg een nieuwe route toe en houd de oude werkend. Wil je validatie aanscherpen, accepteer zowel het oude als het nieuwe inputformaat een tijd, en handhaaf de nieuwe regels geleidelijk. Contracttesten helpen omdat ze je dwingen te bewijzen dat bestaande consumers nog steeds krijgen wat ze verwachten.

Deprecatie is het onderdeel dat snelheid hoog houdt zonder gebruikers te schaden. Webclients kunnen dagelijks updaten, maar mobiele apps lopen weken achter door reviewqueues en trage adoptie. Plan deprecatie op basis van echt clientgedrag, niet op hoop.

Een praktische deprecatiepolicy ziet er zo uit:

• Kondig de wijziging ruim van tevoren aan (release notes, intern kanaal, ticket)
• Houd het oude gedrag aan totdat gebruik onder een afgesproken drempel zakt
• Geef waarschuwingen in headers/logs wanneer het verouderde pad wordt gebruikt
• Stel een verwijderdatum pas vast nadat je bevestigt dat de meeste clients geüpdatet zijn
• Verwijder oud gedrag pas nadat contracttests aantonen dat geen actieve consument het nog nodig heeft

Gebruik expliciete versies alleen wanneer je een wijziging niet achterwaarts compatibel kunt maken (bijvoorbeeld een fundamentele verschuiving in resource-vorm of securitymodel). Versiebeheer brengt lange-termijnkosten met zich mee: je onderhoudt nu twee gedragingen, twee documentatiesets en meer randgevallen. Houd versies zeldzaam en doelgericht, en gebruik contracten om te zorgen dat beide versies eerlijk blijven zolang het oude nog nodig is.

Veelvoorkomende fouten bij contracttesten (en hoe ze te vermijden)

Contracttesten voor API's werken het beste wanneer ze echte verwachtingen controleren, niet een speelgoedversie van je systeem. De meeste mislukkingen komen door een paar voorspelbare patronen die teams een vals gevoel van veiligheid geven terwijl bugs toch in productie glippen.

Fout 1: contracten behandelen als "fancy mocks"

Over-mocken is de klassieke val: de contracttest slaagt omdat het providergedrag gemockt is om bij het contract te passen, niet omdat de echte service dat gedrag daadwerkelijk kan leveren. Bij deployment faalt de eerste echte call.

Een veiliger regel is simpel: contracten moeten geverifieerd worden tegen de draaiende provider (of een buildartifact dat zich hetzelfde gedraagt), met echte serialisatie, echte validatie en echte auth-regels.

Hier volgen fouten die vaak voorkomen, en de oplossing die meestal werkt:

• Providergedrag te veel mocken: verifieer contracten tegen een echte provider-build, niet tegen een gestubde service.
• Contracten te strikt maken: gebruik flexibele matching voor dingen als IDs, timestamps en arrays; vermijd het afdwingen van elk veld als consumers er niet op vertrouwen.
• Foutresponses negeren: test in elk geval de belangrijkste foutgevallen (401, 403, 404, 409, 422, 500) en de fout-bodyvorm die de client parseert.
• Geen duidelijke eigendom: wijs aan wie het contract bijwerkt wanneer requirements veranderen; maak het onderdeel van de "definition of done" voor API-wijzigingen.
• Mobiele realiteiten vergeten: test met langzamere netwerken en oudere appversies in gedachten, niet alleen de nieuwste build op snel Wi‑Fi.

Fout 2: fragiele contracten die onschuldige wijzigingen blokkeren

Als een contract faalt telkens wanneer je een nieuw optioneel veld toevoegt of JSON-keys herordent, leren ontwikkelaars de rode build te negeren. Dat ondermijnt het doel.

Streef naar "strikt waar het ertoe doet." Wees strikt over vereiste velden, types, enumwaarden en validatieregels. Wees flexibel over extra velden, volgorde en waarden die natuurlijk variëren.

Een klein voorbeeld: je backend verandert status van "active" | "paused" naar "active" | "paused" | "trial". Als een mobiele app onbekende waarden als crash behandelt, is dit een brekende wijziging. Het contract moet dit oppakken door te controleren hoe de client met onbekende enumwaarden omgaat, of door te eisen dat de provider alleen bekende waarden blijft teruggeven totdat alle clients de nieuwe waarde kunnen verwerken.

Mobiele clients verdienen extra aandacht omdat ze langer in het wild leven. Vraag voordat je een API-wijziging veilig noemt:

• Kunnen oudere appversies nog steeds de response parsen?
• Wat gebeurt er als een request na een timeout opnieuw wordt geprobeerd?
• Zal gecachte data botsen met het nieuwe formaat?
• Hebben we een fallback wanneer een veld ontbreekt?

Als je APIs gegenereerd of snel bijgewerkt worden (ook met platforms zoals AppMaster), zijn contracten praktische vangrails: ze laten je snel bewegen en tegelijk aantonen dat web en mobiel blijven werken na elke wijziging.

Snelle pre-ship checklist voor API-wijzigingen

Gebruik dit vlak voordat je een API-wijziging merge of releaset. Het is ontworpen om de kleine aanpassingen te vangen die de grootste branden veroorzaken wanneer web en mobiel vaak uitbrengen. Als je al contracttesten gebruikt, helpt deze lijst je te focussen op de breuken die contracten zouden moeten blokkeren.

De 5 vragen die je elke keer moet stellen

• Hebben we responsevelden toegevoegd, verwijderd of hernoemd die clients lezen (inclusief geneste velden)?
• Zijn statuscodes veranderd (200 vs 201, 400 vs 422, 404 vs 410), of is het foutbodyformaat gewijzigd?
• Zijn velden veranderd tussen verplicht en optioneel (inclusief "kan null zijn" vs "moet aanwezig zijn")?
• Zijn sortering, paginatie of standaardfilters veranderd (pagina-grootte, ordering, cursor-tokens, defaults)?
• Hebben contracttests gedraaid voor de provider en alle actieve consumenten (web, iOS, Android en interne tools)?

Een eenvoudig voorbeeld: je API gaf totalCount terug en een client gebruikt dat om "24 resultaten" te tonen. Je verwijdert het omdat "de lijst al items heeft". De backend crasht niet, maar de UI toont leeg of "0 resultaten" voor sommige gebruikers. Dat is een echte brekende wijziging, ook al geeft het endpoint nog 200 terug.

Als je "ja" op een van de items antwoordde

Doe deze korte vervolgstappen voordat je uitbrengt:

• Bevestig of oude clients nog werken zonder update. Zo niet, voeg een achterwaarts compatibel pad toe (houd het oude veld, of ondersteun beide formaten een tijdje).
• Controleer foutafhandeling in clients. Veel apps behandelen onbekende foutvormen als "Er is iets mis" en verbergen nuttige boodschappen.
• Draai consumentcontracttests voor elke vrijgegeven clientversie die je nog ondersteunt, niet alleen de nieuwste branch.

Als je interne tools snel bouwt (bijvoorbeeld een adminpaneel of supportdashboard), zorg dat die consumers ook zijn opgenomen. In AppMaster genereren teams vaak web- en mobiele apps van dezelfde backendmodellen, waardoor je gemakkelijk vergeet dat een kleine schemawijziging toch een gepubliceerde client kan breken als het contract niet in CI wordt gecontroleerd.

Voorbeeld: een brekende wijziging vangen voordat web en mobiel uitbrengen

Stel je een veelvoorkomende setup voor: het API-team deployt meerdere keren per dag, de webapp shipt dagelijks en de mobiele apps wekelijks (door app store reviews en gefaseerde uitrol). Iedereen beweegt snel, dus het echte risico is geen kwaaie opzet, maar kleine wijzigingen die onschuldig lijken.

Een supportticket vraagt om duidelijkere naamgeving in de user profile-response. Het API-team hernoemt een veld in GET /users/{id} van phone naar mobileNumber.

Die hernoeming lijkt netjes, maar is een brekende wijziging. De webclient kan een leeg telefoonveld weergeven op de profielpagina. Erger nog, de mobiele client kan crashen als hij phone als verplicht behandelt, of falen bij validatie bij het opslaan.

Met contracttesten voor API's wordt dit opgevangen vóórdat het gebruikers bereikt. Zo faalt het meestal, afhankelijk van hoe je checks runt:

• Provider-build faalt (API-kant): de API CI job verifieert de provider tegen opgeslagen consumentcontracten van web en mobiel. Hij ziet dat consumenten nog phone verwachten, maar de provider levert nu mobileNumber, dus de verificatie faalt en de deploy wordt geblokkeerd.
• Consument-build faalt (client-kant): het webteam werkt hun contract bij om mobileNumber te vereisen voordat de API het levert. Hun contracttest faalt omdat de provider dat veld nog niet levert.

In beide gevallen is de fout vroeg, luid en specifiek: het wijst naar het exacte endpoint en de exacte veldmismatch, in plaats van dat het later als "profielpagina kapot" opdook.

De oplossing is meestal eenvoudig: maak de wijziging additief, niet destructief. De API levert beide velden een tijdje:

• Voeg mobileNumber toe.
• Laat phone als alias bestaan (zelfde waarde).
• Markeer phone als deprecated in de contractnotities.
• Werk web en mobiel bij om mobileNumber te lezen.
• Verwijder phone pas nadat alle ondersteunde clientversies zijn gemigreerd.

Een realistische tijdlijn onder releasedruk kan er zo uitzien:

• Ma 10:00: API-team voegt mobileNumber toe en houdt phone. Provider-contracttests slagen.
• Ma 16:00: Web schakelt over naar mobileNumber en shipt.
• Do: Mobiel schakelt over naar mobileNumber en dient een release in.
• Volgende di: Mobiele release bereikt de meeste gebruikers.
• Volgende sprint: API verwijdert phone, en contracttests bevestigen dat geen ondersteunde consumer het nog nodig heeft.

Dit is de kernwaarde: contracttests veranderen "brekende-wijziging-roulette" in een gecontroleerde, getimede transitie.

Volgende stappen voor snelbewegende teams (inclusief no-code optie)

Als je wilt dat contracttesten voor API's echt breuken voorkomen (en niet alleen extra checks toevoegen), houd de rollout klein en maak eigenaarschap duidelijk. Het doel is simpel: vang brekende wijzigingen voordat ze web- en mobiele releases bereiken.

Begin met een lichte rollout. Kies de top 3 endpoints die het meeste pijn veroorzaken bij wijzigingen, meestal auth, user profile en een kernlijst-/zoek-endpoint. Leg die eerst onder contract, en breid uit zodra het team het proces vertrouwt.

Een praktisch rolloutplan dat beheersbaar blijft:

• Week 1: contracttests voor de top 3 endpoints, draaiend op elke pull request
• Week 2: voeg de volgende 5 endpoints met het meeste mobiel gebruik toe
• Week 3: dek foutresponses en randgevallen (lege staten, validatiefouten)
• Week 4: maak "contract green" een releasegate voor backend-wijzigingen

Bepaal daarna wie wat doet. Teams bewegen sneller als het duidelijk is wie een failure eigent en wie een wijziging goedkeurt.

Houd rollen simpel:

• Contract-eigenaar: meestal het backendteam, verantwoordelijk voor het bijwerken van contracten wanneer gedrag verandert
• Consumenten-reviewers: web- en mobile-leads die bevestigen dat wijzigingen veilig zijn voor hun clients
• Build-sheriff: roteert dagelijks of wekelijks, triageert contracttest-failures in CI
• Release-eigenaar: neemt de beslissing om een release te blokkeren als een contract is gebroken

Volg één succesmetric die iedereen belangrijk vindt. Voor veel teams is het beste signaal minder hotfixes na releases en minder "client regressions" zoals appcrashes, lege schermen of kapotte checkoutflows die aan API-wijzigingen te linken zijn.

Als je een nog snellere feedbacklus wilt, kunnen no-code platforms drift verminderen door schone code te regenereren na wijzigingen. Wanneer logica of datamodellen verschuiven, helpt regeneratie om te voorkomen dat oplapwerk zich ophoopt en per ongeluk gedrag verandert.

Als je APIs en clients met AppMaster bouwt, is een praktische volgende stap: probeer het door een applicatie aan te maken, je data in de Data Designer (PostgreSQL) te modelleren, workflows bij te werken in de Business Process Editor, en vervolgens te regenereren en te deployen naar je cloud (of de broncode te exporteren). Combineer dat met contractchecks in je CI zodat elke geregenerate build nog steeds aantoont dat hij overeenkomt met wat web en mobiel verwachten.