Skip to main content
A network is the container for everything EVPanda records about one of your systems. It owns the traffic, the discovered chargers or partners, the issues found in that traffic, and the API keys that write to it. Networks come in two kinds, one per protocol.

Charger network

Watches an OCPP 1.6 CSMS. Holds chargers, OCPP messages, and charger issues.

Roaming network

Watches an OCPI 2.2.1 server. Holds roaming platforms, OCPI exchanges, and roaming issues.
The two are separate on purpose: they hold different entities, are validated by different rule sets, and use different API keys. A CSMS that also speaks OCPI needs one network of each, and one SDK client of each.

​
How many networks should you create?

One per system, per environment.
Resist the urge to put staging traffic in your production network. Issue counts, error rates, and online-charger stats are only meaningful when they describe one real system.
Chargers, platforms, and tenants are discovered from traffic — you never register them by hand. The first message that carries a new charger ID creates that charger in the dashboard.

​
Network settings

Each network has settings that shape how its traffic is validated. Find them under the network’s Settings tab.
​
boolean
default:"false"
When enabled, a message carrying JSON fields that the protocol doesn’t define is reported as an issue. Turn it on for strict conformance work, off if your partners routinely send vendor extensions.
​
boolean
default:"true"
Enables the behavioral checks that flag traffic which breaks no protocol rule but signals a real problem. See Issues.
​
integer
default:"30"
Charger networks only. Seconds to wait for a CALLRESULT before an OCPP call counts as unanswered. Range: 1–600.
​
integer
default:"300"
Charger networks only. Seconds of silence after which a charger is treated as offline in the dashboard. Range: 30–900.
Roaming networks also carry the OCPI version and your OCPI role (CPO, EMSP, or HUB), which the validation engine uses to decide which side of an exchange is expected to do what.

​
API keys

An API key authorizes the SDK to write into exactly one network.
1

Generate

Open the network’s Settings tab and generate a key. The raw value — evp_sk_… — is displayed once, at creation. EVPanda stores only a hash of it, so it cannot be shown again.
2

Store

Put it in your secret manager and expose it to your service as EVPANDA_API_KEY. Every SDK falls back to that variable when no key is passed in code, which keeps the key out of your source.
3

Rotate

Generate the new key, deploy it, confirm traffic is still arriving, then revoke the old one. Revocation takes effect immediately.

​
What a key can and cannot do

Scoped to one network

A key written for a charger network cannot write OCPI traffic, and cannot reach any other network in your account.

Write-only

Ingestion keys only submit captured traffic. They cannot read messages, issues, or settings — the dashboard uses your user session for that.
An invalid key makes the ingestion API reject every batch with 401, which the SDK treats as permanent and does not retry. Nothing is buffered forever, and nothing arrives. Watch the SDK’s DroppedUndeliverable counter or its health log after a rotation.

​
The ingestion endpoint

All SDKs point at the same base URL, and append the protocol route themselves:
You never build these paths yourself — set endpoint to the base URL and the SDK does the rest.

​
Next

Identity

How every message is attributed to a charger, a partner, and a tenant.

What gets captured

The exact shape of an OCPP event and an OCPI exchange.