Standards
EN 18216: Data Exchange Protocols
What EN 18216 defines for DPP data exchange — RESTful APIs over HTTPS/TLS, message formats, extensions and the vendor independence principle.
EN 18216:2026 defines how Digital Product Passport data moves: data processing, exchange protocols and formats. It is the channel over which the operations defined by EN 18222 flow.
What it defines
| Topic | Content |
|---|---|
| Protocol | REST over HTTPS/TLS |
| Format | Structured, machine-readable messages |
| Authentication | Authorisation consistent with access tiers |
| Extensions | Voluntary fields permitted without breaking the core |
| Independence | No proprietary protocol or format may be required |
See EN 18222 passport APIs and the EN 18223 core data model.
Why it matters
The most concrete question to ask a DPP platform is: "can I get my data out over a standard API in a standard format?" EN 18216 makes the answer contractible.
In practice it reduces three risks:
- Changing provider: the data can move.
- Customer integration: a retailer or OEM can consume your API.
- Authority access: inspection queries run through a standard interface.
See what a DPP service provider is and choosing DPP software.
Relationship to content negotiation
Serving HTML to a person and JSON-LD to a machine at the same URL happens at the resolver layer. EN 18216 governs system-to-system exchange (B2B and B2G). Together they let one identifier serve both consumers and systems. See what a resolver service is.
Implementation notes
- Define a TLS version and cipher policy; the passport has to stay up for the product's lifetime.
- Plan rate limiting and caching: the public tier can attract heavy traffic.
- Use version headers: API version and passport version are different things.
- Standardise your error format to make life easier for integrators.
See cyber security for DPP systems.
Frequently asked questions
Does the standard mandate a specific JSON schema?
The schema side sits with EN 18223; EN 18216 sets transport and format principles.
Can I write my own API?
Yes, if it conforms — but versioning, access tiers and persistence duties come with it. See build vs buy.
Can I use GraphQL?
The standard is built on REST. You can offer additional interfaces, but a conformant REST interface is expected to exist.
