Skip to content
pagenull

Proof you can check

We'd rather show you than ask you to trust us. Everything below is real output you can download and check yourself, with no account.

E-invoices pass the official validators

This is a Factur-X / ZUGFeRD e-invoice made exactly the way POST /v1/invoices makes it: a Bulgarian seller billing a German business under reverse charge. We ran it through Mustang 2.26.0, the validator from the ZUGFeRD project, which checks the PDF/A-3 file with veraPDF and the embedded EN 16931 XML with the official rules. The report is Mustang’s own output, unedited.

To run the same check yourself, with Java 11 or later:

Terminal
java -jar Mustang-CLI-2.26.0.jar --action validate --source einvoice-sample.pdf

Mustang is free from github.com/ZUGFeRD/mustangproject. Our test suite runs the same validator on domestic invoices, reverse charge, mixed VAT rates, prepaid amounts, credit notes and test renders.

“Nothing is stored”, checked three ways

Every check works the same way: put a unique marker in a document, render it, then look everywhere it could have been kept. If the marker turns up anywhere, the check fails.

1. Against production, every hour

Last checked against production: 1 minute ago, passed. A script on the server sends a fresh marker through the public API as a free test render, then searches:

The last run searched:

  • test render through the API: not found
  • container logs: not found
  • renderer temp files: not found
  • files written by any container: not found
  • database dump: not found

The check uses a free test render. It goes through the same code as a paid render: the same API route, renderer, logging and receipt. The only differences are a watermark on the page and that it isn’t counted toward a plan.

2. In our test suite, before every change we publish

The last run: 17 of 17 passed on 7 November 2026, at commit a4cb89b. The test code is published as it is:

  • no-retention.test.ts: Renders documents containing a unique marker through the real API code, then searches a full dump of the database, every log line and all console output for it, and fails if any file is written during the render.
  • no-write-paths.test.ts: Reads our own source code and fails if anything writes to disk outside a short allowlist, logs outside the metadata-only logger, or brings back an option or table for storing output.
  • no-trace-on-disk.test.ts: Renders a document with a unique marker in a real Chromium, then searches every file Chromium created (its profile, cache and temp files) for it, while the browser runs and again after it closes.
Every test by name
  • HTML sent to /v1/pdf is not stored, logged or written to disk
  • template variables are used once and never stored
  • saved templates are encrypted at rest
  • URLs are not stored or logged
  • the logger drops any field that isn't metadata
  • rejects the old store/expiresIn options with a pointer to deliverTo
  • uploads the output to the customer's URL and keeps nothing
  • refuses private or metadata targets (SSRF via deliverTo)
  • every render carries retention, region, render id, renderer and a valid receipt for the exact bytes
  • test renders are free and watermarked
  • Chromium's profile, cache and temp files never hold the document, during or after a render
  • scans a meaningful amount of code
  • no filesystem writes outside the allowlist
  • no console logging outside the metadata logger
  • logMeta is never handed request content
  • no output-storage option or table can come back unnoticed
  • the renderer container is configured read-only with tmpfs only

3. By design, so there is nothing to find

The checks confirm the setup below. It’s the setup that actually protects your data.

The setup that actually protects your data

  • The renderer’s filesystem is read-only. Chromium can’t write anywhere except /tmp, and that folder lives in memory only, so it’s gone when the renderer restarts.
  • A fresh incognito browser context for every render, closed when the PDF is done.
  • Chromium’s crash reporter is turned off, so there are no crash dumps that could hold a page.
  • Our logs only accept metadata: key id, time, endpoint, status, size and duration. Container logs are capped at 10 MB × 5 files and rotate.
  • There is no option to store output. If you need the file elsewhere, we upload it to your own storage and keep nothing.

Trust lists everything we do keep, such as your account and templates you choose to save, and the data processing agreement puts all of this in writing.

What this can’t prove

These checks show that the service as it runs today doesn’t keep your documents. They can’t prove that we didn’t change the code after a check ran, and nothing can prove a negative from the outside. That’s why the production check runs every hour rather than once, why the dates are on this page, and why the commitment is also in the DPA.

A receipt you can verify end to end

Every PDF comes with a signed receipt. The sample invoice’s receipt is published in full, with the file it names, so you can check the signature and the hash yourself: verify the sample invoice’s receipt. The playground shows the whole response, nothing shortened.