Een PDF API kiezen lijkt eenvoudig tot je begint. Er zijn veel aanbieders, marketingpagina’s klinken hetzelfde, en echte tradeoffs verschijnen pas na duizenden documenten in productie.
Deze checklist is bedoeld voor vendorevaluatie. Ze is neutraal en gebaseerd op echte problemen uit procurement, operatie en post-mortems. Zonder duidelijke antwoorden op alle acht vragen is kiezen te vroeg.
1. Wat is het inputformaat: HTML, JSON of template DSL?
Dit is de belangrijkste vraag. Ze bepaalt wat je team schrijft en debugt.
- HTML/CSS (Puppeteer, DocRaptor, Prince): vertrouwd, flexibel, runtime duur, lastig deterministisch.
- JSON / gestructureerde data (gPdf): goedkoop te renderen, byte-identical, maar vraagt een mapper naar het documentmodel.
- Template DSL (PDFKit, ReportLab, Apache PDFBox): volledige controle en volledige verantwoordelijkheid voor paginering, layout en fonts.
Er is geen universeel juist antwoord. Er is wel een fout antwoord voor je team. Vraag engineers waar ze een drie uur durende pagineringsbug willen oplossen.
2. Wat is de cold-start latency en is die voorspelbaar?
WASM en native binaries kunnen in microseconds starten. Chromium kan seconds nodig hebben. Het verschil wordt zichtbaar bij traffic spikes.
Vraag naar p99 voor de eerste request op een koude worker, wanneer die weer koud wordt en of de status page cold-start data toont.
3. Hoe wordt de prijs per render berekend?
Veelvoorkomende modellen:
- Per pagina: voorspelbaar, maar duur op schaal.
- Subscription + overage: vaak goedkoop, maar usage moet worden geschat.
- Compute-based: jij betaalt Lambda, containers, Chromium memory en cold starts.
Bereken de rekening bij huidig verkeer, 5x en 50x. De kostencurve is belangrijker dan de headline price.
4. Is output deterministisch?
Dezelfde input moet dezelfde bytes geven. Dat heb je nodig voor PDF diff in CI, fiscale bewaarplicht, archive hashes en legal review.
Browser-based renderers zijn vaak niet deterministisch tussen Chromium-versies. Native renderers zijn beter. Vraag of bytes veranderen na een engine update.
5. Hoe worden fonts, CJK en RTL behandeld?
Fontproblemen verschijnen vaak pas bij uitbreiding naar nieuwe markten. Dan toont de PDF ineens □□□□.
Vraag welke scripts ingebouwd zijn, wat gebeurt met onbekende glyphs, of custom fonts per request kunnen en of RTL shaping bestaat.
6. Welke complianceprofielen zijn ondersteund?
Als EU-facturen, PDF/A, XML attachments of digitale handtekeningen ooit nodig zijn, vraag om native support. “Later converteren” betekent een extra pipeline die jij beheert.
Goede antwoorden lijken op { profile: "PDF/A-3b" } of { einvoice: { format: "factur-x", xml: "..." } }.
7. Is rendering stateless? Waar gaan documenten heen?
Stateless rendering ontvangt een request, geeft PDF terug en slaat niets op. Jij beheert persistence. Dat is beter voor gereguleerde workloads.
Stateful rendering bewaart PDF bij de vendor en geeft een signed URL. Handig, maar een derde partij heeft kopieën van je documenten.
8. Wat gebeurt er bij failure?
Elke renderer faalt soms. Controleer structured errors, idempotent retry, kosten voor failed renders, status page, webhooks, region p50/p99 en synthetic probes.
gPdf scorecard
| # | Vraag | gPdf antwoord |
|---|---|---|
| 1 | Input | JSON DocumentRequest |
| 2 | Cold start | 5-20 ms, V8 isolate, geen browser |
| 3 | Kosten | $0/$5/$8/$12 per maand; $0.00005/page overage |
| 4 | Determinisme | Byte-identical met dezelfde engine-versie |
| 5 | Fonts | NotoSans CJK + Latin fallback ingebouwd |
| 6 | Compliance | PDF/A-1b/2b/3b/4 + Factur-X / ZUGFeRD |
| 7 | Stateless | Ja, geen document storage |
| 8 | Failure | Public status page, structured errors, idempotent |
Als je input echt onveranderbare HTML is, passen DocRaptor of Prince mogelijk beter.
Samenvatting
Vraag niet “wat is de beste PDF API”. Stel deze acht vragen en kies op basis van je echte workload. Voor facturen, bonnen en gestructureerde documenten kun je gPdf testen in de Playground.