The EU digital product passport registry became operational on 20 July 2026, with operating rules in Commission Implementing Regulation (EU) 2026/1778 (in force 6 August 2026). The parts of dpp-registry that the regulation text fixes have been brought in line with it. This issue records the parts it does not fix — the wire contract — so that a reader knows which types are grounded and which are still our own invention.
This matters more here than in a normal crate: these types are published, and a released version cannot be unpublished. Anything shipped as though it were the registry's contract is vendored downstream and outlives the mistake.
What the regulation grounds, and what it does not
Grounded, and now modelled: the model/batch/item registration level and its linking rules (Art. 8(1), 8(4), 8(5)); the operator identifier carrying its scheme rather than a guess; the commodity code as a structural type; the back-up link; and the distinction between a registration that was accepted for validation and one that has been ruled on.
Not grounded — everything below.
The payload and envelope shapes are ours, not the registry's
RegistrationPayload and EuRegistryEnvelope are a reasonable reading of what Art. 8 requires to be registered. They are not transcribed from a published schema. Field names, nesting, and the envelope's existence at all are our design.
EuRegistryEnvelope::request_id is treated as an idempotency key — the request is now minted once and replayed unchanged on retries, which is correct behaviour if the registry uses it that way. Whether it does is unverified.
TransferNotification is in the same position, with the added uncertainty that the registry's transfer semantics are not described in the material available.
RegistryEndpoint carries a confirmed host and guessed everything else
The production and test hosts are the Commission's published ones. Beneath them:
- resource paths are invented;
- the
/api/v1 prefix is observed on the registry's own web client, not read from a specification;
api_version "1.0" is provisional;token_endpoint models an OAuth2 token exchange, and registry identity is not that — a verified economic operator proves identity with a qualified electronic seal or a qualified electronic attestation of attributes (IR 2026/1778 Arts. 4–5). The field is kept only so consumers compile, and is marked as wrong in place.
RegistryStatusCode is an unverified vocabulary
The five codes are a plausible set, not a transcribed one. One variant has already been removed as unreachable; the remainder should be checked against the specification rather than against our own mapping.
There is no proof-of-registration type
Art. 9 entitles an operator to a proof of registration: a secure electronic document, downloadable, valid 90 calendar days with regeneration, and carrying an electronic time stamp. Nothing models it. Adding storage and lifecycle without a specified retrieval contract would be an empty box, so this waits.
Two items that are work, not waiting
Commodity code ranges
CommodityCode validates structure only — HS-6, CN-8 or TARIC-10. Art. 8(7)(d) has the registry check the code against "the permitted ranges for this product group", and those ranges live in the applicable delegated act. Once an act names them, they belong beside the other per-sector regulatory facts rather than hard-coded here.
The identifier length question
The registry's operator-facing form states a 50-character maximum for the unique product identifier. A GS1 Digital Link of the shape this workspace builds — https://<host>/01/<gtin-14>/21/<20-char serial> — is 65 characters, and 77 with a batch segment. Even a minimal host stays over.
If 50 turns out to be the API's limit and not the form's, the carrier URL shape has to change, which reaches dpp-digital-link and every printed label derived from it. This is worth resolving early: it is cheap to answer now and expensive to discover during integration.
How to close these
Every item above is closed the same way: obtain the registry's published API specification and diff it against these types. Until then the honest position is what the code already states — hosts confirmed, contract provisional, and the pins left visible in place rather than quietly dropped.
The EU digital product passport registry became operational on 20 July 2026, with operating rules in Commission Implementing Regulation (EU) 2026/1778 (in force 6 August 2026). The parts of
dpp-registrythat the regulation text fixes have been brought in line with it. This issue records the parts it does not fix — the wire contract — so that a reader knows which types are grounded and which are still our own invention.This matters more here than in a normal crate: these types are published, and a released version cannot be unpublished. Anything shipped as though it were the registry's contract is vendored downstream and outlives the mistake.
What the regulation grounds, and what it does not
Grounded, and now modelled: the model/batch/item registration level and its linking rules (Art. 8(1), 8(4), 8(5)); the operator identifier carrying its scheme rather than a guess; the commodity code as a structural type; the back-up link; and the distinction between a registration that was accepted for validation and one that has been ruled on.
Not grounded — everything below.
The payload and envelope shapes are ours, not the registry's
RegistrationPayloadandEuRegistryEnvelopeare a reasonable reading of what Art. 8 requires to be registered. They are not transcribed from a published schema. Field names, nesting, and the envelope's existence at all are our design.EuRegistryEnvelope::request_idis treated as an idempotency key — the request is now minted once and replayed unchanged on retries, which is correct behaviour if the registry uses it that way. Whether it does is unverified.TransferNotificationis in the same position, with the added uncertainty that the registry's transfer semantics are not described in the material available.RegistryEndpointcarries a confirmed host and guessed everything elseThe production and test hosts are the Commission's published ones. Beneath them:
/api/v1prefix is observed on the registry's own web client, not read from a specification;api_version"1.0"is provisional;token_endpointmodels an OAuth2 token exchange, and registry identity is not that — a verified economic operator proves identity with a qualified electronic seal or a qualified electronic attestation of attributes (IR 2026/1778 Arts. 4–5). The field is kept only so consumers compile, and is marked as wrong in place.RegistryStatusCodeis an unverified vocabularyThe five codes are a plausible set, not a transcribed one. One variant has already been removed as unreachable; the remainder should be checked against the specification rather than against our own mapping.
There is no proof-of-registration type
Art. 9 entitles an operator to a proof of registration: a secure electronic document, downloadable, valid 90 calendar days with regeneration, and carrying an electronic time stamp. Nothing models it. Adding storage and lifecycle without a specified retrieval contract would be an empty box, so this waits.
Two items that are work, not waiting
Commodity code ranges
CommodityCodevalidates structure only — HS-6, CN-8 or TARIC-10. Art. 8(7)(d) has the registry check the code against "the permitted ranges for this product group", and those ranges live in the applicable delegated act. Once an act names them, they belong beside the other per-sector regulatory facts rather than hard-coded here.The identifier length question
The registry's operator-facing form states a 50-character maximum for the unique product identifier. A GS1 Digital Link of the shape this workspace builds —
https://<host>/01/<gtin-14>/21/<20-char serial>— is 65 characters, and 77 with a batch segment. Even a minimal host stays over.If 50 turns out to be the API's limit and not the form's, the carrier URL shape has to change, which reaches
dpp-digital-linkand every printed label derived from it. This is worth resolving early: it is cheap to answer now and expensive to discover during integration.How to close these
Every item above is closed the same way: obtain the registry's published API specification and diff it against these types. Until then the honest position is what the code already states — hosts confirmed, contract provisional, and the pins left visible in place rather than quietly dropped.