Norruva · Developer platform
Build on the Digital Product Passport API
A REST API for building, publishing, and resolving Digital Product Passports — the versioned, publicly-resolvable disclosure records mandated by EU regulations such as ESPR and the Battery Regulation. Everything here runs through the public /api/v2/* surface, exactly as a third-party integrator would — sandbox-first, nothing anchors or bills.
The one model to internalise: Product ≠ Passport
The single most important concept for integrators is that a Product and a Passport are different things, created in different steps.
- A Product is your tenant-owned commercial item — a GTIN, a serial, a category, and category-specific
extensions. Creating a product does not make it public and does not register a resolvable identifier. - A Passport (DPP) is the versioned disclosure artifact generated from a product, then published. Publishing mints an immutable version; registering the GS1 Digital Link is a separate, deliberate step.
publish to also register the resolver identifier. They are distinct calls — see Quickstart steps 7a and 7b.The integration journey
End to end, an integrator moves through this sequence. Each stage maps to concrete endpoints in the API Reference.
authenticate → discover → create product → validate → generate passport →
compliance-check → publish + register → resolve publicly → webhooks → bulk jobs → observeNaming note: these are integration steps (0–12, the software/API journey). The TSC roadmap separately numbers cycle steps 1–6 (the physical Auto-ID journey: mint/allocate serial → carrier issue → print job → label verify → EPCIS confirm → stage-scan custody), which begins where this journey ends — always qualify which sequence when saying "step N".
How these docs are organised
/api/v2/* endpoint, grouped by resource, with auth.Source references (2)
- docs/testing/E2E-DEVELOPER-EXPERIENCE-PLAN.md
- docs/testing/ATLAS-CANONICAL-GLOSSARY.md