Download OpenAPI specification:
This is the required base module of OCPI. This module is the starting point for any OCPI connection. Via this module, clients can learn which versions of OCPI a server supports, and which modules it supports for each of the versions.
| status_code required | integer OCPI status code, 1000 for success. |
| status_message | string An optional status message which may help when debugging. |
| timestamp required | string <date-time> The time this message was generated. |
| data | any Response data object or list of objects. |
{- "status_code": 1000,
- "status_message": "string",
- "timestamp": "2019-08-24T14:15:22Z",
- "data": null
}| Enum | Description |
|---|---|
| 2.0 | OCPI version 2.0 |
| 2.1 | OCPI version 2.1 (DEPRECATED, do not use, use 2.1.1 instead) |
| 2.1.1 | OCPI version 2.1.1 |
| 2.2 | OCPI version 2.2 (DEPRECATED, do not use, use 2.2.1 instead) |
| 2.2.1 | OCPI version 2.2.1 |
| 2.3.0 | OCPI version 2.3.0 (this version) |
List of known versions.
"2.0"| version required | string <open-enum> (VersionNumber)
The version number. | ||||||||||||||
| url required | string <uri> URL to the endpoint containing version specific information. |
{- "version": "2.0",
}| Enum | Description |
|---|---|
| cdrs | CDRs module |
| chargingprofiles | Charging Profiles module |
| commands | Commands module |
| credentials | Credentials & Registration module (required for all implementations). The |
| hubclientinfo | Hub Client Info module |
| locations | Locations module |
| sessions | Sessions module |
| tariffs | Tariffs module |
| tokens | Tokens module |
| bookings | Bookings module |
| payments | Payments module |
The Module identifiers for each endpoint. Most modules (except Credentials & Registration) are optional, but there might be dependencies between modules. Parties are allowed to create custom modules with additional custom moduleIDs.
"cdrs"| Enum | Description |
|---|---|
| SENDER | Sender Interface implementation. Interface implemented by the owner of data, so the Receiver can Pull information from the data Sender/owner. |
| RECEIVER | Receiver Interface implementation. Interface implemented by the receiver of data, so the Sender/owner can Push information to the Receiver. |
The interface role of an endpoint.
"SENDER"| identifier required | string <open-enum> (ModuleID)
Endpoint identifier. | ||||||||||||||||||||||||
| role required | string <enum> (InterfaceRole)
Interface role this endpoint implements. | ||||||||||||||||||||||||
| url required | string <uri> URL to the endpoint. |
{- "identifier": "cdrs",
- "role": "SENDER",
}| version required | string <open-enum> (VersionNumber)
The version number. | ||||||||||||||
required | Array of objects (Endpoint) non-empty A list of supported endpoints for this version. |
{- "version": "2.0",
}This endpoint lists all the available OCPI versions and the corresponding URLs to where version specific details such as the supported endpoints can be found.
The exact URL to the implemented version endpoint should be given (offline) to parties that want to communicate with your OCPI implementation.
Both, CPOs and eMSPs MUST implement such a version endpoint.
| X-Request-ID required | string Every request SHALL contain a unique request ID, the response to this request SHALL contain the same ID. It is advised to use GUID/UUID as values. |
| X-Correlation-ID required | string Every request/response SHALL contain a unique correlation ID, every response to this request SHALL contain the same ID. It is advised to use GUID/UUID as values. When a Hub forwards a request to a party, the request SHALL contain the same X-Correlation-ID HTTP header (with the same value). |
{- "status_code": 1000,
- "status_message": "string",
- "timestamp": "2019-08-24T14:15:22Z",
}Via the version details, the parties can exchange which modules are implemented for a specific version of OCPI, which interface role is implemented, and what the endpoint URL is for this interface.
Parties that are both CPO and eMSP (or a Hub) can implement one version endpoint that covers both roles. With the information that is available in the version details, parties don’t need to implement a separate endpoint per role (CPO or eMSP) anymore. In practice this means that when a company is both a CPO and an eMSP and it connects to another party that implements both interfaces, only one OCPI connection is needed.
No structure defined. This is open for every party to define themselves.
| X-Request-ID required | string Every request SHALL contain a unique request ID, the response to this request SHALL contain the same ID. It is advised to use GUID/UUID as values. |
| X-Correlation-ID required | string Every request/response SHALL contain a unique correlation ID, every response to this request SHALL contain the same ID. It is advised to use GUID/UUID as values. When a Hub forwards a request to a party, the request SHALL contain the same X-Correlation-ID HTTP header (with the same value). |
{- "status_code": 1000,
- "status_message": "string",
- "timestamp": "2019-08-24T14:15:22Z",
- "data": {
- "version": "2.0",
}
}