> 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/how-enapi-syncs-ocpi-data.md).
# How ENAPI Syncs OCPI Data
ENAPI keeps data in sync between partners using a mix of push and pull. Most of the time it runs in the background. The two moments worth understanding are what happens when a new agreement activates and how the ongoing sync schedule works.
### The sync model
Two directions, two mechanisms:
* **Partners → ENAPI.** ENAPI pulls from partners on a schedule (see below). Partners also push updates (PUT, PATCH) in real time when objects change.
* **ENAPI → Partners.** ENAPI broadcasts incoming pushes immediately to every connected partner. ENAPI does not periodically push to partners - if you want to pull from us on a schedule, you can, but you don't have to: broadcast keeps you current.
The practical consequence: real-time updates flow via push-and-broadcast. The scheduled pulls are a safety net that catches anything missed.
The same hub model serves pulls, not just pushes: ENAPI keeps each partner's counterparty data continuously up to date, so partners can pull the current state from ENAPI on demand rather than reaching out to each counterparty directly.
This is how OCPI traffic scales efficiently. Each partner synchronizes against one system instead of many: data is reconciled once at the hub and is distributed to partners, so the work of staying in sync grows linearly with how much data actually changes, not with how many partners are on the network.
### Right after signing a new roaming agreement
When a roaming agreement activates, ENAPI automatically pushes the current state to both parties - no manual initial sync required. You receive the partner's full object set as it stands at activation:
* The **CPO's locations and tariffs** are pushed to the **eMSP**.
* The **eMSP's tokens** are pushed to the **CPO**.
From there, ongoing changes continue to flow via push-and-broadcast, with the scheduled pulls (below) as a safety net. The agreement is live from the moment it activates, with nothing to trigger on your side.
{% hint style="info" %}
**Note:** Automatic activation push is rolling out progressively. It is live for a subset of partners today and is being enabled more broadly over the coming weeks. It is also configurable per partner — for example, if you need administrative setup completed before data flows, or if inbound volume is a concern, push can be throttled or disabled for your platform. Contact your integration team to enable it sooner or to adjust the behavior.
Until activation push is enabled for your platform, the current state must be loaded with a one-time initial sync after the agreement activates: a full pull that transfers the OCPI object set as it stands today.
{% endhint %}
### Ongoing sync schedule
Once the initial sync is in, ENAPI keeps data fresh with two recurring jobs:
* **Delta syncs** run **Monday through Saturday at 01:00 UTC**, requesting only objects changed since the last sync (via `date_from`).
* **Full syncs** run **every Sunday at 01:00 UTC**, reconciling the complete dataset.
### How ENAPI identifies itself in pull requests
ENAPI's pull requests include standard OCPI headers identifying ENAPI as the calling party:
```
Authorization: Token
OCPI-From-Country-Code: DE
OCPI-From-Party-Id: ENA
OCPI-To-Country-Code:
OCPI-To-Party-Id:
```
Use these to identify ENAPI traffic in your logs and allowlists.
### Monitoring sync status
Go to **Technical → Data Quality** to see:
* **Your Data.** How much of your data ENAPI has synced.
* **Partner Data.** How much of your partners' data you've received.
### Implementation recommendations
To keep sync reliable:
* Support **pagination** with `Link` headers.
* Support **`date_from`** filtering so delta syncs only return changed objects.
* Return **consistent `last_updated`** timestamps — these drive delta calculations.
* Handle **concurrent requests** gracefully; ENAPI parallelizes where possible.
---
# 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/how-enapi-syncs-ocpi-data.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.
