> 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/advanced-features/hub-routing-and-message-broadcasting.md).

# Hub Routing and Message Broadcasting

ENAPI sits between partners as a hub. Every OCPI message you send us gets routed to the right counterparties, based on your active roaming agreements.

{% hint style="info" %}
**By default, you do not need to manage any of this.** ENAPI handles message routing and distribution for you. For most partners there's nothing to implement: send your messages to ENAPI and the hub broadcasts or targets each one to the correct counterparties automatically, based on message type and your active agreements. You don't need to set `OCPI-to-*` routing headers to reach the right partners.

This page is an optional reference for advanced cases. For example, if you want to narrow a partner-specific tariff to a single eMSP, or your internal systems read inbound routing headers to drive their own logic. 
{% endhint %}

#### Routing headers

Every OCPI message carries identity headers. ENAPI uses these to route correctly:

* **`OCPI-from-country-code` / `OCPI-from-party-id`:** The original sender.
* **`OCPI-to-country-code` / `OCPI-to-party-id`:** The intended recipient.

ENAPI identifies itself as `DE / ENA` in its own calls, but preserves the **original sender's identity** when broadcasting or forwarding on their behalf. Your partners always see who the message actually came from.

#### Routing header behaviour per message type

Whether a message has a specific `OCPI-to-*` target or gets broadcast to every eligible partner depends on the message type:

<table><thead><tr><th width="333.87109375">Message</th><th>Routing header behaviour</th></tr></thead><tbody><tr><td><strong>Location / EVSE / Connector updates</strong></td><td>Broadcast to all receiving parties with an active agreement — eMSPs, data aggregators and PTPs</td></tr><tr><td><strong>Tariff updates (standard)</strong></td><td>Broadcast to all receiving parties with an active agreement</td></tr><tr><td><strong>Tariff updates (partner-specific)</strong></td><td>Delivered only to the eMSP specified in <code>OCPI-to-*</code></td></tr><tr><td><strong>Token updates</strong></td><td>Broadcast to all CPOs with an active agreement</td></tr><tr><td><strong>Session updates</strong></td><td>Targeted; routed to the eMSP whose token initiated the session, or to the PTP whose terminal did</td></tr><tr><td><strong>CDRs</strong></td><td>Targeted; routed to the party associated with the session - the eMSP, or the PTP for terminal-initiated sessions</td></tr><tr><td><strong>Commands</strong></td><td>Targeted; routed to the CPO that owns the location — from the eMSP whose token initiated the session, or from the PTP whose terminal did</td></tr><tr><td><strong>Terminal updates</strong> (Payments)</td><td>Targeted; routed to the CPO that owns the locations the terminal is assigned to, where an active agreement exists between the PTP and that CPO </td></tr><tr><td><strong>Financial advice confirmations</strong> (Payments)</td><td>Targeted; routed to the CPO associated with the terminal, on the same basis</td></tr></tbody></table>

For Sessions, CDRs, and Commands, ENAPI resolves the recipient from the message itself (token owner, session reference, or location owner respectively). `OCPI-to-*` on these message types is not used for routing. Set it correctly per spec, but ENAPI's delivery decision comes from the message content.&#x20;

Payments messages resolve the same way, from two conditions together: the terminal must be assigned to locations owned by that CPO, and an active agreement must exist between you and them. A terminal assigned to a location you have no agreement for won't route.

On Locations, EVSEs, Connectors, Tokens, and Tariffs, omitting `OCPI-to-*` broadcasts to every eligible partner; setting it narrows delivery to that partner. Eligibility follows from your active agreements and any [restrictions](about:blank) you set on them — you can scope an agreement by country or by party without changing anything in the protocol


---

# 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/advanced-features/hub-routing-and-message-broadcasting.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.