Delivering legal content via API: HTML, JSON and PDF
Three artifact forms of the Public Delivery API compared — when HTML fits, when JSON fits and when PDF fits.
What the Public Delivery API serves
The Public Delivery API is a read-only interface for published legal texts. It serves only approved versions — there is no write access and no access to drafts. That makes it a stable, publicly consumable source for website, shop, app and transactional emails.
Every published legal text is available in three artifact forms: HTML, JSON and PDF. Which form fits depends on the consuming system — not on the legal text itself. The full delivery contract is summarized on the feature page Public Delivery API.
HTML, JSON and PDF compared
- HTML fragment: a ready-rendered section to embed directly in a page, a footer or an email. The consuming system needs to know nothing about the internal structure.
- JSON: structured representation with sections and metadata — for systems that render their own layout, components or mail templates.
- PDF: a document generated from exactly the approved version — suitable as an attachment in order and contract confirmations.
Caching, ETag and version reference
Because published versions are immutable, the responses cache well. Via ETag and conditional requests (If-None-Match), unchanged content can be answered with 304 Not Modified instead of being re-transferred.
For deterministic delivery, a specific version can be pinned via ?version=N; if it diverges from the current live state, the API responds with 409 version_mismatch and reports the current version. Alternatively, ?effective_at=<ISO-8601> returns the version published at a point in time. Endpoints, headers and error codes in detail are in the API reference.
Embedding in website, shop, app and email
The pattern is the same everywhere: publish once centrally, consume the same source everywhere. A website embeds the HTML fragment, an app renders the JSON in its own components, a shop attaches the PDF to the order confirmation. No copied full texts, no parallel maintenance effort.
For shop systems specifically, see legal texts in Shopware, Shopify and WooCommerce. The case against scattered maintenance is in why legal texts shouldn’t live scattered across your CMS.
Boundary
TermShelf does not produce legally binding content and is not a substitute for legal advice. The API is a technical delivery path for already-approved content.
Frequently asked questions
- Can I change legal texts through the API?
- No. The Public Delivery API is read-only and serves only approved versions. Authoring and approval happen in the TermShelf application.
- Which formats does the API serve?
- As an HTML fragment, as JSON and as PDF — each from the same approved version. The consuming system chooses the form.
Related guides
Embedding legal texts in order and contract confirmations
How Transactional Legal Text Delivery works: HTML in the email footer, JSON in your own template or PDF as an attachment for order, contract and sign-up confirmations.
Embedding legal texts in Shopware, Shopify and WooCommerce
TermShelf as a central source and delivery layer for shop systems: HTML, JSON and PDF via the Public Delivery API instead of scattered maintenance in the shop backend.
Why legal content shouldn't live scattered across your CMS
Legal content distributed across CMS pages, Word documents, and copied snippets makes versioning and live drift detection harder. This guide outlines typical risks.