// Under the hood
How Joulo is built
We get a lot of questions about where your data lives, how we prove ERE credits and who audits us. This is the short answer.
How Joulo is built
A short, honest explainer of the technology behind Joulo. For anyone who wants to know where their data lives, how we handle it, and how we can prove the ERE credits add up.
In one paragraph
Joulo runs on two separate layers: a global network that handles the website, the dashboard and the charger traffic, and a database in European data centres for your account, sessions and payouts. Every charger that meters, every button you press in the app, every euro we register on your behalf: it is all recorded so we can prove it later to you, to the NEa and to an external auditor.
Where your data lives
| What | Where | Who can access it |
|---|---|---|
| Account, e-mail, settings | Database in a European data centre | You, with your login. We only see it for support after your request. |
| Charging sessions (date, kWh, charger) | Same | Same. |
| IBAN for payouts | Encrypted vault, separated from the database | Nobody can read this without the right key. Not even us, except the payout function itself. |
| Tokens for your charger account | Same | Same. |
| Photos of your MID meter | Private storage | Only you, via temporary links (valid for 1 hour). |
| Raw technical messages from your charger | Append-only archive | Audit evidence, not editable. |
We don't keep what we don't need. Sensitive data like your IBAN lives encrypted, in a different place from the rest of your data, so it isn't trivially viewable even on our side.
How we can prove ERE credits
ERE credits are money. Money has to add up. That's why we record every charging session in two places at once:
- Editable layer the database, with audit trail. This is where calculations happen and where you see your sessions.
- Append-only layer an immutable archive. Not modifiable by us, not modifiable by third parties.
When the NEa or an external auditor asks, we can put the two side by side. That is what an inboekdienstverlener (registration service provider) does: we make your renewable charging provably real. No proof, no credits. No credits, no payout. Hence the dual system.
In the app we clearly distinguish:
- 🟢 Server-verified sessions measured by our own backend over the OCPP protocol.
- 🟡 Imported sessions supplied by your charger account (Tesla, Easee, …) through a connected API.
- ⚪️ Manually entered sessions entered by you, with a lower confidence level.
Our MID-meter detection (and the requirement to have one for the highest credit category) is hard-wired: no MID meter, no ERE.
OCPP and end-to-end traceability
For chargers that talk to us directly over the OCPP protocol (the open standard for charging infrastructure) we built our own Central System. It runs on our global edge network and has three properties that matter:
- One long-lived process per charger. Every charger gets its own fixed slot at the edge, close to where it physically sits. No charger ever shares connection state with another. Between messages the process sleeps (and costs us nothing); the moment a frame arrives it wakes up. That is how you can be both cheap and always-on.
- Nothing is lost if the database is briefly unreachable. The edge writes incoming OCPP messages into a local queue (the "outbox") first and forwards them to the database afterwards. Database maintenance or outage? The queue fills up, and once the database returns everything is registered correctly. Each message carries an idempotency key, so duplicate messages never lead to duplicate bookings.
- Every OCPP frame is archived immutably. Alongside the editable database tables, every incoming and outgoing OCPP frame is written as a standalone file to an append-only archive. Not modifiable, not deletable, retained at least 13 months hot and indefinitely in cold storage thereafter.
The effect is end-to-end traceability: from the moment your car starts charging and the charger sends a StartTransaction, through every intermediate MeterValues reading, to the final StopTransaction closing reading every step exists in two independent records. When the NEa, an external auditor or you ask, we can reconstruct the full message flow per session. Not "trust us", but proof.
Who sees what
Our database enforces per-row access control on every table. That means: the database itself only allows your sessions, your IBAN, your photos to reach you. A misprogrammed frontend cannot bypass that, because the database rules themselves refuse it.
For our admins there is a separate layer, with logging of every admin action. Who looked at what when, lives in a separate audit table.
Outer-layer security
- A firewall at the edge of the network filters malicious traffic before it reaches us.
- AI-bot policy keeps scrapers and automated abuse out, with an exception for search crawlers we explicitly allow.
- For partners and API users: OAuth 2 with scoped tokens and per-token rate-limiting.
- Login uses industry-standard password hashing, with optional magic-link login.
- No passwords in our logs. No tokens in our logs. No IBANs in our logs.
Who audits us
- NEa the Dutch regulator. Joulo B.V. has been on the official list of inboekdienstverleners since 2 February 2026. The REV account (the technical channel through which registrations are submitted) is a separate follow-up step for service providers.
- Capptions our official compliance-software partner. Audit evidence under every ERE claim we make.
- External auditor on the first batch registration and yearly thereafter.
- You through your own dashboard you can trace every session and every payout down to the kWh.
What if you want to leave
- Cancel: one click in your dashboard. No fixed term, cancel yearly (Wet van Dam, Dutch consumer law). No fees.
- Export your data: all sessions and payouts downloadable as CSV/JSON.
- Delete your account: self-service from your dashboard as long as we have not yet registered ERE credits for you with the NEa. Have we already registered? Then we are legally required to retain the underlying records as an auditable trail. In that case your account is blocked and your data is minimised to what the audit trail requires; you'll hear nothing more from us, but the records remain available for the NEa.
Short summary
| Component | What |
|---|---|
| Marketing and dashboard frontend | Server-side rendered, with a fast SPA for the logged-in dashboard |
| Edge | Global network handling traffic close to the user; one long-lived process per charger for the OCPP connection |
| Backend (data) | Relational database in European data centres with per-row access control, plus an append-only archive for audit evidence |
| Mobile app | Native iOS and Android, sharing the same backend |
| Charger protocol | OCPP 1.6J our own Central System (CSMS), self-managed |
| Cloud integrations | Tesla, Easee, Wallbox, Zaptec, V2C, 50five, Plugchoice (live), Smappee (in development) |
| Releases | Fully automated via Git no manual deploys |
| Observability | External uptime monitoring, structured logs and an internal /status page |
Questions about how we built something, where your data lives or why we picked a specific approach? E-mail info@joulo.nl or give us a call.
Joulo B.V. Brummen, NL KvK 42023359
Want to go deeper into the stack?
For partners and developers we have more in-depth documentation of the platform, the OAuth stack, the OCPP CSMS and the white-label options.