API and integrations

The platform is API-first

A developer at a screen of code — programmatic access to digital product passports.

Everything the screen does goes through the API

WIARA was built as an API before it was built as an interface. The dashboard you use talks to the same programmatic interface you are given — there is no private mode and no feature that exists only behind a button. Integration is therefore not an addition to the platform; it is the platform.

There are two interfaces. One is for integration and administration — over a hundred operations documented to OpenAPI 3.0.3: passports, templates, organisations, files, audit trail, statistics. The other is public and read-only, and it is how the world opens the passports themselves.

We send the full specification to teams that are integrating — ask and you will have it. You may also want the technical standards the platform is built on, or the product itself

What you can automate

API and integrations

Two interfaces, one contract

An integration API for your systems and a public read-only API for the passports themselves. Both documented to OpenAPI 3.0.3.

GS1 Digital Link resolver

Passports open by GS1 Digital Link identity. The resolver conforms to ISO/IEC 18975 — the standard, not a proprietary scheme.

Model, batch, item

All three granularity levels, plus product variants. The same QR standard whichever level your delegated act ends up naming.

Draft, preview, publish

A passport is prepared as a draft, reviewed over a protected link and published when it is ready. Every version stays in the history.

Audit trail on demand

Who changed what — by object, by user, by manufacturer, by operator, by platform. Not one long journal, but a question with an answer.

24 languages, programmatically

Passport values are managed per language. Automatic translation is switched on or off per passport.

What programmatic access covers

Every area below is driven entirely through the API, with no manual step in the interface.

Passport lifecycle

✅ Create, edit, draft, preview over a protected link, publish, and a full version history.

Templates

✅ Template creation and versioning, status per version, per-language translations, and bespoke templates assigned to a single manufacturer.

Organisations

✅ Platforms, operators and manufacturers with their addresses and contacts — including transfer of ownership.

Operator ↔ manufacturer linking

✅ Invitation codes, preview before accepting, acceptance on behalf of your own organisation, and unlinking.

Files and evidence

✅ Secure upload, a version history per file, and signed download links valid for a limited time.

Audit trail

✅ Queries by object, by actor and by organisation — built to answer an auditor, not to be scrolled.

Statistics

✅ Metrics and time series by scope — for your dashboards, not only for ours.

Access and tokens

✅ Personal access tokens issued and revoked per user, with administrative oversight.

Taxonomy

✅ Regulations and product groups held as data — a new product group is added, not re-engineered.

Public read

✅ Opening a passport by GS1 Digital Link at model, batch or item level, variants included; a withdrawn passport answers distinguishably rather than silently.

API and integrations

Frequently asked questions

Question Mark Section Supporting Image

Yes. The full OpenAPI specification is not published openly, but we send it to any team preparing an integration — you only have to ask. That way the documentation reaches the people who use it rather than the people who copy it.

Yes. The interface is a client of the same programmatic access you are given. That is the difference between a platform with an API and a platform that had an API added to it.

Yes. Creating and updating passports, uploading documents and managing organisations are all programmatic operations, so your system can call them directly. Which integration pattern is right depends on your system — that is a conversation with one of our engineers, not an off-the-shelf recipe.

Through GS1 Digital Link — the standard way for a QR code to point at a product. The resolver conforms to ISO/IEC 18975, and the identity itself is built on the GTIN.

The answer is distinguishable. A passport that was published and is no longer valid is not made to look as though it never existed — the system reading it can tell the difference and act accordingly.

Not yet. EPCIS 2.0 is a planned extension for sectors with intensive traceability; the base passport does not require it. We would rather say so than let it be assumed.

A technical team in a working meeting — integrating a DPP platform.
Open StandardsProgrammatic Access
Open StandardsProgrammatic Access
Last verified