Identity

EVPanda attributes every message to something in your network — a charge point, or a roaming partner. That attribution is what makes the dashboard useful: it is how a message becomes “this charger”, how an issue becomes “this partner’s fault”, and how traffic splits per tenant. Identity is per message, not global configuration. One process can serve thousands of chargers or dozens of roaming partners, so the SDK asks who a message belongs to at the moment you capture it, not at the moment you start the client.

The two shapes

OCPP
OCPI

A charge point is identified by a charger ID: whatever your CSMS already uses to name a charge point.

Field	Required	Max length
`chargerId`	Yes	64
`tenantId`	Optional pair	64
`tenantName`	Optional pair	32

OCPP identity is known at connect time — you resolve the charge point during the WebSocket handshake, before any frame arrives — so you supply it once per connection and the session handle carries it for every frame.

id := evpanda.ChargerIdentity{ChargerID: "CP-001"}

const id = { chargerId: "CP-001" };

id = ChargerIdentity(charger_id="CP-001")

A roaming partner is identified by a platform ID and name. Both are required: the ID is what EVPanda groups on, the name is what your team reads in the dashboard.

Field	Required	Max length
`platformId`	Yes	64
`platformName`	Yes	64
`tenantId`	Optional pair	64
`tenantName`	Optional pair	32

OCPI identity is per request — it comes out of the token or credentials the partner presented — so you resolve it per exchange, usually in the same place your auth layer already looks the partner up.

id := evpanda.RoamingIdentity{
    PlatformID:   "acme",
    PlatformName: "Acme Mobility",
}

const id = { platformId: "acme", platformName: "Acme Mobility" };

id = RoamingIdentity(platform_id="acme", platform_name="Acme Mobility")

Identity is always the partner on the other side of the exchange, never your own platform — in both directions. When a partner pushes you a CDR, it’s their identity. When you pull their locations, it’s still their identity.

Tenants

tenantId and tenantName are optional, and all-or-nothing: supply both or neither. A half-set pair fails validation and the message is dropped. Use tenants when one deployment serves several distinct operators — a CPO platform hosting sub-operators, a white-label CSMS, a hub carrying several parties. The dashboard uses them to filter chargers, platforms, messages, and issues, and to report per-tenant activity.

evpanda.ChargerIdentity{
    ChargerID:  "CP-001",
    TenantID:   "cpo-42",
    TenantName: "Acme Energy",
}

{
  chargerId: "CP-001",
  tenantId: "cpo-42",
  tenantName: "Acme Energy",
}

ChargerIdentity(
    charger_id="CP-001",
    tenant_id="cpo-42",
    tenant_name="Acme Energy",
)

If you have a single operator, leave them out entirely. You can start sending them later; tenants are discovered from traffic like everything else.

OCPP is the exception today. The SDKs treat the tenant pair as optional for both protocols, but the ingestion API currently requires it on OCPP messages and rejects those that omit it — server-side, after a successful delivery, so nothing in the SDK reports it.Until that is relaxed, send a tenant pair on OCPP even in a single-tenant CSMS. A constant value such as your own operator name is fine. See Getting started.

Choosing good identifiers

Use the ID your systems already use

A charger ID should be the same string your CSMS, your support tooling, and your field team all say out loud. Usually that’s the OCPP identity from the WebSocket URL path. Don’t mint an EVPanda-specific ID — you’ll spend the rest of the year translating between them.

Keep IDs stable, keep names readable

platformId and tenantId group your data over time, so they must not change for the same entity. platformName and tenantName are display strings, and can be updated freely; EVPanda shows the most recent one it has seen.

Don't put secrets in identity fields

Identity is stored and shown in the dashboard. It should identify a partner or a charger, not authenticate one. Never pass a token, a Token B, or a client certificate fingerprint as an ID.

Mind the length limits

The ingestion API rejects a message whose tenantName exceeds 32 characters, or whose other identity fields exceed 64. Long partner names get truncated at the source, not in the dashboard — trim them before you pass them in.

What happens to an unattributable message

The SDK validates identity at capture, before anything is buffered. A message that fails validation is dropped silently — it is not queued, not sent, and never raises an error into your code. An identity is invalid when:

A required field is empty, missing, or whitespace only.
Exactly one of tenantId / tenantName is set.

Dropping is deliberate: a message EVPanda can’t attribute would arrive as an orphan that nobody can search for or act on. But because the drop is silent, it is also the most common reason for “the SDK isn’t sending anything”. Every SDK counts it.

Symptom	Likely cause
Everything drops, no traffic at all	An HTTP adapter is mounted before your auth layer, so no identity is resolved yet
One partner drops	Your resolver returns an empty `platformName` for them
Random messages drop	A half-set tenant pair — one field populated, the other blank

In Go, read panda.Stats().DroppedInvalid. In Node and Python, turn on debug. See Getting started.

The HTTP adapters treat “no identity” as “don’t capture”, not as an error. A request the adapter can’t attribute is served exactly as it would have been — your partners never see a difference.

Core concepts

SDK integration

The two shapes

Tenants

Choosing good identifiers

What happens to an unattributable message

​The two shapes

​Tenants

​Choosing good identifiers

​What happens to an unattributable message

The two shapes

Tenants

Choosing good identifiers

What happens to an unattributable message