Which terms version applied at contract conclusion?
Version pinning, effective_at delivery and audit trail: how to establish the link between a transaction and the published version that applied at that time.
The question behind “which version applied?”
When a query, a complaint or a review comes up, the operational question is almost always the same: which version of the terms, the withdrawal notice or the privacy policy was published at a specific point in time? Without clean versioning, that becomes a reconstruction from backups, email attachments and memory.
This page describes how to establish the link between a transaction and the published version that applied at that time in a technically clean way — as an operational, not a legal, framing.
Version pinning: referencing one version deliberately
With version pinning a system references a specific approved version via ?version=N and stably receives exactly that state — regardless of whether a newer version has since gone live. If the pinned value diverges from the current live state, the Public Delivery API responds with 409 version_mismatch and reports the current version, so a consumer can re-pin deterministically.
Pinning fits when a system stores the version number used for a transaction itself and later wants to retrieve exactly the same version.
effective_at: the version at a point in time
When a system only knows the transaction time but not the version number, an effective_at delivery returns the matching version: a call with ?effective_at=<ISO-8601> returns the version published at that instant — as JSON, HTML or PDF derived from exactly that version.
version and effective_at are mutually exclusive. Both are plan-dependent and available from Business. The matching counterpart for the transactional case is in legal texts in order and contract confirmations.
The audit trail as the basis of proof
Pinning and effective_at only work because every approved version is an immutable, dated snapshot. The audit trail records when which version was approved and published. That makes the link between a date and the version that was live on that date traceable — without manual reconstruction.
The foundations of this versioning are covered in legal text versioning without copy-paste chaos and on the feature page legal text versioning. The concrete endpoints are in the API reference.
Boundary
TermShelf does not produce legally binding content and is not a substitute for legal advice. Whether and how a version record is legally weighed in a specific case is a question for qualified counsel. TermShelf establishes the technical link between a point in time and the published version.
Frequently asked questions
- Which terms version applied at contract conclusion?
- The version published at the time of contract conclusion. When every publication is a dated, immutable snapshot, it can be retrieved unambiguously via version pinning (?version=N) or an effective_at delivery (?effective_at=<ISO-8601>).
- What is the difference between version and effective_at?
- version=N references a known version number; effective_at=<ISO-8601> references the version published at a point in time. Both are mutually exclusive and available from the Business plan.
Related guides
Attaching terms as a PDF to order confirmations
How to attach the approved terms version as a PDF artifact from the Public Delivery API to transactional order confirmations — versioned and traceable.
Embedding the withdrawal notice in order confirmations
HTML in the email footer or PDF as attachment: how the approved withdrawal notice reaches transactional confirmations in a versioned way.
Embedding legal texts in Shopware order confirmations
How Shopware storefronts and order-confirmation emails pull terms, the withdrawal notice and privacy information as a versioned HTML, JSON or PDF artifact from TermShelf — instead of maintaining full texts across sales channels and Twig mail templates.