How the registry works

Charger identity is a deterministic hash

A charger is identified by a SHA-256 hash of its canonical vendor and normalized serial number. The hash is deterministic and computed locally — any participant derives the same reference ID for the same charger without sharing the raw serial. The registry stores the hash and the last four characters of the serial, not the full serial.

Look up before you claim

An anonymous public lookup tells you whether a charger has an active registration, how many, and the period they cover — and nothing else. It never reveals which organization holds the registration. Authenticated registry members get the full entitled detail through the API or their dashboard.

Try a public lookup →

Register your claim

A single authenticated API call records your program’s registration for a charger and its start/end dates. Each registration is its own immutable ledger row; renewing creates a new row rather than editing the old one, so the history is preserved. When a new registration overlaps an existing one, the registry records an advisory conflict and returns the overlapping party so you can act on it.

Conflicts and disputes

Overlapping claims surface as conflicts. Either party can open a dispute, exchange messages, and the registry operator records the outcome the parties reach. The registry records dispute outcomes — it never decides ownership or allocates credit.

Read the dispute process →

Stay in sync with webhooks

Register a webhook endpoint and the registry will notify your systems when a registration is created, updated, expired or cancelled, when a conflict is detected, and when a dispute is created or resolved. Every delivery is signed with an EVR-Signature header so you can verify it came from the registry.