Regulatory boundary
The Integration API (Phase 1 core and Phase 1.5 endpoints) is GA on production (app.traceable.digital) as of v0.99.6.1. The API returns 503 FEATURE_DISABLED on any environment where it is not enabled. See Availability.
The Integration API is designed around the obligations imposed by EU Battery Regulation 2023/1542 (and its implementing acts). This page explains the regulatory constraints that shape what the API can and cannot do, and why some of those constraints are deliberate design choices rooted in the Regulation, not merely Phase 1 limitations.
The API cannot publish
Every write through the Integration API terminates at Submitted status. There is no API call that transitions a DPP to Approved or Published.
This is required by Art. 77 of EU Regulation 2023/1542. The regulation requires that each Digital Product Passport record carry the attribution of a natural person (the economic operator responsible for placing the battery on the market). A service account or API key is not a natural person. The human who reviews and publishes the DPP in the Traceable portal is the named responsible party; that attribution is recorded on the tamper-evident audit chain.
Attempting to create an API path that publishes on behalf of a service account would violate this attribution requirement. There is no dpp:publish scope in Phase 1: publication is deliberately a human action in the portal today. (A future phase may introduce operator-controlled publish-via-API; it is not available today.)
Art. 38 — Economic operator responsibility
The Economic Operator (typically the battery manufacturer or EU-market importer) is the entity legally responsible for the DPP. This is the company whose Traceable operator account holds the Integration API key. Data written through the API is attributed to that operator account, not to the third-party ERP system or integration vendor that makes the API call.
If your integration writes incorrect data to a DPP, the economic operator (your customer) is the party whose compliance record reflects that data. Ensure your field mapping and data quality controls are robust before submitting for review.
Art. 77 — Attribution and audit trail
Every write through the Integration API is recorded on the platform audit chain with attribution to the named person who minted the API key. The audit trail is tamper-evident. If a key is shared across multiple systems or users, the attribution granularity is limited to the key holder.
Recommendation: mint a separate key for each integration point and name each key to identify its source (e.g. odoo-prod-erp, plm-system). This preserves per-system attribution in the audit trail.
Annex XIII — Field completeness at submission
The EU Battery Regulation Annex XIII specifies the mandatory data attributes for each battery category (EV, LMT, Industrial, Stationary, SLI, Portable). The API enforces this at the submit step. A 422 SUBMIT_BLOCKED response lists the specific mandatory fields that are missing.
The gate is date-aware: it does not block a field whose underlying obligation has not yet reached its compliance date under the Regulation. Carbon footprint (Art. 7(1), suspended pending the implementing act per the Commission's 28 July 2026 data-points guidance, for all categories including EV), supply chain due diligence (Art. 48, postponed by Regulation (EU) 2025/1561), and the recycled-content declarations (per the guidance's 15 August 2026 update) are the obligation groups this currently affects; see Enforcement timeline for the exact dates per category. Two things stay constant regardless of date:
- Suspension is dated, not permanent. Each suppressed obligation carries its recorded resume date, and blocking resumes automatically on that date. Data a caller does submit in a suspended section is still validated for internal consistency.
- An unresolved or unknown battery category fails closed. If the gate cannot determine which category a product belongs to, it treats every mandatory field as blocking rather than assuming a date-gated obligation does not apply.
For voluntary-scope categories (SLI, portable, industrial ≤2 kWh), which have no Art. 77(1) passport obligation, the gate additionally applies the voluntary rule-set: only a fixed safety and consumer-information keep-list of fields remains required, and the gap list a GET /products/{id}/gate call returns reflects that reduced set.
The gate endpoint (GET /api/v1/products/{id}/gate) provides the same check before submission so you can surface gaps to your user early, rather than discovering them at submit time. A field that is not yet due appears in the gate response as informational, not as a blocking gap.
Do not retry-loop on a 422 SUBMIT_BLOCKED. The list of missing fields does not change until you supply the missing data through PATCH or document upload, or until a date-gated obligation's compliance date arrives.
Art. 67 — GTIN and GS1 registration
The DPP GTIN must be a valid GS1-registered identifier (EAN-13, 13 digits). A GTIN is required for publication. Providing a GTIN that is not registered under a GS1-licensed prefix is a field-level compliance gap that the gate will flag.
Operators manage their GS1 prefix registration in the Traceable portal under Settings → GS1 Prefixes. The API does not mint or validate GS1 prefix registrations.
Carbon footprint methodology
For battery categories where a carbon footprint declaration is mandatory, EU Battery Regulation 2023/1542 requires the value to be calculated using the methodology set out in the Commission's implementing measures (life-cycle based, with the prescribed system boundary and reference values). The carbon footprint is more than a number: it is a declaration computed a specific way.
The Integration API ingests the declared carbon footprint value and its supporting fields (for example the methodology reference and any verification details) as data. It does not compute the carbon footprint for you, and it does not certify that your calculation followed the prescribed methodology. Responsibility for using the correct methodology rests with the economic operator. As with every other field, the value is evaluated downstream by the publish gate and the human reviewer, not validated by the act of ingestion. Submit the figure you have calculated and declared, not a placeholder.
EU data residency and GDPR
All DPP data written through the Integration API is stored within EU data centres. The data residency policy for Traceable is described in the GDPR and Data Processing section of this guide.
Art. 13 and language requirements
The EU Battery Regulation and its implementing acts impose language requirements on specific fields (particularly consumer-facing fields on DPPs that must be available in the language(s) of the relevant member state(s)). The Integration API accepts data in any language. Ensuring that consumer-facing fields meet the applicable language requirements is the responsibility of the economic operator.
No compliance claims by proxy
Ingesting data through the Integration API does not constitute a claim that the data meets EU Battery Regulation requirements. Regulatory conformance is evaluated by:
- The publish gate (automated field completeness check against Annex XIII)
- The human reviewer in the Traceable portal
- The verifier (where applicable) who signs off on specific technical claims
The act of submitting data through the API is a data transfer. The act of publishing a DPP is a regulatory declaration made by the economic operator. These are distinct steps for a reason.
Withdrawal
Withdrawing a published DPP is available over the API as of Phase 1.5: POST /api/v1/products/{id}/withdraw (dpp:withdraw). After withdrawal, the public DPP returns HTTP 410 Gone, the correct response for a passport that has been pulled. Withdrawal uses its own least-privilege scope, separate from dpp:submit, so you can grant the ability to pull a passport without granting the ability to submit one. This endpoint is GA on production as of v0.99.6.1; see Availability.
There is no single article that withdrawal happens "under". The legal basis depends on the withdrawal reason you supply, and for the six commercial reasons — end of life, market withdrawal, supersession, customer complaint, operator request, and informal regulatory direction — the platform asserts no regulatory basis, because citing one would publicly claim a non-conformity that did not occur, to an audience that includes market-surveillance authorities. Where a basis does apply, the withdrawn passport page states it.
Amendments to already-published data remain operator actions in the portal. A submitted DPP that a reviewer returns for revision can be updated via PATCH while it is in Draft state.