Service catalogue for digital product passports: answers for your due diligence

The ESPR core requirements and the conformity profile for textiles, enforced before every publication unless the workspace switches the check off.

Checked before publication are the identifiers of the passport and the economic operator and, from the textile template, the fibre composition label and the technical documentation; material composition and passport level are checked as recommendations. Care instructions and further accompanying documents are available as template fields with a preset disclosure level.

As long as a delegated act is in draft, the data points it specifies are configuration in Transpareo. Whatever the final act adds arrives as an update to the conformity profile, without rebuilding the platform.

Yes. The battery data model of DIN DKE SPEC 99100 is stored in full and validated before publication.

Transpareo ships the data model defined in DIN DKE SPEC 99100 (Annex A, Table A.1), which covers the data points required by the EU Battery Regulation and the Commission’s category-specific guidelines, among them battery category, chemistry, CO2 footprint, recycled content per metal, state of health and lifetime values.

Battery passports are validated against a conformity profile of their own. Data points that the regulation reserves for readers with a legitimate interest are kept separate from the public record. A battery workspace automatically works with one passport per battery. The obligation applies from 18 February 2027.

Eleven product groups have a conformity profile today, and any other product group is represented through custom property types.

Conformity profiles exist for textiles, batteries, electronics, tyres, packaging, furniture, aluminium, iron and steel, chemicals, construction products and food contact materials. A workspace chooses its category, and the platform validates every passport against that profile.

Any other kind of product is represented by defining custom property types for products and components, each as a mandatory or optional field. A product group that regulation has not yet covered is therefore a matter of configuration.

Transpareo issues passports for the EU. One workspace per industry is recommended, because each industry template sets its own mandatory data points.

Within a workspace, further data points are added as property types, each with its own disclosure level, and every passport is validated against the conformity profile of the workspace’s category. GS1 identification, W3C Verifiable Credentials and JSON-LD vocabularies are readable worldwide.

Each template has two layers: a regulated layer set by regulation, and the customer’s own layer, which the customer extends freely.

The regulated layer: for each regulatory category, the platform keeps the data points and accompanying documents of the relevant regulation as a template, which a workspace adopts in one step. The textile set follows Regulation (EU) No 1007/2011 and the ESPR core requirements; the delegated act for textiles is still in draft. The battery set follows DIN DKE SPEC 99100 with the Commission’s category-specific mandatory rules. Type, mandatory status and vocabulary term are fixed, while the workspace can adapt name and disclosure level; the fixed term makes the passports of different brands readable with the same tools.

The customer’s own layer: the workspace defines as many custom property types of any kind as it needs, for example for footwear or accessories, beside the regulated framework. A new property type is available as soon as it is saved.

Brands, categories, property types, languages, groups, branding and domain are configuration. Every customer runs the same product: what one customer needs goes into the platform for everyone, behind configuration, so an upgrade leaves every customisation in place.

Per model, per lot or per item.

The GTIN identifies the model, also called style or SKU. A lot passport appends the lot number to the address; an item passport carries the serial number in place of the lot number. The result is one web address per passport, which any GS1-compliant scanner resolves.

The workspace sets the level, and for textiles and batteries the regulatory category presets it: one passport per production lot for textiles, one per battery for batteries. A published passport keeps the level it was published at.

Yes. The product identifiers are GS1, and the economic operator and facilities are validated against the schemes of EN 18219:2026.

The GTIN identifies the model, the lot number (AI 10) the lot, the serial number (AI 21) the item. A GTIN is checked against its check digit on entry, and a product with a wrong GTIN check digit can be neither saved nor published. The GLN of the economic operator and of facilities is likewise validated against its check digit.

Work can begin before GS1 numbers exist: a product is identified by a manufacturer part number (MPN, usually the same as the SKU), and the GTIN is added later without disturbing anything that exists.

Each level is a record of its own with its own identifier and holds what belongs to it.

The model holds what applies to the article: composition, care, origin, documents. Variants inherit from it; a differing value is set on the variant and marked as differing. A lot holds its number and manufacturing date and freezes the record as manufactured. An item inherits the frozen record of its lot; what is its own is its history of repairs, refurbishments, changes of ownership and incidents.

From a model you reach the lots produced under it, and from a lot its items; an item resolves to its lot and its model. Packaging hierarchies, that is what was packed into what, are not recorded today.

By the schemes EN 18219 permits: the economic operator with LEI or GLN, the facility with LEI, GLN or DID.

Your company’s LEI or GLN is set in the workspace settings, the manufacturer’s in its record. Both are checked against these schemes and written where the standard puts them in the passport. Further manufacturer identifiers are added as property types without development effort.

Any data carrier that can hold a web address; the platform generates the QR code itself.

Every passport of a product with a GTIN is issued as a GS1 Digital Link and delivered with a print-ready QR template, as scalable SVG, as PDF and as PNG in any size up to 2,000 pixels, with error correction level M. Illustrator and InDesign open these files directly; there is no dedicated Adobe plug-in.

Data Matrix suits a small print area, NFC tags carry an NDEF URI record, and UHF RFID inlays are read at a distance; an EPC formed from the same GTIN and serial number resolves to the same passport. Any number of carriers can encode the same address and lead to the same passport.

Yes. The address is deterministic, so a code can go to print before the product record is created.

Once the domain is configured, the address of a passport follows from the GS1 Digital Link: domain, GTIN and, depending on the level, lot or serial number. The code resolves as soon as the passport is published. The platform renders it from the first draft on, as vector SVG, as print-ready PDF and as PNG in the pixel sizes required, as a file or through the API.

Serial numbers generated in advance by a supplier are imported in bulk by file or through the API. In a workspace with one passport per item they become the serial numbers of the passports; otherwise they become serial numbers of a lot and open its passport.

In both directions, with nothing installed at the supplier and no integration with its systems.

If the supplier prints codes that Transpareo issues, the passports are created from the order data, each receives its address, and the supplier receives the set as a file or through the API together with print-ready templates. If the supplier brings its own codes, its serial numbers are imported and bound to the passports, in bulk before production or item by item through the API.

The business relationship with the supplier stays with the customer, and the platform holds the mapping between serial number and passport, so the supplier can change without touching passports already issued. Transpareo supplies the software; physical labels and data carriers come from partners or any provider the customer chooses, at that provider’s price. A consumer scan needs only the phone camera, and NFC or RFID reading uses the devices a business already has.

Each address opens the passport of its level or of the nearest level above it, so a shop can link the model’s address before anyone buys.

Where passports are issued per lot, a GTIN without a lot number opens the passport of the newest lot. A lot number opens that lot’s passport, a serial number the item passport or, in a workspace that issues per lot, the passport of the lot holding that serial number. An invented serial number opens the lot or model passport with the note that this unit has no passport of its own, and the request is logged; an unknown GTIN resolves to nothing. An SGTIN EPC read from an RFID tag, as a URN or in GS1’s compressed form, is forwarded to its GS1 Digital Link.

The resolver is built to the GS1-Conformant Resolver Standard (ISO/IEC 18975) and describes itself at /.well-known/gs1resolver on every workspace host. Machines get the identifier’s link set (RFC 9264), valid against GS1’s schema, for linkType=linkset and the older linkType=all; gs1:pip, gs1:dpp and gs1:defaultLink are followed, a link type the passport does not hold answers 404 and a malformed link 400, and every answer names the level it serves. Our own resolver answers GS1 Digital Links and GS1-encoded RFID addresses, and the passport opens at its GS1 address; a brand whose links run through a GS1 resolver points that resolver at ours, and each scan arrives here through its redirect.

Every publication freezes a new signed version under the same address, and every earlier version stays retrievable as it was published.

Each version is one W3C Verifiable Credential signed with ECDSA-SD, a selective disclosure scheme: the consumer, the recycler and the authority each receive the subset they are entitled to, and the signature remains verifiable on that subset. Each version carries the hash of the one before it, so the history cannot be rewritten unnoticed, and a manifest signed with Transpareo’s key lists every version with its hash. Every earlier version names what has changed since the previous one.

The product record behind the passport stays editable and keeps its own history: every change is logged field by field with the person or system, the time and the value before and after, and an earlier state can be restored. The product history shows who changed what, and the passport versions prove what was published on the market and when.

The identifier stays; the change is published as a new version of the same passport, and the code on the product leads to the updated state.

A new identifier is needed only if the article itself becomes a different one. That is what supersession is for: the new passport is linked to the superseded one, and whoever arrives at one finds the other.

Yes. The Transpareo Time Machine, our open-source viewer, shows every published version in the brand’s design.

The current version loads with the page, and earlier ones as soon as the timeline is opened. You swipe through the life of the product: how it was made, what was repaired, where it went. More at Transpareo Time Machine.

The lot keeps its own composition, and later product changes reach it only through a correction that signs a new version.

The SKU and its GTIN remain unchanged. On creation, a lot takes a permanent copy of the components and properties as they were actually manufactured, and later changes to the product are not written back to it. If the bill of materials of a season differs, the change is made on the model before the lot is created; further values of the run, such as test results, are set the same way and frozen by the lot. A correction of the lot takes over the corrected state of the model and signs a new version.

An item made in spring thus names its materials, and an item of the same SKU from autumn names its own, with no new SKU and no ambiguity. Earlier states remain readable through the Transpareo Time Machine.

The event is recorded on the passport, and a change of data is published as a new signed version under the same address; nothing is reissued or reprinted.

Repair, refurbishment, take-back, recycling and recall are recorded with date and actor and appear as public EPCIS events. A change of supplier or material is a data change and appears as a new version. Inspections, changes of ownership and incidents are recorded for authorities only.

Yes, with access the brand grants them.

The brand gives a repairer, refurbisher or recycler its own API credentials with the permission to record events. Each event it records carries its GLN, where one is on file, as the place where it happened, and publishing the event as a new version needs the separate permission to publish. A party without access from the brand adds nothing.

By its signature, which anyone checks without Transpareo software, API or account; if the brand chooses, it signs with keys that only it holds.

• Proof for everyone: signed with ECDSA-SD as a W3C Verifiable Credential; any conformant library verifies it.
• Verification on the reader’s side: the viewer resolves the DID document and public key and checks the signature in the browser.
• Open source: the verification path can be audited publicly and rebuilt independently.
• Own keys: the platform sends what is to be signed to a signing endpoint of the brand; private keys never reach Transpareo.

One requirement is met in part: EN 18246 asks for keys certified after an identity check, while the issuer keys are published on the issuer’s own domain without such a certificate. The physical security of the data carrier, such as anti-copy features or hardware identifiers, is supplied by the data carrier manufacturer; Transpareo does not evaluate such features today.

Forged passports fail the signature immediately; copied genuine codes show up in the scan statistics.

• Forged passport: it is not on the brand’s domain and not signed with its key; every verification fails.
• Copied genuine code: scans per passport and country appear in the scan statistics. An item passport can be suspended; every further scan then shows it as suspended.

To expose a physical clone at the moment of scanning, a feature of the data carrier that cannot be copied is needed, such as a tag hardware identifier. Transpareo does not capture or check such values today.

Yes. Each source writes the fields it is responsible for into one catalogue, through the API, spreadsheet import, the agent interface or the application manager.

Products, components, documents, media and property types sit in that one catalogue. An import matches on the identifier of the product or component and updates existing records in place, so a recurring extract from PLM or ERP keeps the catalogue up to date. Components are shared: a material corrected once reaches every product that contains it.

Every write is validated on receipt and checked against the rules of the category immediately afterwards, and every change is logged field by field with source and time. A typical division of work: the PLM supplies composition and care, the ERP provides orders, lots and serial numbers, and a supplier portal provides certificates; Transpareo assembles the passport, validates it, signs it and resolves it.

Documents are attached to products and components, and the platform generates each product’s technical documentation as a branded PDF itself.

On the product, a public document reaches the passports as a download, and each published version keeps the file it was published with; an internal one stays out of the passport. A regulated document held in a data point follows that data point’s disclosure level, so one reserved for authorities stays out of the public data. On a component, a document is public or visible only after signing in.

The technical documentation is generated from the published passport through the open-source renderer md2pdf, which applies the workspace’s branding and produces the same document in every language of the workspace, up to 40. The library is public on GitHub.

Data points are configuration: create the field, set the disclosure level, mark it as mandatory, with no platform development and no waiting for a release.

The name is entered once in your own language and translated into the others by the platform. For existing data:

• Detection: DPP readiness is recalculated across the whole catalogue straight away, 200 products per minute; every product without the new field is shown and can be filtered, and the export contains the new field for the whole catalogue.
• Back-filling: manually, by bulk import from a spreadsheet or through the API. Where the value can be derived, the assistant can draft suggestions for review.
• Published passports: they keep their version; updating is a new publication under the same URL.
• Control: field, values and every republication are recorded in the audit log and in the version history.

If an entirely new category is added, we supply the conformity profile and data points as a template, which a workspace adopts in one step.

By spreadsheet import with column mapping and preview, up to 50 MB and 100,000 rows per file, or through the API.

The importer suggests a mapping of the columns to the fields, shows before writing what each column will become and suggests the same mapping every time for identical column headings; where it recognises every column it needs, an automatic run skips the mapping step, so a recurring import is a single upload. Exports in XLSX or CSV carry the complete data set, one sheet per language, and can be imported again in the same formats. An initial load usually starts as a spreadsheet; once the structure is in place, the data is usually filled through the API.

Everything travels authenticated over HTTPS. Larger volumes go in several uploads or through the bulk API. Media are uploaded file by file, four at a time and up to 50 MB per file; exports are produced in the background at an address that expires. The operator is notified in the application manager when an import has finished or needs a decision, and, on request, also by email when it has finished. Neither FTP nor unauthenticated storage is offered.

Through a REST API, signed webhooks, an event feed, spreadsheet import and export, an MCP server for AI agents and an n8n node; no middleware is needed.

• REST API: documented, authenticated with OAuth 2.0 Client Credentials, restricted in scope per system. PLM or ERP systems create and update products, components, properties and lots, and publish passports.
• Webhooks: report lifecycle events without any need to poll; the event feed delivers the same events to systems that poll.
• Bulk import: spreadsheet or CSV for systems without an integration budget, with mapping, preview and updating of existing records.
• Agent interface (MCP): for tools where an integration project does not pay off.
• n8n node: published as @transpareo/n8n-nodes-transpareo, for workflows a team builds without programming.

The API and webhooks work in real time. Imports, exports, publication and translation run as background jobs with status polling, show their progress and block no one; a bulk publication cannot saturate the queue. Anything that speaks HTTPS can be connected, including an existing integration platform or an iPaaS. A partner system recognises the GS1 identifiers without a mapping table.

Every write is checked on arrival for the type and format of its values, and the record is then checked against the rules of its regulatory category, both when its DPP readiness is calculated and at every publication.

The check on arrival applies whether data comes through the API, an import or a person. The rules come from the category’s conformity profile, written as shapes modelled on SHACL, so they turn the regulation’s data requirements into checks. Facility identifiers are checked against the permitted schemes. Regulatory data points are held on the product and frozen at publication; compliance documents sit on the same records, and their visibility follows the disclosure level of the data point that holds them.

The check is structural: are the mandatory values present, correctly formatted and of the required type? Whether a statement is correct in substance is a review step for people, for example through the supplier page.

Every product carries a continuously recalculated DPP readiness: a percentage, a colour and the list of open checks, each with a link to the field.

Checks that block publication are kept apart from those that only improve the record. As long as a mandatory check is open, no passport can be published. A missing mandatory property is named with its type; a value rejected by the standard is reported with the rule it breaks.

Components are shared, so one change reaches every product that contains it. Lot data stays frozen, and published data changes only when the editor wants it to: a correction signs a new version, which webhooks and the event feed report.

In the catalogue, DPP readiness is a sortable and filterable column. Try it without an account: our demo.

Yes, as review flows with up to five stages, in which whoever submits a request does not decide it.

Each stage is assigned to a group or permission. As long as a mandatory review is open, publication of a passport stays blocked, and a publication triggered by a connected AI agent goes through the same flow. Access can be limited to individual products or components. Versioned workflow templates do not exist yet; where a customer needs particular steps, we build them into the product.

Yes. Tasks go to people or groups, a daily email tells each person their new and overdue tasks, and information requests to suppliers carry deadlines and reminders of their own.

Automatic escalation to further people is on the roadmap. Tasks can be queried through the API, and webhooks and the event feed report every status change of a passport, so an external workflow tool, such as n8n with the Transpareo node, can react to them.

The configurable product table, the task and request lists and the statistics page; every data set can be exported.

• Catalogue: each person chooses their own columns, including the DPP readiness; saved views keep queries for the whole team. Components are searched by name, type and properties, passports by identifier, status (from draft to end of life), version, invalidity and lot or item.
• Work in progress: the task and request lists show overdue tasks, tasks without an assignee, expired requests and answers awaiting review.
• Consumers: scans per passport, region and period, from server logs without tracking, downloadable from the statistics page.
• Exports: products, components and passports as complete records in CSV, XLSX, JSON-LD or SQL, whatever columns and filters are set on screen.

Through the API, passports can be queried by product, status and search term, and catalogue, passports and the scan figures per passport are available to customers with their own BI tools. Demo: our demo.

Each workspace’s product and passport data lie in a database of its own; only account and plan data sit in the shared platform database.

The search index, signing key and encryption key are also separate per workspace; media and the passport archive sit under a separate path per workspace.

Yes, at two levels: sensitive fields and backups.

• Fields: AES-256-GCM with one key per workspace, which is itself wrapped with a key derived from the server’s master secret; rotating the master secret re-wraps every workspace key it protects without re-encrypting the data. Protected values include the AI provider key. The workspace’s signing key is wrapped with a second workspace key reserved for it.
• Backups: encrypted with AES-256 before they leave the host.

Media and the passport archive are held in object storage in the EU, and the archive of a paying workspace is write-once for ten years.

Email and password with a passkey or a time-based code as the second factor, which the workspace can require; the workspace sets the period of inactivity before sign-out.

The default is 480 minutes; the workspace can set the duration freely. The session is ended on the server; our demo workspace runs with 60 minutes. In addition, the session cookie expires when the browser is closed. An encrypted session cookie marked as secure carries the session, and a language cookie the chosen language; there are no third-party cookies.

Users are invited and assigned to access groups; removing a user revokes access and API credentials immediately. There are no generic or shared accounts. Each user’s last sign-in is shown; automatic deactivation of accounts that have long been inactive is on the roadmap.

Three records: the audit log (five years), the security log under NIS2 (365 days) and a log of all authority access, which we export on request.

The audit log states who changed what and when, field by field, with the value before and after, and can be filtered on screen by period, record or actor. The security log records sign-ins (successful or rejected), multi-factor challenges, password resets, account lockouts, rejected API credentials, blocked addresses and rejected agent calls; it is searchable in the application manager.

Personal data in operational logs is kept only as long as its purpose requires (Art. 5(1)(e) GDPR). Passports are exported as signed artefacts that an authority verifies without our software; logs as CSV or XLSX.

We inform the customer without undue delay of any security incident that affects its workspace, whether or not personal data is involved, and anyone can report a vulnerability to support@mail.transpareo.com.

For a personal data breach, the notification follows Clause 9 of our data processing agreement: it describes the nature of the breach, its likely consequences and the measures taken, names a contact point and states when the breach occurred and was discovered and which workspaces it concerns. What is not known at first follows as soon as it is.

Only through a login on the customer’s behalf, which is recorded in the platform log and in the workspace’s own security log.

The customer reads every such login in its security log. Staff are screened before they receive access and trained in security regularly. They are bound to confidentiality and receive access only as far as running and supporting the contract requires (Clause 7.4(b) of the data processing agreement).

Support by email at support@mail.transpareo.com, in German and English, included in every plan.

There is no separate support contract and no support billed by effort. In the application manager, help articles are searchable and appear in the operator’s language, beside the API guide. With the workspace’s own AI access, the assistant answers from both, can point to the article and, after confirmation, carry out the described step straight away with the person’s permissions.

Yes, the platform is live: anyone can sign up, and each passport is generated, validated, signed and published under its permanent address.

What it does can be tried without an account in our demo.

A fixed monthly plan per workspace by number of passports, with no setup, consulting, user or scan fees and no paid add-on modules.

The data carrier plays no part in the price, and scans, traffic and storage are never counted. Every plan includes the full feature set with your own domain, 40 languages and the complete API, so every function in this catalogue is also available in the smallest plan; the only cost outside the plan is the AI provider’s charge when a customer uses the assistant with its own account. Billing is monthly with no minimum term.

Four plans in francs, euros or dollars: up to 100 passports, up to 1,000, up to 10,000 and unlimited, each with unlimited products and components. During the beta phase, a discount of 30 % on the list prices applies, and the price at which you sign up stays your price for as long as you keep the plan. A non-binding trial of eight days is possible. The current price list on our pricing page applies.

We build the workspace with the customer’s data, property types, branding and domain, and the first passports are live within days.

A new workspace is ready in minutes on a Transpareo address; the customer’s own domain follows as soon as its DNS record points to us. On the customer’s side a current browser is all it takes, on Windows, macOS, Linux, iOS or Android; there is nothing to install or operate.

• Supply chain onboarding: through the supplier page, in the workspace’s languages.
• Integration: the REST API, webhooks, MCP server and n8n node are looked after by the people who wrote them.

In addition, there are tools at no extra cost: branded documents in 40 languages, the Transpareo Time Machine as a trust factor and traffic statistics without tracking.

Our terms of service under Swiss law: notice to the end of the monthly billing period, no minimum term, and liability for slight negligence limited to the fees of the last twelve months.

• Notice: the plan runs for an indefinite period and can be terminated at any time with effect from the end of the current billing period.
• Liability: unlimited for intent and gross negligence; for slight negligence only for breach of material contractual obligations, limited to the typically foreseeable damage and in total to the fees paid in the twelve months before the damaging event. Lost profit, data loss and consequential damage are excluded as far as the law permits.
• Changes: changes to the terms and to prices are announced in text form at least 30 days before they take effect, with the right to object to changed terms and to terminate before a price change.
• Law and jurisdiction: Swiss law, excluding the UN Convention on Contracts for the International Sale of Goods; the place of jurisdiction is Zug, Switzerland.
• Data protection: the data processing agreement forms part of the terms.

The customer remains the economic operator and is responsible for the content of its passports; Transpareo provides the technical platform.

We sit on the committees where the rules are made, and we implement what they publish.

• European standardisation: a seat on the national standards committee of the Swiss Association for Standardization (SNV) and its subcommittee on the DPP, the Swiss voice in CEN/CLC/JTC 24, the committee drafting the European DPP series of standards. We see the drafts as they take shape and comment on them.
• EU pilot projects: member of the Community of Practice of CIRPASS-2, the EU project that is trialling the Digital Product Passport in four value chains.
• Protocol work: ongoing contribution to the UN Transparency Protocol; six of our comments on version 0.7.0 are in the public register.
• Battery passport: supporting partner of the Battery Pass consortium, which, together with leading research institutions, is building the test environment for the EU battery passport, funded by the German Federal Ministry for Economic Affairs and Energy. Batteries are the first product group with a binding obligation, from 18 February 2027.

51 % of the share capital is held by the non-profit Transpareo Foundation in Zug; this holding cannot be sold, and Transpareo cannot be taken over.

The foundation is under the supervision of the Swiss Federal Foundation Supervisory Authority. The experience reaches beyond regulation: the founder’s first product transparency platform has been running for cosmetics manufacturers since 2008.