# The OCPI repository is a specification with a branching model, not an implementation > The ocpi/ocpi repository holds the Open Charge Point Interface specification, currently at OCPI 2.3.0, published as a core document plus separately released optional modules such as Payments and Bookings. What makes it unusual is the branch taxonomy, where release, feature and hotfix branches sit under one namespace, and the version scheme that distinguishes a protocol change from a documentation edit. **ocpi/ocpi** — The Open Charge Point Interface (OCPI) allows for a scalable, automated roaming setup between Charge Point Operators and e-Mobility Service Providers. It supports authorisation, charge point information exchange (incl transaction events), charge detail record exchange and finally, the exchange of smart-charging commands between parties. - Repository: https://github.com/ocpi/ocpi - Stars: 599 · Forks: 230 - Language: Perl - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/ocpi-ocpi ## A protocol for roaming between operators and roaming service providers The Open Charge Point Interface, OCPI, allows for a scalable, automated roaming setup between Charge Point Operators and e-Mobility Service Providers. The repository description enumerates what the protocol covers: authorisation, charge point information exchange including transaction events, charge detail record exchange, and the exchange of smart-charging commands between parties. So the problem it addresses is the seam between two parties who do not have a contract with each other. A driver charges at a station that belongs to one operator while holding an account from a service provider, and something has to carry the authorisation, the session events, the consumption records and the pricing between them. OCPI is the message vocabulary for that exchange. What this repository is, and is not, matters for anyone deciding whether to depend on it. The README says plainly that this repository contains the OCPI specification. The most recent specification is OCPI 2.3.0, published as a core document plus separately packaged optional modules. There is no server here, no client library and no conformance suite. The examples/ directory holds payload examples, and the rest of the tree is AsciiDoc source for the documents themselves, with a plantuml/ directory for the diagrams and a scripts/ directory for the build. Background on OCPI, its development and its contributors is on the EV Roaming Foundation website, and development of the next version is handled separately in the ocpi-3 repository, which is only accessible to Contributors of the EV Roaming Foundation. ## Three kinds of branch under one 2.3.0 namespace The branching strategy is the part of the README that takes longest to understand, and it is the most useful thing in the file for an implementer. The 2.3.0 work is organised into three kinds of branches under the shared 2.3.0/ namespace. Release branches hold the published sources of truth, that is the core specification and each module. Feature branches hold work in progress, and once a module or change is ready it is merged into the relevant release branch and the feature branch is archived. Hotfix branches collect corrections to an already-published release, and as with feature branches the fixes are merged into the relevant release branch and the hotfix branch is then archived. The three release branches currently listed are 2.3.0/release/core for the core specification, 2.3.0/release/payments for core plus the Payments module, and 2.3.0/release/bookings for core plus the Bookings module. The core branch is the source of truth for the core spec, and each module has its own source of truth. The reason the modules get their own branches rather than a single combined document is worth noting. A payments module changes on a different cadence from the core, and separating them means a payments correction does not force a new core document to be republished. There is a wrinkle from the previous scheme. A release-2.3.0-bugfixes branch predates the 2.3.0/release convention, it holds edition 1 and is now frozen with all of its fixes carried into 2.3.0/release/core. The compatibility matrix says that branch will be deleted, and the README adds that new work and new implementations should follow the 2.3.0/release branches. The 2.3.0/release/* branches replace master as the reference for the current release, and the default branch of this repository is 2.3.0/release/core rather than master. ## Version numbers separate protocol change from documentation edit OCPI releases use a semantic-style version number of the form MAJOR.MINOR.PATCH, for example 2.0, 2.1.1 and 2.2. Any change to the specification produces a new number, where a larger increment signals a broader or breaking change and a smaller one a minor or corrective change. Documentation revisions of the same specification are marked with a -dN suffix, for example 2.1.1-d2 and 2.2-d2, indicating updated text and examples with no protocol change. That distinction is the useful part. If you are implementing a protocol, the difference between 2.2-d2 and 2.2 is the difference between a spec that gained examples and a spec whose messages changed, and a client that ignores the distinction will misjudge whether it needs to change. The compatibility matrix makes the mapping concrete, and the recent release tags follow the same shape. v2.3.0-ed2-payments and v2.3.0-ed2 were both published on 2026-06-18, with v2.3.0-bookings on 2026-06-04. The README also flags that the versioning methodology itself is under discussion. One proposal is to adopt the CEN-CENELEC versioning methodology, where the protocol version stays fixed and changes are expressed through multiple levels, for example an edition such as ed2 for changes to messages, fields or datatypes, and a documentation update such as -d2 for text and examples only. The same approach could be applied to modules so each carries its own edition and evolves independently of the core. The note is marked as under discussion, which is a signal that the scheme described above is a convention rather than a frozen rule. ## Where to get the document you actually have to implement There is no install step for a specification, so the practical equivalent is picking the right branch or tag and taking the document from it. The README points at the compatibility matrix as the way to do that, and the matrix maps each published PDF to its GitHub tag, its GitHub branch, its core and module versions, a remark and a status. The entries illustrate how the matrix is meant to be read. OCPI 2.3.0 including Payments is tagged v2.3.0 and lives on the release-2.3.0-bugfixes branch, with the remark that that branch will be deleted. OCPI 2.3.0 Edition 1 is tagged v2.3.0-ed1 and sits on 2.3.0/release/core, with the remark that it is similar to OCPI 2.3.0 without the payment module, and its status is Internal Release. OCPI 2.3.0 Edition 2 is tagged v2.3.0-ed2 on 2.3.0/release/core, with core improvements and Invoice Reconciliation, and its status is Planned. That last line is the one to watch. A document whose status is Planned is not something to build an implementation against yet, so reading the status column before reading the protocol is a sensible habit. For earlier versions, fixes live on dedicated bugfix branches. There is release-2.2.1-bugfixes for the latest fixes to the 2.2.1 documentation, release-2.2-bugfixes for 2.2, and release-2.1.1-bugfixes for 2.1.1. The documents themselves are AsciiDoc sources in the repository root, with names that map onto the protocol's concepts: transport_and_format.asciidoc, credentials.asciidoc, mod_locations.asciidoc, mod_sessions.asciidoc, mod_tariffs.asciidoc, mod_tokens.asciidoc, mod_commands.asciidoc, mod_charging_profiles.asciidoc, mod_hub_client_info.asciidoc, mod_invoice_reconciliation.asciidoc, mod_cdrs.asciidoc, plus introduction.asciidoc, topology.asciidoc, types.asciidoc and status_codes.asciidoc. The releases/ directory holds the published outputs. ## The examples directory is a payload dictionary, and it is large The examples/ directory is the closest thing to runnable content in the repository, and its size is itself informative about the protocol's surface. The location examples alone run to a dozen files. There are straightforward ones such as location_example.json, and then a series of numbered variants that each isolate one rule: location_example_uc2_destination_charger.json, location_example_uc3_destination_charger_not_published.json, location_example_uc4_limited_visibility.json and location_example_uc5_home_charge_point.json. There is a parking garage variant with opening hours, several regular hours examples, and hours examples for always open, exceptional closing and exceptional opening. Then there are the patch and put examples, which show the mutation half of the API: location_patch_example_location.json, location_patch_example_remove_evse.json, location_patch_example_status.json, location_patch_example_tariff.json and location_put_example_add_evse.json. The pattern of numbered usage cases and separate mutation examples suggests the numbering maps to use cases in the specification text, which makes the examples usable as a checklist while implementing. The other families are credentials, with four example files, session with two, and a charge detail record example. The credentials examples are particularly worth reading, because authorisation is where a roaming integration usually goes wrong and four variants suggests the accepted shapes are not obvious. There is also a location_energymix_example with a complete variant and an energy provider variant alongside a simple one. The energy mix data on a location is what lets a driver or a service provider reason about whether a charge is renewable, which is a common requirement in European market rules. One structural detail at the top of the tree is the template-object-description.md file, which suggests the specification includes a description of its object model in a form that can be turned into something else. ## The licence is not a standard one, and that is worth reading The repository listing classifies the licence as a custom one that GitHub cannot classify, with a LICENSE file at the root. The top level entries do include copyright.asciidoc as a separate file, which is the usual place for a specification to state its copyright and reuse terms, and terminology.asciidoc for the defined vocabulary, plus version_history.asciidoc and version_information_endpoint.asciidoc. For a specification repository, the interesting question is not the code licence but the terms on the document text itself, since that is what you would copy into an implementation, a conformance paper or a product. The classification of the licence as unrecognised by GitHub is a fact about the tooling, not a statement about permissiveness, and the practical step is to read the LICENSE file rather than to infer anything from the listing. That is a licensing note, not legal advice. The second thing worth checking is the example payloads. A specification that ships JSON examples will be reused by implementers, and whether those examples are covered by the same terms as the prose is a separate question from the prose itself. On maintenance, the record is current. The last push was on 2026-09-07, the repository is not archived, and the recent release tags are v2.3.0-ed2-payments and v2.3.0-ed2 from 2026-06-18 and v2.3.0-bookings from 2026-06-04. The default branch is 2.3.0/release/core, so the working copy you get by default is the current core specification rather than a stable tag. The alternative to working from this repository is a third party implementation guide, and the difference in approach is that a guide tells you what the messages mean in one author's words, while this tells you what the standard says, in a document that both parties in a roaming relationship are expected to cite. If you are on both sides of an integration, that is the version that matters, because a mismatch is a commercial problem before it is a technical one. ## Conclusion Use this repository if you are implementing OCPI and need the authoritative text for a specific version, because the branches and tags tell you exactly which document corresponds to which protocol revision. Do not expect an implementation, a client library or a test harness, since the repository is the specification and its examples only. Verify first which branch holds the version you must match, since the 2.3.0/release branches replaced master as the reference, that the module you need is published for the edition you target, and how the licence file applies to the specification text and the example payloads. ## FAQ ### What is the ocpi repository and what does it contain? It contains the OCPI specification, with the most recent specification being OCPI 2.3.0, published as a core document plus separately packaged optional modules. The tree holds AsciiDoc sources for the documents, a plantuml directory for diagrams, a scripts directory for the build, and an examples directory of JSON payloads. ### Which branch holds the current OCPI 2.3.0 specification? The 2.3.0/release/core branch is the source of truth for the core specification, with 2.3.0/release/payments and 2.3.0/release/bookings holding the core plus their respective modules. The 2.3.0/release/* branches replace master as the reference for the current release, and the repository default branch is 2.3.0/release/core. ### What is the difference between a -dN suffix and an edition in OCPI versioning? A -dN suffix such as 2.2-d2 marks a documentation revision of the same specification, meaning updated text and examples with no protocol change, while an edition such as ed2 covers changes to messages, fields or datatypes. The README notes that adopting the CEN-CENELEC methodology formally is still under discussion. ### Where do I find the OCPI examples for locations, sessions and credentials? The examples/ directory holds them, with location_example.json and numbered use case variants, regular hours and exceptional hours examples, patch and put mutation examples, four credentials examples, session examples and a charge detail record example. ### Does this repository contain an OCPI implementation or server? No. The README says the repository contains the OCPI specification, and the description covers the protocol itself, covering authorisation, charge point information exchange including transaction events, charge detail record exchange and smart-charging command exchange between Charge Point Operators and e-Mobility Service Providers. Development of the next version happens in the separate ocpi-3 repository. ## Sources - [Issues](https://github.com/ocpi/ocpi/issues) - [ocpi/ocpi on GitHub](https://github.com/ocpi/ocpi) - [README](https://github.com/ocpi/ocpi/blob/2.3.0/release/core/README.md) - [Releases](https://github.com/ocpi/ocpi/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ocpi-ocpi