Een PDF-generatie-API kiezen lijkt eenvoudig totdat u begint. Er zijn ongeveer 40 aanbieders, de marketingpagina’s klinken allemaal vergelijkbaar en de echte afwegingen worden vaak pas duidelijk na een paar duizend documenten in productie.

Dit is een checklist die u kunt meenemen naar een leverancierevaluatie: leveranciersneutraal en gebaseerd op incidenten die teams werkelijk tegenkomen tijdens inkooptrajecten en post-mortems. Acht vragen; als u op één ervan geen duidelijk antwoord krijgt, hebt u nog niet genoeg informatie om te kiezen.

1. Wat is het invoerformaat: HTML, JSON of een template-DSL?

Dit is de belangrijkste vraag. Het antwoord bepaalt wat uw team gaat schrijven en wat het om 02:00 uur moet debuggen.

HTML/CSS (Puppeteer, DocRaptor, Prince): vertrouwd, onbeperkt flexibel, duur tijdens runtime en lastig deterministisch te maken.
JSON / gestructureerde data (gPdf): goedkoop te renderen, byte-identiek, maar vereist een kleine mapper van uw datamodel naar het documentmodel.
Template-DSL (PDFKit, ReportLab, Apache PDFBox): volledige controle en volledige verantwoordelijkheid; u schrijft zelf paginering, layout en fontfallback.

Er is geen verkeerd antwoord in absolute zin. Er is wel een verkeerd antwoord voor uw team. Vraag uw engineers in welk model zij liever een pagineringsbug van drie uur debuggen.

2. Wat is de cold-startlatency en is die voorspelbaar?

Sommige render-engines starten in microseconden (WASM of native binary). Andere starten in seconden (Chromium-gebaseerd). Het verschil is onzichtbaar totdat u een verkeerspiek krijgt.

Vragen voor de leverancier:

“Wat is uw p99-latency voor de eerste request naar een koude worker?”
“Hoe lang na mijn laatste request wordt een worker weer koud?”
“Publiceert u een statuspagina met cold-startdata?”

Als de leverancier de eerste vraag niet met een getal kan beantwoorden, ga er dan van uit dat het slecht is.

3. Hoe wordt de kostprijs per render berekend?

Drie varianten, in volgorde van hoe vaak ze teams later raken:

Prijs per pagina (Anvil met $0.10/PDF, DocRaptor met$ 89/100K): voorspelbaar, makkelijk te budgetteren, duur op schaal.
Abonnementslagen met overage (gPdf met $5-12/maand + 0,00005 USD per pagina boven de inbegrepen bundel): goedkoop op elk volume, maar moeilijker te voorspellen voor gebruik dat u nog niet hebt getest.
Compute-gebaseerde prijs (zelf gehoste Puppeteer op Lambda): u betaalt de compute-rekening direct, inclusief cold starts en Chromium-geheugen.

Bereken uw werkelijke rekening op drie verkeersniveaus (huidig, 5×, 50×) voordat u tekent. De vorm van de kostencurve is belangrijker dan het headlinebedrag.

4. Is de output deterministisch?

Determinisme, dezelfde invoer levert dezelfde bytes op, klinkt academisch totdat u het nodig hebt.

U hebt het nodig wanneer:

U PDF’s in CI diff’t om ongewenste templatewijzigingen te vinden.
U documenten bewaart onder e-factuur- of belastingwetgeving; de PDF die u opslaat en de PDF die u opnieuw rendert moeten overeenkomen.
U de PDF hasht voor archiefintegriteit.
U de gerenderde output onder versiebeheer zet voor juridische review.

Browsergebaseerde render-engines (Puppeteer, alles rond Chromium) zijn NIET deterministisch over patchversies heen. Native binary render-engines (Prince, gPdf) zijn dat meestal wel. Vraag expliciet: “Veranderen mijn outputbytes als u een update van de render-engine uitrolt?”

5. Hoe gaat de render-engine om met fonts, vooral CJK en RTL?

Dit is de vraag die in PDF-land meer carrières schade heeft toegebracht dan bijna elke andere.

De foutmodus is herkenbaar: u lanceert in uw thuismarkt, fonts zijn prima. Zes maanden later breidt u uit naar een markt met een schrift waarvoor de render-engine geen glyphs heeft. De PDF begint ▢▢▢▢-blokjes uit te spugen. De klant escaleert. Uw team besteedt twee sprints aan fonts toevoegen aan een Dockerfile.

Vragen die u moet stellen:

“Welke scripts zijn zonder extra configuratie ingebouwd? Latin, CJK, Cyrillisch, Devanagari, Arabisch, Hebreeuws?”
“Wat gebeurt er bij een onbekende glyph: fallback of tofu?”
“Kan ik custom fonts op requesttijd toevoegen, of moet ik ze vooraf deployen?”
“Ondersteunt u RTL text shaping?”

Een goed antwoord: “We embedden NotoSans CJK en een Noto-fallbackset; onbekende glyphs vallen terug naar Noto Symbols.” Een slecht antwoord: “Ja hoor, we ondersteunen fonts.”

6. Welke nalevingsprofielen worden ondersteund?

Als uw bedrijf ooit mogelijk:

facturen in de EU uitgeeft (Factur-X / ZUGFeRD / EN 16931, verplicht in DE/FR/IT/PL vanaf 2026),
documenten bewaart onder SOX-, HIPAA- of GDPR-retentieregels (PDF/A),
medische dossiers indient (PDF/A-3 met gekoppelde XML),
digitale handtekeningen embedt (PAdES),

vraag dan welke profielen de render-engine native ondersteunt. Het slechte antwoord is: “u kunt achteraf nog een andere tool draaien om te converteren”. Dat is een meerstapspijplijn die uw team nu beheert.

Goede antwoorden zien er meestal uit als één flag. gPdf accepteert bijvoorbeeld settings.profile: "pdfa-3b" plus een settings.e_invoice block met standard: "factur_x" en ingesloten CII XML. Ingebouwd is operationeel veel lichter dan achteraf aangebouwd.

7. Is rendering stateless? Waar gaan mijn documenten heen nadat ze zijn gerenderd?

Dit zijn twee samenhangende vragen.

Stateless rendering betekent dat de request binnenkomt, de PDF wordt uitgegeven en niets wordt opgeslagen. U regelt persistentie zelf (S3, uw database, wat bij uw systeem past). Dit wilt u voor werklasten met zware privacy- of nalevingseisen: de renderlaag wordt nooit beheerder van uw data.

Stateful rendering betekent dat de leverancier de PDF opslaat, vaak op een CDN, en u een signed URL geeft. Handig voor lichte processen, bijvoorbeeld “stuur de klant een link”, maar lastig voor gereguleerde processen: er is nu een derde partij met een kopie van elk document dat u ooit hebt gerenderd.

Vraag:

“Is rendering standaard stateless?”
“Waar wordt het document geografisch opgeslagen als u het opslaat?”
“Hoe lang wordt het bewaard?”
“Kan ik een schriftelijke garantie krijgen van stateless rendering voor een nalevingsreview?”

Als het antwoord vaag is, maakt uw privacy- of legalteam hier over negen maanden een probleem van.

8. Wat gebeurt er wanneer de render-engine faalt, en hoe kom ik dat te weten?

Elke render-engine faalt soms. De vragen zijn:

Hoe wordt een fout zichtbaar? Een 500 met stacktrace? Een 4xx met een gestructureerde fout? Een lege PDF?
Wat is het retrybeleid? Is het idempotent? Wordt u gefactureerd voor mislukte renders?
Welke instrumentatie biedt de leverancier? Een statuspagina? Webhooks voor incidenten? p50/p99-dashboards per regio?
Is er een synthetische probe? Draait de leverancier eigen monitoring tegen de publieke API-route, of wacht hij totdat u een ticket opent?

Een snelle test: bezoek nu de statuspagina van de leverancier. Als die niet bestaat, niet realtime is of alleen “all systems operational” toont zonder detail, dan is dat het niveau van betrouwbaarheidstransparantie dat u na aankoop krijgt.

Ter referentie: gPdf publiceert /status met synthetische probe-data plus Cloudflare Analytics over de laatste 7 dagen.

Hoe gPdf scoort op de acht vragen

Omdat dit onze blog is en u zult vermoeden dat we de vragen hebben gekanteld, staat hier onze eerlijke scorecard:

#	Vraag	gPdf-antwoord
1	Invoerformaat	JSON `DocumentRequest` (gestructureerde data)
2	Cold start	5-20 ms (V8 isolate, geen browser)
3	Kostenmodel	$0/$ 5/ $8/$ 12 per maand; 0,00005 USD per pagina overage
4	Determinisme	Byte-identiek, gegarandeerd binnen dezelfde engineversie
5	Fonts	NotoSans CJK + Latin-fallback ingebouwd
6	Naleving	PDF/A-1b/2b/3b/4 + Factur-X / ZUGFeRD-bijlage ingebouwd
7	Stateless	Ja, contractueel: nergens documentopslag
8	Fouten en zichtbaarheid	Publieke statuspagina met 7-daagse trend; gestructureerde 4xx/5xx; idempotent

Waar we verliezen: Q1, als uw invoer echt HTML is die u niet kunt refactoren, bijvoorbeeld door gebruikers gegenereerde rapporten of legacy templates. Dan zijn DocRaptor of Prince het juiste antwoord.

TL;DR

Vraag niet “wat is de beste PDF-API”. Stel de acht vragen, scoor de antwoorden en kies de leverancier die past bij uw echte werklast. Het team dat een inkooptraject verloor aan een iets goedkopere rivaal en negen maanden later door vraag 5 werd verrast, zal hetzelfde zeggen.

Als uw werklast toevallig aansluit bij de manier waarop gPdf is gebouwd, kost evalueren in de Playground 30 seconden. Als dat niet zo is, wijzen we u zonder omweg naar de juiste tool: meestal DocRaptor voor HTML-vormige problemen, Prince voor self-hosted, of Puppeteer wanneer uw invoer echt uit willekeurige webpagina’s bestaat.