---
title: DPP vendor evaluation — our answers
description: "Procurement-grade answers to every question a buyer should ask a DPP vendor: APIs, GS1 resolver, Battery Regulation articles, exit terms, pricing, GDPR."
canonical: "https://www.tracepass.eu/buyers-guide"
locale: en
source: "https://www.tracepass.eu/buyers-guide"
---

# DPP vendor evaluation — our answers

> Procurement-grade answers to every question a buyer should ask a DPP vendor: APIs, GS1 resolver, Battery Regulation articles, exit terms, pricing, GDPR.

The questions a buyer should ask any DPP vendor before signing — and how TracePass answers each. Forward this to your procurement, compliance, and engineering teams; every answer carries evidence.

## Do you have public APIs?

**TL;DR:** REST + OpenAPI. Read and write across passports, products, and templates.

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.

Some vendors expose only public-passport read endpoints. "We have an API" can mean a single GET — push for write coverage and a published spec.

## Can you bulk-import passports via CSV or API?

**TL;DR:** Per-category CSV templates and a bulk-import endpoint. UI drop-zone for non-technical users.

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.

Generic, schema-agnostic CSV imports usually require weeks of mapping per category. Per-category templates collapse that to minutes.

## Who owns the GS1 resolver — and what happens if I leave?

**TL;DR:** Custom domain on every paid plan. URL portability is permanent because the domain is yours; 30-day post-termination grace at no cost.

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.

Some vendors print their own domain on the QR code without exit clauses. In that model, exit means physically reprinting every product ever shipped.

## Do you support EPCIS for supply-chain event tracking?

**TL;DR:** Yes — full EPCIS 2.0 (export, capture, query) included on every paid plan. Volume meter by tier (1k events/mo on Basic up to 10M on Pro, unlimited on Enterprise). No add-on, no "talk to us" tax.

EPCIS 2.0 export, capture, and query are all included on every paid plan. 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.

Most EPCIS vendors are quote-only — Tracelink, rfXcel/Antares Vision, Evrythng, OpenEPCIS-as-a-service all gate pricing behind sales calls. Published per-tier event quotas with hard overage rates are the cheap signal that a vendor is serious about transparent SaaS pricing, not a one-off enterprise contract dressed up as a product page.

## Can an AI assistant connect to the platform directly?

**TL;DR:** Yes — a Model Context Protocol (MCP) server. Hosted endpoint or local npm package; uses your existing API key.

TracePass ships a Model Context Protocol server. Two ways to use it: a hosted endpoint you point an MCP client at, or a local npm package run via npx. It authenticates with the same API key as the REST API, so it's available on every plan.

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.

MCP support is rare among DPP vendors today — most have only a REST API. If conversational / agent-driven workflows matter to your team, a real MCP server (not a roadmap promise) is worth probing for.

## Is there a no-code automation integration (n8n / Zapier / Make)?

**TL;DR:** Yes — a free n8n community node: n8n-nodes-tracepass. Install from any n8n instance.

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.

A verified n8n community node is a small thing that signals a vendor takes the long-tail of integrations seriously. The verification standard means it gets discoverable inside n8n's UI rather than buried behind self-host config.

## Do you support serial-level passports?

**TL;DR:** Native. gs1.serialNumber is the canonical primary join key.

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.

Vendors built around SKU-level data models retrofit serial as a custom field, which breaks bulk operations and analytics. Serial-first vs serial-as-afterthought is visible in the API shape.

## Are passport edits versioned and auditable?

**TL;DR:** Every edit audit-logged. Version timeline visible per passport. Authority queries can specify a version.

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.

"We have an audit log" without UI surfacing usually means raw database records nobody can read. Auditors want timeline views, not log-aggregator queries.

## Can I export my data?

**TL;DR:** Full JSON-LD per passport. Tenant-wide bulk export. Media included with stable URLs.

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.

Export is the single feature most vendors haven't actually built — they discover the gap when the first customer asks to leave.

## Which exact Battery Regulation articles are supported?

**TL;DR:** Article-level mapping for 6 (carbon footprint), 7 (recycled content), 11 (removability), 14 (state of health), 77 (DPP).

Our battery template models all five core articles: 6 (carbon footprint declaration), 7 (recycled content thresholds), 11 (removability and replaceability information), 14 (state-of-health for industrial and EV batteries), 77 (DPP fields including QR code, supplier identification, and lifecycle status).

Implementing acts continue to refine some thresholds — recycled-content percentages and SOH measurement methodology in particular. We track every change in the Regulatory Changelog and version-bump the schema when material.

Full article coverage is rare; partial-with-roadmap is more honest than blanket "compliant."

## Which ESPR delegated acts have you modelled?

**TL;DR:** Per-template matrix: jewellery, chemicals, furniture, tyres, electronics. Speculative ahead of final acts; explicitly labelled.

We ship templates for jewellery, chemicals, furniture, tyres, and electronics. Each template maps to the proposed delegated-act fields known at the time of release; speculative fields are flagged in the schema metadata.

When a delegated act is finalised, our normal versioning flow applies: in-flight passports stay valid against their original schema until amended; the new version becomes available for new passports immediately.

Vendors who claim "we already support all ESPR delegated acts" are claiming something that doesn't yet exist — the acts are still being drafted.

## How do you update schemas as regulation evolves?

**TL;DR:** Versioned templates. Public regulatory changelog. In-flight passports unaffected by amendments.

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.

Vendors that say "we'll let you know" pass migration cost back to you. Versioned templates make a regulatory amendment a 30-minute review instead of a project.

## Can authorities query machine-readable endpoints?

**TL;DR:** JSON-LD via content negotiation on every public passport URL. GS1 Digital Link conformant.

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.

Vendors who serve text/html only at the passport URL fail the basic interoperability test.

## Does the passport identify all economic operators a regulator expects?

**TL;DR:** Yes. Manufacturer + recycler + producer-responsibility-organisation + importer + authorised representative + distributor as a structured roles map keyed on validated GS1 GLNs. Per-category required-role enforcement matches each regulation.

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

Most DPP vendors today model only the manufacturer as a free-text string. A buyer running GS1-native master data needs the full economic-operator chain validated and structured — single-string manufacturer fields don't survive procurement at any GS1-keyed enterprise.

## What's your SLA?

**TL;DR:** 99.9% portal, 99.95% resolver. Resolver is split out because regulators query it directly.

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.

A single SLA across portal and resolver hides the asymmetric risk: the resolver is the part that can't go down without regulatory consequence.

## Where is data hosted?

**TL;DR:** EU-only. Primary database in Frankfurt; CDN, email, monitoring all in EU.

Primary database: self-hosted MongoDB on Hetzner Falkenstein (Germany). Application runtime: Vercel EU edge regions. Email delivery: Resend (EU). 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.

A US-headquartered vendor with an "EU region" toggle is not the same as an EU-resident operation; check sub-processors carefully.

## How do you handle GDPR — data subject access, deletion, sub-processor disclosure?

**TL;DR:** DPA in place. Sub-processor register published. SAR and erasure endpoints exist. 72-hour breach notification.

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.

Most DPP fields are not personal data, so GDPR risk concentrates in scan analytics. Vendors that log IP, user-agent, and referrer on every scan create exposure your privacy team should know about.

## What are your backup and retention policies?

**TL;DR:** Operational backups (30-day PITR) and category-aligned product-lifecycle retention tracked separately.

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

"Backed up nightly" is not the answer to this question. The relevant policy is whether the passport is still resolvable in year 12 of the product's life.

## How is tenant data isolated?

**TL;DR:** Logical isolation (companyId scope) by default. Physical isolation tier on Enterprise.

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.

Logical isolation enforced only at controllers (not the data layer) creates real leak risk; ask where the scope is applied.

## Per passport, scan, SKU, or serial — how does pricing work?

**TL;DR:** Tiered passport allowance. Never per scan. Serial-volume bundle for high-volume manufacturers.

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.

Per-scan pricing is the most dangerous model in DPP — scan rates are determined by your customers, not you. Per-passport tiers tie the bill to what you control: catalogue size.

## What does exit and migration look like?

**TL;DR:** Full JSON-LD export, no fee. 30-day post-termination grace for the resolver. Customer-as-controller throughout. Optional source escrow.

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.

Migration support without resolver continuity is migration support that bricks your QR codes. Always read the resolver clause first.

## What are your liability terms and do you carry E&O insurance?

**TL;DR:** 12× monthly cap default; 24× rider on Enterprise. E&O insurance in place; cap published.

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

Most SaaS caps liability at 12× monthly. For an EU manufacturer with potential fine exposure, that's small comfort — push for an explicit rider.

## If we leave, what's actually ours — the data, the URL, the passports?

**TL;DR:** All of it. You own the data (full JSON-LD export, no fee), the URL (custom-domain resolver), and the provenance (per-field audit trail). No exit fee, no resolver hostage.

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, plus per-category CSV that round-trips with any ERP/PIM. 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.

"You own your data" is table stakes and easy to say. The questions that separate vendors are who owns the resolver URL on the printed QR, and what happens to a 20-year passport if the vendor doesn't last 20 years. If those two aren't answered in writing, the data export doesn't matter.

## Decentralised identifiers and verifiable credentials — on roadmap?

**TL;DR:** On roadmap. EBSI direction. Built on first prospect requirement.

DID/VC support is not in the current product. The architecture is compatible — passport documents are content-addressable, edits are signed, and the schema can carry credential proofs as an additional field set.

Trigger to ship: first deal that raises VC issuance as a hard requirement. Design notes available on request.

Vendors claiming live VC support today are usually demoing prototypes. The EBSI ecosystem itself is still pre-production for most use cases.

## Can passports be timestamped or notarised for tamper-evidence?

**TL;DR:** Per-field audit trail with timestamp and actor; visible in passport history. Cryptographic anchoring + third-party notarisation on roadmap.

Every field write goes through a single update path that appends an audit entry — timestamp, actor, previous value, source (manual / AI / API / supplier). The per-field history is queryable via API and visible in the passport version timeline. Entries are append-only by application convention.

Cryptographic anchoring (a content-hash chain over each passport's audit entries, optionally co-signed by a trusted timestamping authority or a public ledger) is on the roadmap and not yet built. Trigger: first prospect that requires it for a regulator-defended tamper-evidence story. Until then, the audit trail is verifiable against our database, not independently — call this out explicitly in any RFP response that asks for tamper-evidence.

An audit log without cryptographic snapshots is verifiable only against the vendor's own database — the vendor could rewrite it if compelled.

## Conformance against published interoperability standards?

**TL;DR:** GS1 Digital Link conformance result published. CIRPASS-aligned vocabulary. Schema.org JSON-LD + GS1 vocabulary (gs1:partyGLN) on every passport. Validated GLN identifiers per economic-operator role.

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.

"We follow the spec" is not a conformance claim. Look for tested results, not stated intent.

## Can prospects influence schema decisions for pre-final delegated acts?

**TL;DR:** Yes. Pro/Enterprise prospects shape pre-final delegated-act templates through a documented mechanism.

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.

Vendor roadmap-as-influence is a feature for buyers with regulatory expertise, not a downgrade.

## Source escrow if you go bust?

**TL;DR:** Available on Enterprise. Tagged source held by independent third party with defined release triggers.

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.

Source escrow with no defined release triggers is theatre; the triggers are the substance.