Overview
How Joulo reads charging sessions from every supported charger brand, platform and protocol.
An integration is the path a charging session travels from your charger to the Joulo API. Joulo reads sessions over three routes. The route is a property of the hardware and of who operates it, not a preference you set.
The three routes
| Route | Who holds the credentials | Data arrives |
|---|---|---|
| Cloud API | The manufacturer or the platform operator | On a sync schedule, minutes after the session ends |
| OCPP 1.6J | Joulo, over a WebSocket to the charger | Live, while the car charges |
| No automatic route | Nobody | The charger cannot deliver session data to Joulo |
A charger that a CPO or an energy supplier already operates always takes the cloud route through that operator. Pointing such a charger at Joulo over OCPP cuts the operator's own services, so Joulo does not offer that.
Supported brands
| Brand | Route | API or protocol |
|---|---|---|
| Alfen | OCPP 1.6J | wss://ocpp.joulo.nl |
| Blue Current | Cloud API | Blue Current API |
| Charge Amps | Cloud API | Charge Amps eAPI v5 |
| Easee | Cloud API | Easee Cloud API |
| Ecotap | Cloud API | EVC-net (Last Mile Solutions) |
| Enphase | Cloud API | Enphase API v4 |
| EVBox | OCPP 1.6J | wss://ocpp.joulo.nl |
| go-e | Cloud API | go-e Cloud API + session export |
| KEBA | OCPP 1.6J | wss://ocpp.joulo.nl |
| NexBlue | Cloud API | NexBlue third-party OpenAPI |
| Ohme | Cloud API | Ohme API |
| Peblar | OCPP 1.6J | wss://ocpp.joulo.nl |
| Plugchoice | Cloud API | Plugchoice API v3 |
| Smappee | Cloud API | Smappee Dev API v3 |
| SolarEdge | Session export | SolarEdge feed |
| Tesla | Cloud API | Tesla Fleet API |
| V2C | Cloud API | V2C Cloud |
| Victron | Cloud API | Victron VRM API |
| Volt Time | Cloud API | Plugchoice API v3 |
| Wallbox | Cloud API | Wallbox API |
| Zaptec | Cloud API | Zaptec Cloud API |
| ABB | No automatic route | Manual meter reading |
| OpenEVSE | No automatic route | Local network only |
Brands without a page here still connect. Any charger that speaks OCPP 1.6J reaches Joulo over the universal OCPP route. Platform accounts connect with the operator's own login. That covers 50five, Eneco eMobility, E-Flux by Road, Monta, PowerD, Vattenfall InCharge, EV Company and every EVC-net reseller.
Sync cadence and freshness
Each cloud provider runs on its own schedule. The pages below give the cadence per brand. Two rules hold across all of them:
- Cadence is a capacity decision, not a promise per session. Joulo targets a freshness of under one hour for everything the dashboard shows. Most providers beat that by a wide margin.
- A re-run never double-counts. Every provider writes sessions through the same idempotent insert, keyed on the charger and the session start.
Session history is fetched with an overlap window rather than a cursor, so a missed tick repairs itself on the next run.
Backfill
Joulo backfills history to 1 January 2026, the date the Dutch ERE scheme started. How far back a brand actually reaches depends on the upstream API. Some keep a full history, some cap the window, and a few keep nothing at all. Each page states the limit where one exists.
Backfill never creates measurement. ERE registration counts only the kWh a MID-certified meter measured, so sessions recorded before a MID meter was in place never become eligible.
MID certification
mid_certified on the charger object says whether Joulo has proof of a MID-certified meter. One classifier decides it for every brand, in this order:
- Admin override, recorded for the NEa audit trail.
- Provider signal, when the integration reports something definitive. Tesla exposes a part number, Smappee a meter serial, OCPP a boot notification.
- Catalog match against the validated hardware matrix, per model.
- Unknown, which queues the charger for review.
An unknown verdict never replaces a stored one. Sessions still sync while a charger sits in review, and ERE eligibility stays closed until the verdict lands.