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 EU law requires: the battery passport under the Battery Regulation from 18 February 2027, and ESPR product groups as their delegated acts apply. 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). Cycle steps 1-6 are numbered separately (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.