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, Portable). The API enforces this at the submit step. A 422 SUBMIT_BLOCKED response lists the specific mandatory fields that are missing.
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.
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.
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 (Article 76)
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 product removed from the market under EU Battery Regulation Article 76. 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.
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.