> 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/technical-documentation/roaming-on-2.1.1.md).
# Roaming on 2.1.1
**Everything you need to know about OCPI 2.1.1 and the ENAPI platform**
The ENAPI Transaction Broker fully supports OCPI 2.1.1.
However, where necessary the schema has been extended to:
* Implement the "hub" topology which is not natively supported by version 2.1.1
* Provide added-value functionality seen in other OCPI versions and protocols
* Ensure smooth operation for partners on their OCPI version of choice
Roaming on 2.1.1 with a partner that implements OCPI 2.2.1+ has the biggest impact. Similarly, it is important to be aware of the limitations when roaming with a 2.1.1 partner on OCPI 2.2.1+ connections.
This document outlines all additions made and the caveats when roaming across OCPI versions.
## 🔌 Roaming Partners
### ENAPI's Credentials
As part of the Credentials handshake, ENAPI will provide your system with its own hub credentials: `DE*ENA`.
### Receiving Roaming Partner Credentials
In OCPI 2.1.1 there is no way for ENAPI to share the list of roaming partners from which you will receive requests on the ENAPI platform. You must prepare your platform for this before roaming with a partner.
Data received from roaming partners via ENAPI will have the `country_code` and `party_id` of the roaming partner in the URL. If your platform does not support this, ENAPI can use its own credentials in the URL.
If the ENAPI credentials are used in the URL, data such as locations and tokens that need to be mapped internally to an operator must be done so via other means. ENAPI modifies the Location operator and Token issuer in OCPI 2.1.1 for this reason. How this is done is outlined in the Version Interoperability section below.
## 🌐 Version Interoperability
OCPI 2.1.1 features the most changes of all OCPI versions implemented by ENAPI. This section contains information for partners that support OCPI 2.1.1, or which roam with OCPI 2.1.1 partners.
### Roaming using OCPI 2.1.1
#### Common Changes
Each top-level OCPI object (*Location, Tariff, Token, Session, CDR*) contains the `country_code` and `party_id` to help with identification of the operator, for billing purposes. They are not required to be set by the sending 2.1.1 party. They are added by ENAPI (2.1.1 receivers can opt-out).
| **Property** | **Type** | **Card.** | **Description** |
| ------------- | --------- | --------- | ------------------------------------------------------------------------------ |
| country\_code | String(2) | ? | ISO-3166 alpha-2 country code of the operator that 'owns' this object. |
| party\_id | String(3) | ? | ID of the operator that 'owns' this object (following the ISO-15118 standard). |
#### New Functionality in OCPI 2.2.1+
You will not receive fields and enumeration values added in OCPI 2.1.1 unless explicitly back-ported by ENAPI. Where necessary, ENAPI maps the incompatible values to OCPI 2.1.1 compatible values.
### Locations
* The `operator.name` field is also set to the `country_code` and `party_id` of the Location owner, in case the above values are not supported. For example, if the Location has `country_code=DE` and `party_id=CPO`, the value of the operator's name will be `DE*CPO`.
* Postal code is optional in OCPI 2.2.1+. If receiving a Location from a 2.2.1+ partner that does not include the `postal_code`, this value will be an empty string.
* Connectors that have incompatible `standard`, `format` and `power_type` values (i.e. introduced in subsequent OCPI versions) are omitted in OCPI 2.1.1. They will not be shared with OCPI 2.1.1 roaming partners.
* If a 2.2.1+ roaming partner assigns multiple Tariff IDs to a Connector, ENAPI will attempt to infer the correct Tariff ID for OCPI 2.1.1 partners., based on the Tariff type. If no tariff ID can be selected, it is omitted.
* The `max_electric_power` field was back-ported to OCPI 2.1.1 (see below).
#### Connector ***Object***
Made available to OCPI 2.1.1 receivers when roaming with 2.2.1+ partners.
| **Property** | **Type** | **Card.** | **Description** |
| -------------------- | -------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| max\_electric\_power | int | ? | Maximum electric power that can be delivered by this connector, in Watts (W). When the maximum electric power is lower than the calculated value from voltage and amperage, this value should be set.
For example: A DC Charge Point which can delivers up to 920V and up to 400A can be limited to a maximum of 150kW (max\_electric\_power = 150000). Depending on the car, it may supply max voltage or current, but not both at the same time.
For AC Charge Points, the amount of phases used can also have influence on the maximum power.
|
#### Tokens
* The `issuer` field is also set to the `country_code` and `party_id` of the Token owner, in case the above values are not supported. For example, if the Token `country_code=DE` and `party_id=MSP`, the issuer value will be `DE*MSP`.
#### Sessions and CDRs
* In OCPI 2.1.1, ENAPI uses `PENDING` as a fallback session status, in case of receiving e.g. the `RESERVATION` status value in 2.2.1 or 2.3.0.
* The `FLAT` CDR Dimension was removed from subsequent OCPI versions. CDR Dimensions with this type are filtered out in version 2.2.1+.
* OCPI 2.2.1 introduced the concept of **authorization references**. This was backported to 2.1.1 through the `authorization_id` field on Commands, Sessions, and CDRs.
When you receive a Command that contains an `authorization_id`, you can set that same value on the corresponding Session (and CDR). If you don't, we'll try to set it ourselves.
---
# 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/technical-documentation/roaming-on-2.1.1.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.