Document generation as a feature — not an infrastructure problem

Who this is for

Product and engineering teams building B2B SaaS who arrive at the point where documents become part of the product: invoice PDFs sent to end customers, contracts built from template data, monthly reports as printable versions, exportable forms.

Typical situations:

• Series A/B: first paying customers → invoice output must look professional
• Enterprise deal on the horizon: the customer wants SSO, SAML, and a printable quote on their own letterhead
• Compliance requirement: EU customers need e-invoices (XRechnung/ZUGFeRD) from 2025 onward
• Scaling pain: your current wkhtmltopdf setup collapses under load, fonts disappear, PDFs become inconsistent

Typical pain points

1. Running your own Chrome costs more than you think — OOM kills, font management, timeouts, release cadence
2. Template editors slow the product team down — every customer-specific layout becomes an engineering ticket
3. Internationalisation in PDFs is tricky — umlauts, RTL, date formats
4. The 2025/2027 e-invoicing mandate lands on the backlog — XRechnung and ZUGFeRD turn into standalone stories
5. Digital signatures (PAdES, PKCS#12) — nobody wants to implement them themselves

Four typical scenarios

1. Invoice on a customer’s stationery

Your platform runs billing for customers. Each customer uploaded their own stationery as a PDF. At monthly billing time, the final invoice should sit exactly on that stationery:

curl -X POST https://api.dokmatiq.com/v1/docgen/render \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -d '{
    "stationery": { "firstPage": "<base64-pdf>", "subsequentPages": "<base64-pdf>" },
    "contentAreas": [
      { "x": 20, "y": 50, "width": 80, "html": "<p>To<br>Example Ltd<br>1 Sample Street<br>W1A 1AA London</p>" },
      { "x": 20, "y": 90, "html": "<h1>Invoice 2026-0042</h1>" },
      { "x": 20, "y": 120, "html": "<table>...</table>" }
    ],
    "outputProfile": "PDF/A-3b"
  }' -o invoice.pdf

No template editor, no HTML reproduction of the layout — the original stationery simply gets “printed over”.

2. Contract output with placeholder substitution

Your users curate contracts as .docx templates. On close, customer data is inserted automatically and the result is returned as a signed PDF:

curl -X POST https://api.dokmatiq.com/v1/convert/word-to-pdf \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -F "document=@contract-template.docx" \
  -F 'variables={"customerName":"ACME","startDate":"2026-05-01","amount":"€12,500"}' \
  -F "outputProfile=PDF/A-3b" | \
curl -X POST https://api.dokmatiq.com/v1/pdf/sign \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -F "document=@-" \
  -F "certificate=@signing.p12" \
  -F "passphrase=$P12_PASS" \
  -F "profile=PAdES-B-LT" \
  -o contract-signed.pdf

Two calls: conversion with placeholder substitution, then a PAdES long-term signature. Both stateless, both in seconds.

3. E-invoice straight from your billing data

Your invoicing logic stays in your code; transport to ZUGFeRD or XRechnung happens in a single API call:

curl -X POST https://api.dokmatiq.com/v1/einvoice/zugferd \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -d '{
    "profile": "EN16931",
    "invoice": { "id": "2026-0042", "issueDate": "2026-04-18", "seller": {...}, "buyer": {...}, "lines": [...] }
  }' -o invoice-zugferd.pdf

A single endpoint, a finished ZUGFeRD PDF/A-3 with the CII XML embedded. Your database stays the source of truth.

4. Monthly report from your BI tool

Your BI tool produces HTML or Markdown with customer metrics. From there, a PDF for the customer:

curl -X POST https://api.dokmatiq.com/v1/convert/markdown-to-pdf \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -d '{
    "markdown": "# April 2026 Report\n\n## KPIs\n...",
    "theme": "stationery",
    "stationery": { "firstPage": "<base64-pdf>" }
  }' -o report.pdf

No in-house template generator. Content lives in the BI tool or your CMS; the API handles the layout.

Features most relevant

• Document generation — the core feature: stationery + content areas
• PDF tools — merge, split, password protection, watermarks
• Digital signatures — PAdES long-term signatures via API
• E-invoices — ZUGFeRD, XRechnung, Peppol BIS

SDKs and integration

Dokmatiq ships SDKs for Python, TypeScript, Java, PHP and C#. All generated from the same OpenAPI spec — deterministic, typed, and compatible with your ecosystem’s tooling (pytest fixtures, Jest mocks, etc.). Every call is idempotent via Idempotency-Key, retry-safe, and returns structured errors.

Pricing model

• Free tier: 100 documents/month — enough for development, staging, early pilots
• Pay-per-use beyond that: consolidated team billing via Stripe, no tier cliffs
• Enterprise: dedicated rate-limit bucket, SLA, self-hosting option via Docker container

Typical consumption profile: a B2B SaaS with ~500 paying customers, monthly billing + occasional contracts = roughly 5,000–10,000 documents/month.

When Dokmatiq is not the best fit

• Pure HTML rendering without stationery logic — if you only want HTML to PDF and the layout lives in your HTML, a simpler service often suffices
• Mass delivery to end customers with complex template governance — services like Docmosis or DocRaptor offer broader template editors for non-developers
• Ad-hoc documents without recurring structure — for one-off generation, local Pandoc wins

Honesty helps both sides: Dokmatiq shines for recurring, data-driven document production with layout quality and compliance requirements.

Common pitfalls

1. Stationery in the wrong format — fresh from Illustrator, often RGB instead of CMYK; DocGen accepts both but printer output may differ
2. Content areas in mm, not pixels — positions are always millimetre-precise; pixel conversion is mandatory
3. Idempotency-Key omitted — essential with retry logic; otherwise you risk duplicate documents
4. Font-embedding edge cases — emoji and Chinese characters may need a dedicated font registration