> 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/testing-your-ocpi-handshake-with-enapi.md).

# Testing your OCPI Handshake with ENAPI

## Testing your OCPI handshake with ENAPI

### Overview

Testing your OCPI integration with ENAPI has two parts:

1. **The handshake** — exchanging credentials and endpoints with the ENAPI Transaction Broker.
2. **Testing the integration** — end to end tests of all connected modules, simulating real life scenarios.

You can run both parts in one of two ways:

* **Asynchronous** — run through most tests in your own time
* **Synchronous** — run them together with the ENAPI integrations team on a scheduled call.

Both paths use the same simulators and check the same things. In either case, the integrations team must validate the connection before moving to production, typically on a call.

### Prerequisites

* Functioning OCPI implementation in version 2.1.1, 2.2.1, or 2.3
* ENAPI staging account
* Technical team member invited to the account

### What the handshake tests

A successful handshake confirms:

* Authorization tokens were exchanged
* Module endpoints were exchanged
* Both sides can reach each other's endpoints

Once the handshake succeeds, your platform is automatically connected to the appropriate ENAPI simulator:

* **CPO partners** → connected to ENAPI eMSP simulator (ES/MSP)
* **eMSP partners** → connected to ENAPI CPO simulator (ES/CPO)
* **Partners acting as both** → connected to both simulators

The simulators provide standardized test data — locations, tariffs, tokens, and a session simulator that generates realistic sessions and CDRs.

### CPO test

#### Phase 1: Data synchronization

**Inbound** (ENAPI pulls from you):

* **Locations** — pulled, validated for structure and completeness, connectors and capabilities mapped correctly
* **Tariffs** — pulled, pricing structure validated, tariff-to-location associations confirmed

**Outbound** (you pull from ENAPI):

* **Tokens** — pulled from the eMSP simulator, authentication data validated, token states and types covered.

#### Phase 2: Session flow

1. **Session start** — ENAPI uses test tokens to initiate sessions at your locations; state transitions and authorization flows are monitored
2. **Session updates** (optional) — real-time updates from your side are validated and routed
3. **Session stop and CDR** — stop commands executed, CDR generation and receipt verified, CDR routed to billing

### eMSP test

#### Phase 1: Data synchronization

**Inbound** (ENAPI pulls from you):

* **Tokens** — pulled, format and authentication data validated, state management tested (if only commands will be used, this step is skipped)

**Outbound** (you pull from ENAPI):

* **Locations** — pulled from the CPO simulator, completeness and filtering tested
* **Tariffs** — pulled, pricing accuracy confirmed, update mechanism tested

#### Phase 2: Session flow

1. **Session start** — sessions started using your tokens, either driven from ENAPI or initiated through your interface; authorization and routing verified
2. **Session updates** — ENAPI session updates routed to you, state synchronization checked
3. **Session stop and CDR** — termination executed, CDR generation and routing to you verified
4. **RFID authentication** — tested manually with the ENAPI onboarding team

### Asynchronous

Partners who want to work at their own pace:

1. Register on [staging](https://app.staging.enapi.com/register)&#x20;
2. Invite a relevant team members on [team](https://app.staging.enapi.com/company/team) page
3. Carry out the [handshake](https://app.staging.enapi.com/handshakes), you technical team runs through the tests
4. [Contact](https://calendly.com/integrations-enapi) ENAPI technical team to validate test results.
5. Once green in staging, register on [production](https://app.enapi.com/register)
6. Run the production [handshake](https://app.enapi.com/handshakes)&#x20;

### Synchronous

Partners trying to move quickly:

1. Register on [staging](https://app.staging.enapi.com/register)&#x20;
2. Invite a relevant team members on [team](https://app.staging.enapi.com/company/team) page
3. Book a 50-minute session with your technical team and the integrations team via [Calendly](https://calendly.com/integrations-enapi/50min)
4. Handshake and tests are run live on the call

### Success criteria

A test run passes when:

* All handshake verification points pass
* Data synchronization operates bidirectionally without errors
* Session flows complete end-to-end with correct CDR generation
* All routing mechanisms function correctly
* No critical errors remain unresolved&#x20;

***


---

# 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/testing-your-ocpi-handshake-with-enapi.md?ask=<question>&goal=<endgoal>
```

`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.
