> 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/getting-started/roles-and-parties-on-enapi.md). # Roles and Parties on ENAPI ENAPI is a hub: you connect once, and the platform routes your data to every counterparty you have an agreement with. What you send, what you receive, and what you sign depend on **what kind of party you are** — which you declare yourself, during the handshake. ## The four party types | Party type | What you do | You send | You receive | | -------------------------------------- | --------------------------------------------------------------------------------------------------- | --------------------------------------------------- | ---------------------------------- | | **CPO** — Charge Point Operator | Operate a network of charge points | Locations, Tariffs, Sessions, CDRs | Tokens, Commands, Payments | | **eMSP** — e-Mobility Service Provider | Give EV drivers access to charging | Tokens, Commands | Locations, Tariffs, Sessions, CDRs | | **Data aggregator** — NSP / NAP | Publish or analyse charge point data: maps, navigation, national access points, market intelligence | — | Locations, Tariffs | | **PTP** — Payment Terminal Provider | Operate payment terminals at charge points for ad-hoc card payment | Terminals, Financial advice confirmations, Commands | Locations, Tariffs, Sessions, CDRs | Data aggregators receive reference data only. Sessions and CDRs — the transaction record — go to the party that initiated the session, and only for that party's own sessions: the eMSP whose token was used, or the PTP whose terminal was used. ## How your party type is determined You declare it. Your party type is taken from the `role` you send in the Credentials module during the [OCPI handshake](about:blank) — `CPO`, `EMSP`, `NSP`, `NAP` or `PTP`. There's no separate setting and nothing to request: connect with the role you operate and the platform configures itself around it. If you operate as more than one, declare them all in a single credentials exchange and run one connection. Two things to keep in mind: * **Your role is whatever your credentials say** — including if that's wrong. Many platforms send EMSP by default, and a data aggregator whose platform does that will appear as an eMSP. * **OCPI 2.1.1 can't express it at all.** 2.1.1 predates roles in Credentials, so any non-CPO party connecting on 2.1.1 is registered as an eMSP. Data aggregators and PTPs should connect on 2.2.1 or later — and PTPs should prefer 2.3.0, where the Payments module is fully standardised. ## **Two things called "role"** It's worth separating them, because the docs use both: * **Your party type** is commercial. It decides which agreements you sign, how you're billed, and what you see in the Portal. * **Your protocol role** is per module: Sender or Receiver. It decides which OCPI endpoints you implement. The technical documentation is written in terms of protocol roles, because those don't change as the network grows. A data aggregator is a Receiver on Locations and Tariffs and absent everywhere else. ## **Agreements and offers** Every data flow on ENAPI sits behind a signed agreement, whatever the party types involved. ENAPI's standard roaming agreement covers the CPO–eMSP case. If **you're a data aggregator or a payment terminal provider, upload your own standard data-sharing agreement or customer contract as a custom contract template and send offers on that basis** — the offer flow, signature routing and activation are identical. See [Custom Contract Templates](/roaming/custom-contract-templates.md). **What this means for your integration** * **You only implement the modules in your scope**. A data aggregator implements two Receiver interfaces, not six. See [Which modules apply to you](/technical-documentation/supported-ocpi-modules-and-capabilities.md). * **Agreements can be scoped**. A CPO can restrict any offer by country or by OCPI party, and set a future activation date — useful when you want to share part of your network with an aggregator but not all of it. See [Roaming Offers Restrictions](/roaming/roaming-offers-restrictions.md). * **One connection, several party types**. Operating as both CPO and eMSP is one handshake and one account with both roles declared. **Next** * **Create your account** → [Onboarding to ENAPI](/getting-started/onboarding-to-enapi.md) * **Decide which region to operate in** → [Pick your region](/getting-started/pick-your-region.md) * **Declare your role and connect** → [Set up your OCPI Handshake with ENAPI](/getting-started/set-up-your-ocpi-handshake-with-enapi.md) * **See which modules apply to you** → [Supported OCPI Modules and Capabilities](/technical-documentation/supported-ocpi-modules-and-capabilities.md) --- # 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/getting-started/roles-and-parties-on-enapi.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.