> For the complete documentation index, see [llms.txt](https://docs.enapi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.enapi.com/advanced-features/ocpi-version-interoperability.md). # OCPI Version Interoperability The ecosystem isn't on a single OCPI version. Partners run 2.1.1, 2.2.1, and 2.3.0 — sometimes across the same pair of companies. ENAPI's translation engine lets partners on different versions roam with each other without either side changing their implementation. ### How it works Each partner connects using their native OCPI version. When messages flow between partners on different versions, ENAPI translates in both directions. ### Translation principles * **Lossless where possible.** Fields with no equivalent in the target version are preserved internally so they're not lost on re-translation. * **Spec-compliant output.** What each partner receives always conforms to their OCPI version's spec. * **Transparent to partners.** Neither side needs to know what version the other is on. ### Limitations A small number of version-specific features can't be represented across versions. When these apply, ENAPI makes a best-effort mapping or downgrade. ### APP\_USER and AD\_HOC\_USER token types (2.2.1+ → 2.1.1) OCPI 2.2.1 introduced token types for app-based users (`APP_USER`) and ad-hoc direct-payment users (`AD_HOC_USER`). OCPI 2.1.1 has neither concept. When a 2.2.1+ eMSP sends one of these to a 2.1.1 CPO, ENAPI maps the type to `OTHER`. The token works for authorization, but the CPO loses the specific context about what kind of user is charging. A side effect of this mapping: a 2.1.1 CPO may issue an authorization request after receiving a command involving an `APP_USER` or `AD_HOC_USER` token. Strictly speaking, this is not aligned with OCPI: for `APP_USER` and `AD_HOC_USER` tokens used in a command, eMSPs should not receive authorization requests. ENAPI can handle these requests from 2.1.1 partners on your behalf if needed. Reach out at or in the designated Slack channel. ### Credit CDRs (2.2.1 → older versions) OCPI 2.2.1 introduced **credit CDRs** — a way to issue a corrective CDR that reverses or adjusts a previously sent one, rather than the recipient deleting and re-receiving. 2.1.1 has no equivalent. Credit CDRs can't be delivered to partners on older versions. If you need to correct a CDR with a partner on 2.1.1, handle it as a dispute through the CDR Inbox (see [The CDR Inbox](/cdr-clearing/the-cdr-inbox.md)). ### Signed metering data (2.2.1+ → 2.1.1) OCPI 2.2.1 introduced signed metering data in CDRs — cryptographic proof of energy measurements for regulated markets (notably Germany's Eichrecht requirements). When a 2.2.1+ CPO sends a CDR with signed metering data to a 2.1.1 eMSP, the signed data isn't delivered — the receiver's version has no field for it. The CDR itself is still delivered in full. If your market requires signed metering data on the receiver's side, both partners need to be on 2.2.1 or higher. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.enapi.com/advanced-features/ocpi-version-interoperability.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.