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 is per-organisation API keys with scoped permissions. 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; partial imports are atomic (either all rows commit or the file is rejected with a diff). For high-volume customers, the import API supports multi-file batches.

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.

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. The passport detail page renders a version timeline; each historical version is fetchable by ID via the API.

Public passport URLs serve the latest version by default; ?version=N or ?as_of=DATE return the historical state. This is the surface authorities use during conformity-assessment queries.

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. Customers are notified before any schema change takes effect.

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}). The resolver is conformance-tested against GS1's reference suite.

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.).

Two distinct SLAs: 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. The resolver is fronted by a CDN and replicated across regions for the higher target.

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

Primary database: MongoDB Atlas in eu-west-1 (Frankfurt). Application runtime: Vercel EU edge regions. Email delivery: EU-region SES. Monitoring and logging: EU-region. 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 can be served against the analytics surface (the passport content itself is product data, not personal data). Breach notification: 72 hours from confirmed incident, codified in the DPA.

Operational backups: 30-day point-in-time recovery on the primary database. Restore tested on a recurring schedule.

Product-lifecycle retention: passports remain live and queryable for the full regulatory lifetime applicable to each product category, in line with the relevant ESPR or sector-specific retention expectation. Lifetime is enforced even after subscription termination, for the duration of the resolver continuity window.

Default isolation is logical: every read and write is scoped by companyId, enforced at the data-access layer (not the controller). Tests verify the scope cannot be bypassed even with deliberate companyId omission in queries.

Enterprise customers can request physical isolation: their data lives in a dedicated MongoDB cluster, with a dedicated application instance. Pricing is talk-to-us; turnaround is days, not weeks.

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.

Standard liability cap: 12× monthly fees. Enterprise customers can negotiate a 24× rider for higher exposure profiles.

E&O insurance is in place; policy cap is published on the trust page. The trust page also lists indemnification carve-outs (third-party IP claims, regulatory penalties traceable to vendor error).

We publish the GS1 Digital Link conformance test result on the trust page. Schema.org JSON-LD is emitted on every public passport URL. Vocabulary alignment with CIRPASS recommendations is documented field-by-field.

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.

Customers are listed as contributors on the template's metadata block — credit and traceability for the contribution.

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.