Developer Docs
Sandbox · API v2PlaygroundGet API keys

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.

60+
Endpoints
v2
Stable major
11
Calls to resolve
0
Sandbox side effects
Base path
/api/v2 · single stable major version
Transport
HTTPS · JSON request/response · Idempotency-Key on mutations
Auth
API key or OAuth 2.0 client-credentials, Authorization: Bearer <token>
Environment
Sandbox-first, nothing you do in sandbox anchors, emails, submits to registries, 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.
Why it matters. Two common integration bugs come from collapsing these: expecting a freshly-created product to resolve publicly, and expecting 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.

flow
authenticate → discover → create product → validate → generate passport →
compliance-check → publish + register → resolve publicly → webhooks → bulk jobs → observe

Naming 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

Was this page helpful?
Thanks, noted.Feedback goes to the docs team by email.