Skip to main content
EVPanda is an observability platform for EV charging infrastructure. You embed an SDK in the systems you already run — your OCPP CSMS, your OCPI server — and EVPanda records the protocol traffic that flows through them, validates every message, and gives your team one place to search it. An online charger isn’t necessarily a working one. Neither is a roaming partner that returns 200 OK on every call. EVPanda tells you the difference.

Get started

Install an SDK and send your first captured message.

Core concepts

Networks, identity, and what the SDK records.

What you get

A searchable message log

Every OCPP frame and OCPI exchange, decoded and indexed — searchable by charger, roaming partner, tenant, action, or tag.

Protocol validation

Each message checked against OCPP 1.6 and OCPI 2.2.1 rules, well past schema, into cross-field and cross-message logic.

Behavioral anomalies

Traffic that breaks no rule but breaks your network — silent chargers, unanswered calls, sequences that never complete.

Failure attribution

Every issue tied to the charger or partner it came from, so you stop guessing whose side the problem is on.

Supported protocols

SDKs ship for Go, Node, and Python. See Getting started for versions and availability.

How it works

Four moving parts, and traffic flows one way through them.
1

The SDK captures

You call it where you already handle protocol traffic — a WebSocket read loop for OCPP, an HTTP handler or client for OCPI. Each capture validates the identity, enforces a size cap, redacts secrets, buffers the message, and returns. No network call happens on your thread.
2

The SDK delivers

One background worker per client flushes when a full batch of 1,000 messages is waiting or the flush interval elapses, compresses it, and POSTs it. Failed deliveries retry with capped backoff; under sustained failure the SDK drops its own oldest captures rather than growing without limit.
3

The ingestion API accepts

It authenticates the batch, validates each message independently, and writes the valid ones to durable storage before returning. It never asks your SDK to retry a batch that will always fail.
4

The validation engine analyzes

Stored messages are checked against protocol-aware rules built for OCPP 1.6 and OCPI 2.2.1. Findings become issues, grouped by type.
5

The dashboard shows

Messages, issues, chargers, and roaming platforms — with one search box across all of them.
Capture is passive. The SDK is not a proxy and not middleware in the protocol sense — it never rewrites a frame, alters a response, delays a handler, or fails a request because EVPanda is unreachable.

Issues

An issue is a finding about one message, grouped with every other occurrence of the same finding. A charger that sends a malformed StatusNotification ten thousand times produces one issue with a count of ten thousand — not ten thousand rows. Each group carries a severity, the validation stage and message part it came from, the charger or platform it affects, a 7-day occurrence trend, and a link straight to the messages that triggered it.

Error

The message violates the protocol. A conforming implementation would not have sent it.

Warning

Legal but questionable — a missing optional field the spec says you should send, a value that looks wrong.

Anomaly

Nothing breaks a rule, but the behavior around it does. This is the class that catches “online but not working”.

What gets caught

Cross-field rules catch what schemas can’t: a TxProfile charging profile set on connector 0, a StatusNotification reporting a connector-specific status on connector 0, a connectorId outside the range the charger reported at boot.
Two per-network settings shape the issue stream — anomaly detection and reject unknown JSON fields — along with the OCPP call and idle timeouts. See Networks. While validating, the pipeline extracts tags: the identifiers that matter inside a payload, pulled from the URL, headers, body, or connection. Session IDs, location IDs, transaction IDs, and token IDs all become searchable. That is what makes the global search box useful during an incident — paste a session ID from a customer complaint and get every message across both protocols that touched it.

Where to go next

Networks

How EVPanda organizes your systems, and how to get an API key.

Identity

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

What gets captured

Event shapes, redaction, size limits, and retention.

Getting started

Install an SDK, configure it, and instrument your service.