On this pageThe version is in the path
A battery passport has to stay available for years, and so do the integrations that feed it. An ERP job written against v1 should keep working without anyone touching it.
The version is in the path
Every endpoint is under /v1. There is no version to request in a header and no date-pinned behaviour to manage: the path you call is the contract you get. Every response names the exact version that answered in X-DPP-Api-Version (currently 1.0.0), and GET /me returns it as apiVersion.
What may change within v1
Within a version, changes are additive only:
| Change | Within v1? |
|---|---|
| New endpoints | Yes |
| New optional request properties | Yes |
| New properties in responses | Yes |
| Removing or renaming an endpoint or property | No — new version |
| Making an optional request property required | No — new version |
| Changing the type or meaning of a property | No — new version |
Breaking changes
Anything that could break a working integration goes into a new version, /v2, announced in advance — never into v1.
Writing tolerant clients
- Ignore response properties you do not recognise instead of failing on them.
- Do not depend on the order of properties in a JSON object.
- Treat the
errorcodes you handle explicitly as a known set and fall back to the HTTP status for the rest. - Read obligations from the field catalogue at runtime rather than copying today’s list into code.
The specification
The OpenAPI 3.1 document is public and is the source of truth for request and response schemas. Generate a client from it, diff it in CI, or load it into your API tool of choice: