Issue passports at scale. Schema-correct, signed, verifiable.
Single, batch or bulk CSV — every passport is mapped to the right delegated act, cryptographically signed, and published to a public verification URL the moment it is issued.
- 500 free for 90 days
- ESPR-ready · 4 delegated acts
- GS1 + DataMatrix native
A live surface, not a slide.
A real batch run as it executes: schemas validated, signatures applied, QR codes generated and public URLs published — at roughly 14 SKUs per second.
- Total SKUs
- 487
- Validated
- 487
- Signed
- 312
- Published
- 312
- passport.signedVOLTA-9821-LIB0.4s ago
- passport.publishedMAISN-3304-TXT0.7s ago
- qr.generatedKURO-7712-MOB0.9s ago
- passport.signedHALIN-2204-TOY1.2s ago
Four properties that hold from one SKU to a hundred thousand.
Built for volume.
Issue 500+ passports in under thirty seconds. Single click, batch run or bulk CSV — same throughput, same guarantees, same signing chain.
Mapped per category.
Every record is auto-mapped to ESPR core plus the active delegated act for its category — Battery, Textiles, Electronics or Toys. Schema drift is caught at validate, not after publish.
Immutable by default.
Every revision is a new cryptographically signed record. Previous versions are retained verbatim. The audit trail is the source of truth, not a log file.
Public on day one.
Each issued passport gets a public AAA-accessible URL with a QR. Auditors, distributors and consumers verify in one tap — no login, no portal, no waiting on us.
Pick the surface that fits the workflow.
Issue from the console.
Sign in, pick a SKU template, hit issue. For small batches, ad-hoc fixes and the moments before a product ships.
Learn howPOST /v1/passports.
REST or webhook-driven from your ERP, PLM, PIM or CI. Idempotent, schema-versioned, and signed at the response boundary.
Read the API referenceDrop a CSV, ship a batch.
Every row is validated against the active schema in-flight. Bad rows surface inline; valid rows go straight to sign and publish on submit.
See the CSV formatThree steps from system of record to public passport.
- 01Step
Map.
Connect your ERP, PLM or PIM (60+ native integrations). Field-map once per SKU category — the platform remembers the mapping for every batch that follows.
- 02Step
Validate.
Every record is checked against the active delegated-act schema in real time. Bad rows surface inline with a clear reason; valid rows go straight through to sign.
- 03Step
Sign + publish.
Cryptographic signature, immutable revision, public AAA-accessible URL, QR generated. All in one transaction — never half-published.
Issue from any system you already run.
A single POST creates a passport, signs it, indexes it, and returns a public verification URL. Drive it from your ERP, your PIM, a CI job or a Zapier step — the contract is the same.
curl -X POST https://api.dppautomate.eu/v1/passports \
-H "Authorization: Bearer $DPP_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"gtin": "07612345678901",
"category": "battery",
"regulation": "EU 2023/1542",
"manufacturer": "Volta Cell GmbH",
"placed_on_market": "2027-02-18",
"schema_version": "battery@1.2",
"metadata": { "model": "LiB-4.2kWh", "chemistry": "LFP" }
}'What every issued passport carries by default.
ESPR-ready
Core schema plus the four live delegated acts: Battery, Textiles, Electronics, Toys. New acts shipped as they land.
GS1 + DataMatrix native
GTIN, SGTIN and DataMatrix-encoded identifiers built into the schema. No bolt-on identity layer.
Cryptographically signed
Every passport — and every revision of every passport — is signed. Tamper-evident from the moment it is issued.
Immutable revisions
Versions accumulate; nothing is ever overwritten. Every change is a new signed record on the same passport ID.
Public verification URLs
AAA-accessible passport URLs, hreflang-served in 24 languages, with a QR generated at issuance.
Per-passport pricing
Pay for what you issue, never per seat. Unlimited team members on every plan.
The questions
product teams actually ask.
Six recurring questions from product, compliance and supply-chain teams running their first bulk issuance. If yours is not here, the contact form goes to a person.
Book a working session →What is the real throughput on bulk issuance?+
On the standard plan, the platform sustains roughly fourteen SKUs per second of signed, published throughput — so a five-hundred-row CSV finishes in under thirty seconds. Enterprise customers run dedicated signing workers and have benchmarked at over a hundred SKUs per second. The bottleneck in practice is almost always schema validation upstream, not the signing pipeline.
Can we issue passports before the delegated-act schema is fully finalised?+
Yes. The platform ships a draft mode for every delegated act that is in active rulemaking — Toys, the next Electronics revision, the textiles minor amendments. Draft passports are signed against the candidate schema and marked clearly as draft on the public URL. When the act is finalised, the platform auto-migrates the records and re-signs against the final schema. The original draft signature is retained in the revision history.
What happens when the schema changes mid-cycle?+
When a delegated act ships an update, we publish the new schema version and mark the previous version as superseded. Existing passports keep their original signatures and remain valid against the version they were issued under. You can re-issue at the new version at your own pace; nothing forces a stampede. The public URL surfaces both the issued version and the current canonical version so auditors can trace exactly what changed and when.
How are duplicate-SKU collisions handled?+
Every passport carries a stable platform-side ID (`pst_*`) plus the customer-side identifier (typically GTIN or SKU). If you POST a passport for an SKU that already has an issued record, the platform treats it as a new revision on the existing passport — not a duplicate. The old revision is retained verbatim; the new one becomes canonical at the same public URL. Idempotency keys are supported so a retried call never accidentally creates a second record.
Can I issue draft or preview passports without publishing?+
Yes. Set `status: "draft"` on the issuance request and the passport is signed but the public URL returns a private-access page that requires the issuer-side token. Useful for internal review, regulator pre-checks, and supplier walkthroughs. A single API call (or one click in the console) promotes the draft to published — same signature, same revision, no second signing ceremony.
Does the public passport URL change when we issue a new revision?+
No. The public URL is stable for the lifetime of the passport. A new revision becomes the canonical content at that URL; older revisions are still reachable by appending the version (`/p/pst_*/v3`). QR codes printed on the product never go stale — they point at the same URL whether you re-issue once or fifty times.