EVPanda documentation

EVPanda records the protocol traffic your systems already exchange, validates it, and gives your team one place to search it. You embed an SDK in your OCPP CSMS or OCPI server. It captures messages, buffers them in memory, and ships them in batches to the EVPanda ingestion API. Capture is passive: it never rewrites a frame, delays a handler, or fails a request.

​

What you get

​

Supported protocols

SDKs ship for Go, Node, and Python.

​

How it works

1. The SDK captures. Each call validates the identity, caps the payload size, strips secrets, buffers the message, and returns. No network call runs on your thread.
2. The SDK delivers. One background worker flushes when 1,000 messages are waiting or the flush interval elapses, compresses the batch with zstd, and posts it. Failures retry with capped backoff.
3. The ingestion API accepts. It authenticates the batch, validates each message independently, and stores the valid ones.
4. The validation engine analyzes. Stored messages are checked against protocol rules. Findings become issues.
5. The dashboard shows. Messages, issues, chargers, and platforms, with one search box across all of them.

​

Issues

An issue is a finding about one message, grouped with every other occurrence of the same finding. Ten thousand malformed StatusNotification frames produce one issue with a count of ten thousand. Each group carries a severity, the charger or platform it affects, a 7 day trend, and a link to the messages that triggered it.

​

Next