DPP vendor evaluation — our answers

TracePass exposes a documented REST API covering passports, products, templates, organisations, and webhooks. Read and write surfaces are symmetrical — anything that can be done in the UI can be driven through the API.

Authentication uses per-organisation API keys (company-wide access) or OAuth 2.0 applications with per-scope consent via the OAuth Apps tab in the dashboard. The OpenAPI spec is published to every customer in the developer portal — no NDA gating, no "talk to our integration team" friction.

Each category template ships with its own CSV template — column names match the schema, types and constraints validated on upload. Drop a file in the UI; the bulk-import endpoint accepts the same CSV via API for automated pipelines.

Validation is per-row with column-level error reporting. The batch API endpoint returns a per-item result — rows that pass validation are created, rows that fail are reported individually without blocking the rest.

Every paid plan can route QR codes through the customer's own domain (e.g. id.your-brand.eu/01/...). TracePass resolves under your domain, so URL portability is permanent — even if you exit, the URL on the package keeps working.

Free / trial accounts resolve under tracepass.eu/p/...; switching to a paid tier does not break in-flight QR codes that started on the shared domain. After cancellation, TracePass continues to resolve your existing passports for 30 days at no cost (see Terms of Service) — for paid customers on a custom domain, that gives you a window to re-point DNS to another vendor's resolver. After the 30-day grace, shared-domain URLs return expired and TracePass stops serving the custom domain. Resubscribing at any point brings the expired passports back online, as many as the plan allows.

EPCIS 2.0 export, capture, and query are all included on every plan, Free included. Suppliers and ERP systems push events to our Capture endpoint; our query node answers the EPCIS Query interface; any passport's events serialise as a standards-valid EPCIS 2.0 JSON-LD document, advertised on the QR's GS1 Digital Link resolver so an EPCIS-aware system discovers the history automatically.

Volume is the meter: Basic 1,000 events/month, Starter 10,000, Growth 100,000, Scale 1,000,000, Pro 10,000,000, Enterprise unlimited. Free tier has 10 events/month as evaluation guardrail. Hitting a paid-plan cap is opt-in overage at a per-1,000-event block rate that drops from €5 (Basic) to €1 (Pro) — see the price table on /pricing. Free hitting its cap requires an upgrade, no surprise charges.

The TracePass AI agent additionally drafts EPCIS TransformationEvents from supplier datasheets and PDF specs for your reviewer to approve — the same "AI suggests, human approves" gate as the rest of the platform.

TracePass ships a Model Context Protocol server, listed on the official MCP Registry as eu.tracepass/tracepass. Two ways to use it: a hosted endpoint you point an MCP client at, or a local npm package run via npx. Authentication supports both API keys and OAuth 2.0 (the "Connect" button in Claude.ai and compatible MCP clients).

It exposes the platform as MCP tools (products, passports, fields, parties, EPCIS), plus resources and prompts. Write actions are clearly marked — the server tells the assistant which actions are billable or irreversible, so an agent warns you before creating passports or archiving anything.

TracePass ships an n8n community node — n8n-nodes-tracepass — built strictly to n8n's current community-node verification standard. Declarative routing, zero runtime dependencies, MIT-licensed, free. It surfaces three resources (Product, Passport, EPCIS Event) with the v1 API operations on each.

Install it from any n8n instance via Settings → Community Nodes → Install. Authenticate with the same `tp_` API key as the REST API. Risky operations carry safety notes in their descriptions — Create on Passport is billable, Archive is irreversible — and ship with an opt-in "Confirm Overage Charge" toggle so a workflow doesn't surprise-bill the account.

Zapier and Make integrations are not yet shipped — call the REST API directly via their HTTP modules in the meantime; the same `tp_` API key works.

Every passport in TracePass is keyed by serial number. gs1.serialNumber is the canonical primary join, with SKU/model as a secondary field for grouping. The data model was designed serial-first because the regulatory direction is serial-first.

Serial-level passports support per-unit lifecycle data: state of health, repair history, ownership transfers, end-of-life status. Bulk creation and bulk update by serial range are first-class operations.

Every passport edit is recorded with timestamp, actor, and field-level diff, shown as a timeline on the passport detail page.

On top of that, every change to a published, suspended, expired or archived passport is archived as a complete snapshot of what the passport asserted, sealed with a SHA-256 content hash (re-verified on every read) and recording who made the change. A nightly sweep catches any change made outside the normal edit paths. This is the change archive EN 18221:2026 (clause 4.2) describes.

To answer "what did this passport say on date X", ask for the version valid at that moment: in the dashboard, or through the API with GET /api/v1/passports/{id}/snapshots?at=<date>. The public passport URL always serves the current version.

Each passport exports as JSON-LD via the API or UI download. The export preserves field metadata, source attribution, version history, and translations.

Tenant-wide bulk export packages every passport, every product, every template you've created. Media attachments (images, test reports, PDFs) ship with stable URLs that remain resolvable for the 30-day post-termination grace window — long enough to migrate to a successor vendor.

Templates are versioned. Adding a field is non-breaking; changing or removing one creates a new schema version with an explicit migration path. In-flight passports stay valid against their original schema; amended passports validate against the latest version.

Every regulatory change we track is logged in the public Regulatory Changelog with date, scope, and migration impact. On Growth and above, tracked changes for your product categories appear in your dashboard notifications.

Every public passport URL serves valid JSON-LD when the request carries Accept: application/ld+json. The same URL serves HTML for browsers and JSON-LD for crawlers and authority systems — no separate endpoint to discover.

URLs follow the GS1 Digital Link grammar (.../01/{GTIN}/21/{serial}). Resolver behaviour is self-tested against the v2.0 spec using a published script (tracepass-open/packages/gs1-utils).

Accept: application/json returns the same body as plain JSON — EN 18216 makes JSON the mandatory machine format — and the body carries the EN 18223 passport header as top-level fields (digitalProductPassportId, uniqueProductIdentifier, granularity, dppSchemaVersion, dppStatus, lastUpdated, economicOperatorId). Passport URLs are served over HTTP/2 or later.

Each passport carries a structural `parties` block keyed by economic-operator role. Each entry has a validated GS1 GLN (13 digits, mod-10 check digit), legal name, ISO 3166-1 country code, and optional URL. The GLN is emitted in both `gs1:partyGLN` (GS1 Web Vocabulary, spec-precise) and `schema:identifier` with `propertyID: "GS1:GLN"` (schema.org mirror) so DPP-aware readers and standard schema.org crawlers each see what they expect.

For suppliers without a GLN, a `legacyOperatorId` field accepts a VAT, EORI, national tax ID, or internal supplier code — every party stays traceable even before the supplier's GS1 onboarding is complete.

Per-category required-role enforcement matches the regulation: battery passports need manufacturer + recycler + PRO; toys need manufacturer + importer; packaging-bearing categories (FMCG, packaging) need PRO. Optional roles surface in the editor but don't block publish. The same role map drives the dashboard editor, the v1 API (`PATCH /api/v1/passports/{id}/parties/{role}`), and the CSV bulk-import templates (dotted-key columns: `manufacturer.gln`, `recycler.legalName`, etc.).

The QR code resolves to an ordinary web address. The same passport opens in any desktop or laptop browser, on a shop kiosk or on a tablet, with no app to install.

Every public passport offers a PDF download of the fields the viewer shows, in the chosen language, with its images embedded, so a retailer or customer-service desk can print it on request.

The viewer is built for assistive technology as well: it passes an automated WCAG 2.1 AA audit, is fully usable by keyboard, reflows on a narrow screen or at 400% zoom, and declares the passport's language so a screen reader uses the right voice (EN 18216 requires EN 301 549 for the human-readable passport).

Two distinct uptime targets: 99.9% for the application portal where you and your team work; 99.95% for the public resolver that authorities and consumers hit through QR codes. Both are hosted in the EU (Germany) and are not replicated across regions; availability is monitored on the public status page.

The status page tracks both surfaces independently. Outage credits apply per surface — portal credits do not require resolver outage, and vice versa.

Application and primary database: the TracePass platform and its database are hosted on Hetzner in Nuremberg, Germany. The marketing website is served by Vercel; its server functions run in Frankfurt. Email delivery: Resend (EU). Full sub-processor list with jurisdictions on the trust page.

We do not use any US-only sub-processors for production data paths. The Anthropic AI processing path (used for category extraction and translations) is invoked on customer demand only and is governed by an explicit DPA — the trust page documents this in detail.

Standard processor DPA available; signed before customer data flows. The sub-processor register on the trust page lists every processor with role and jurisdiction; additions trigger advance notification per Article 28.

Subject access and erasure requests are handled on request under the DPA process (the passport content itself is product data, not personal data; the relevant surface is scan analytics). Breach notification: 72 hours from confirmed incident, codified in the DPA.

Operational backups: a daily automated logical backup of the primary database is written to an encrypted EU object store (Cloudflare R2), kept off the database server with 7-day retention.

Product-lifecycle retention: while the subscription is active, passports remain live and queryable for the full regulatory lifetime applicable to each product category. After subscription termination, published passports stay publicly resolvable for 30 days at no charge; after that, QR codes return an expired notice. Resubscribing restores access at any point.

Default isolation is logical: every read and write is scoped by companyId, enforced in every route that touches tenant data and checked by an automated test that fails when a route skips it.

If you need physical isolation, contact us.

Tiered passport allowance. Each plan includes a passport count; overage is metered at a published rate that drops at scale. We never charge per scan — consumer scan volume is unpredictable, and we will not send you a surprise invoice when one of your products trends.

For high-volume battery, EV, and tyre manufacturers with serial-level mandates, we offer a serial-volume bundle with marginal-cost pricing that makes the economics work at scale. Talk to us.

Full JSON-LD export of every passport, product, template, and media attachment is available on demand at no charge. No "export fee."

After cancellation, TracePass continues to resolve your existing passports for 30 days at no cost (codified in the Master Services Agreement). During that window, QR codes on already-printed packaging keep resolving to your data while you migrate; on a custom domain you re-point DNS to a successor vendor and the printed codes never break.

Customer is the data controller throughout the relationship and after termination. Optional source escrow available on Enterprise: a tagged copy of our application source code is held by an independent third party, releasable to you under defined trigger events.

Liability terms are as set out in the Terms of Service. The trust page lists indemnification carve-outs (third-party IP claims, regulatory penalties traceable to vendor error).

E&O insurance is not yet in place.

The data is yours. Every paid plan includes a full JSON-LD export of every passport, product, and template — provenance and version history preserved — at no charge, via the REST API. There is no export fee and no proprietary format you can't read elsewhere.

The URL is yours. On every paid plan the GS1 Digital Link resolves under your own domain via DNS you control. If you leave, you re-point that DNS to a successor and the QR codes already printed on shipped products keep working — the single biggest, least-discussed lock-in risk in DPP, neutralised by design.

The continuity is contractual. A 30-day post-termination grace window keeps your passports resolving while you migrate; you remain the data controller throughout; and Enterprise customers can add source escrow with defined release triggers (insolvency, uncured breach, sustained outage). Each of these is detailed in its own answer below.

We publish the GS1 Digital Link conformance test result on the trust page. Schema.org JSON-LD is emitted on every public passport URL. Templates are designed to align with CIRPASS vocabulary recommendations; a formal field-by-field alignment document has not yet been published.

GS1 GLN (Global Location Number) identifiers are first-class fields on every passport — strict 13-digit mod-10 validation, multi-role keyed (manufacturer / importer / authorised representative / distributor / recycler / producer-responsibility organisation), and emitted in both gs1:partyGLN and schema:identifier 'GS1:GLN' shapes so DPP-aware readers and standard schema.org crawlers each see what they expect.

Where conformance is partial (e.g. CIRPASS recommendations that postdate our last alignment review, or the /414/{gln} resolver path which is on the build-on-first-ask roadmap), the gap is named explicitly with a target version.

For categories where the delegated act is not yet final, we maintain explicit speculative-field markers in the template. Pro and Enterprise customers can submit field-level proposals that go into the next template version after a brief review.

Accepted proposals ship in a new version of the public @tracepass/dpp-schemas package.

Enterprise customers can opt into source escrow via an independent third-party escrow agent. A tagged copy of the application source code is deposited and updated on a recurring cadence.

Release triggers are defined in the escrow agreement and typically include: vendor insolvency, material breach uncured, or sustained outage beyond a defined threshold.