Keeping Your Digital Product Passport Up to Date: How the Update Workflow Works

Why Updating a Digital Product Passport Is More Than Changing a Database Field

A Digital Product Passport (DPP) is not a static document. It accompanies a product throughout its entire lifecycle — from production through retail, on to repair, and finally to recycling. This requirement flows directly from the Ecodesign for Sustainable Products Regulation (ESPR), which has been in force since April 2024 and is being phased in across product categories.

For businesses, this means: creating a DPP once is not enough. Repair records get added, certificates expire, supply chain data shifts. At the same time, the change history must never be lost — auditors and market surveillance authorities need to be able to trace who changed what and when.

This article walks through the technical and organizational process of a DPP update: which fields can change, which cannot, how the GS1 Digital Link fits into the picture, and how to structure a bulk update across a large product catalog.

What Can Change — and What Cannot

Immutable Core Data

Certain identifiers are locked after initial certification. The GTIN (Global Trade Item Number) uniquely identifies a product within the GS1 system and cannot be swapped out after the fact. Likewise, a serial number is considered immutable once it has been assigned to a physical object. This is not an oversight — it is by design: traceability along the supply chain depends on exactly this stability.

The primary QR code resolver entry — that is, the URL a GS1 Digital Link points to — should also not be changed once it has been printed on packaging. Instead, you update the destination behind the resolver, not the code itself. This is the key advantage of dynamic QR codes over static ones: the printed code stays the same while the underlying data can evolve.

Updatable Fields

The following data categories are typically intended for updates:

• Repair and maintenance data: Which components were replaced, when, and by whom?
• Certificates and conformity documentation: Expiration dates, new test reports
• Recycling instructions: May change as new end-of-life infrastructure comes online
• Carbon footprint: Refined over the course of the supply chain (e.g., after actual transport data is available)
• Retailer and distribution data: New markets, new distribution partners

The ESPR requires that this information be "current, complete, and accurate" — without specifying a concrete update cadence. In practice, industry associations such as EURATEX recommend quarterly reviews for the textile sector, particularly because supply chains are shifting rapidly under current conditions.

The Technical Update Workflow in Detail

Step 1: Document the Change Request

Before a single database field is touched, the change request needs to go into a ticketing system. Who is changing what, and on what basis (new certificate, supplier change, repair)? This is not bureaucracy for its own sake — it is the foundation of the audit trail that market surveillance authorities may require.

Step 2: API Call or Bulk Import

For individual products, a targeted PATCH request to the DPP API is the right approach. A minimal example in TypeScript:

const response = await fetch(
  `https://api.qr3.app/v1/passports/${passportId}`,
  {
    method: "PATCH",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${API_KEY}`,
    },
    body: JSON.stringify({
      sustainability: {
        carbonFootprintKgCO2e: 4.2,
        updatedAt: new Date().toISOString(),
        updatedBy: "supplier-audit-2025-q2",
      },
    }),
  }
);

if (!response.ok) {
  throw new Error(`Update fehlgeschlagen: ${response.status}`);
}

For updating many products at once, a bulk import is more efficient. You upload a CSV or JSON file containing only the fields to be changed — not the entire passport. This minimizes error sources and keeps the payload small.

curl -X POST https://api.qr3.app/v1/passports/bulk-update \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: multipart/form-data" \
  -F "file=@updates_q2_2025.csv" \
  -F "dryRun=true"

The dryRun=true flag is important: it validates the file without writing anything. Only after manual approval is the actual import triggered.

Step 3: Versioning and Audit Trail

Every successful change creates a new version row. The underlying database schema follows a simple principle — append-only:

INSERT INTO passport_versions (
  passport_id,
  version_number,
  changed_fields,
  changed_by,
  changed_at,
  previous_hash,
  new_hash
)
VALUES (
  $1, $2, $3::jsonb, $4, NOW(), $5, $6
);

The hash mechanism ensures that retroactive tampering is detectable. Each version references the hash of the previous one — similar to a blockchain, but without the overhead of a public chain.

Step 4: Invalidate the Resolver Cache

After an update, the GS1 Digital Link Resolver must invalidate its cache for the affected GTIN/serial number entry. Otherwise, users who scan the QR code will still see stale data. Typical cache TTLs are 5–15 minutes; for time-critical updates (e.g., a product recall), an immediate invalidation should be triggered via API.

Special Considerations for the Textile Industry

The European textile industry is under considerable pressure. EURATEX reports that the sector has been shrinking for the third consecutive year — factories are closing, supply chains are relocating. It is precisely during such periods that DPP-relevant changes pile up: a supplier drops out, another takes over, certificates need to be reissued.

The ESPR delegated regulation for textiles (priority from 2026 onward) requires information on fiber composition, country of production, and recyclability, among other things. All of these are fields that can change when a supplier changes. Companies should therefore establish processes now that automatically trigger a DPP update request whenever such a change occurs — rather than treating it as manual follow-up work.

A pragmatic approach: webhook integration with your ERP system. As soon as a new supplier is created in the ERP and assigned to a product, a webhook fires and kicks off a DPP update workflow.

// ERP webhook handler (simplified)
app.post("/webhooks/supplier-change", async (req, res) => {
  const { productId, newSupplierId, effectiveDate } = req.body;

  await dppUpdateQueue.add({
    passportId: await resolvePassportId(productId),
    fields: {
      supplyChain: {
        primarySupplier: newSupplierId,
        supplierChangeDate: effectiveDate,
      },
    },
    requiresReview: true, // Manual approval before publishing
  });

  res.status(202).json({ queued: true });
});

Governance: Who Can Change What?

A DPP update is not a trivial technical task. The ESPR holds the economic operator placing the product on the market responsible for the accuracy of the data. That means not every employee should be able to edit arbitrary fields.

A role-based model is recommended:

This table covers three meaningful dimensions (role, fields, approval) — it is purposefully structured, not bloated.

Conclusion: Updates Are the Norm, Not the Exception

The Digital Product Passport is not a one-time compliance document you check off and forget. It lives. Once you understand that, you build processes from the start that support updates — with clear ownership, technical versioning, and automated triggers from the ERP.

The textile industry is a particularly vivid example: in a sector that is structurally under pressure and where supply chains shift frequently, a robust update workflow is not a nice-to-have — it is an operational necessity. The regulatory requirements of the ESPR and its associated delegated regulations will only tighten these demands in the years ahead.