ChargePointStatus Webhook

Description

The ChargePointStatus webhook is triggered whenever the status of a charge point connector changes on a Fuzz-managed station.

When a charging station reports a status change via an OCPP StatusNotification message, Fuzz evaluates whether the status has actually changed compared to the previously known state. If a real transition is detected, this webhook event is sent to notify your system of the new connector status.

This webhook fires on the Pre-Status Notification hook, meaning it is sent before Fuzz forwards the notification upstream to the CPO.

Note: If the reported status is identical to the last known status, no webhook is sent - Fuzz deduplicates unchanged notifications to avoid redundant events.

Payload Structure

The webhook uses the standard Fuzz envelope with a ChargePointStatus-specific payload:

{
  "eventId": "3c977fbe-ee7b-4f61-bdd5-035a77e56437",
  "eventType": "ChargePointStatus",
  "siteId": "y1u00tdl",
  "timestamp": "2023-10-01T12:00:00+02:00",
  "payload": {
    "stationId": "jvpfa6ie",
    "chargePointId": "1sjn7tza",
    "connectorId": 1,
    "status": "Charging",
    "errorCode": "NoError",
    "info": "Connector operating normally"
  }
}

Envelope Fields

Field	Type	Description
eventId	string	Unique identifier of the webhook event (UUID).
eventType	string	Always "ChargePointStatus" for this event type.
siteId	string	The unique identifier of the site where the station is located.
timestamp	string	ISO 8601 timestamp in the Europe/Brussels timezone.

Payload Fields

Field	Type	Required	Description
stationId	string	Yes	The unique identifier of the station that reported the status change.
chargePointId	string	Yes	The identifier of the charge point whose status changed.
connectorId	integer	Yes	The connector ID on the charge point.
status	string	Yes	The new status of the connector. See the Status Values table below.
errorCode	string	Yes	The error code reported by the charge point. See the Error Codes table below.
info	string	No	Additional free-form information related to the status or error, provided by the station.

Status Values

Status	Description
Available	The connector is available and ready to start a new session.
Preparing	The connector is preparing for a charging session.
Charging	The connector is actively charging a vehicle.
SuspendedEVSE	Charging is suspended by the EVSE (station).
SuspendedEV	Charging is suspended by the EV (vehicle).
Finishing	The connector is finishing a charging session.
Reserved	The connector is reserved for a future session.
Unavailable	The connector is unavailable and cannot accept sessions.
Faulted	The connector is in a faulted state and requires attention.

Error Codes

Error Code	Description
NoError	No error is present.
ConnectorLockFailure	The connector lock mechanism failed.
EVCommunicationError	Communication error with the vehicle.
GroundFailure	Ground fault detected.
HighTemperature	High temperature detected on the connector.
InternalError	Internal error on the charge point.
LocalListConflict	Conflict with the local authorization list.
OtherError	An unspecified error occurred.
OverCurrentFailure	Over-current condition detected.
PowerMeterFailure	Power meter failure detected.
PowerSwitchFailure	Power switch failure detected.
ReaderFailure	RFID reader failure.
ResetFailure	Reset operation failed.
UnderVoltage	Under-voltage condition detected.
OverVoltage	Over-voltage condition detected.
WeakSignal	Weak signal detected (typically for Plug & Charge).

Retry Mechanism

Fuzz implements a robust queue-based delivery system for webhook events to ensure reliable notification:

Queue Processing

• Each webhook type maintains a dedicated background thread that processes events from a bounded queue (capacity: 1000 messages).
• When a status change event occurs, it is enqueued and processed asynchronously by the dedicated thread.
• If the webhook is disabled for a site, the thread is gracefully interrupted.

Retry Policy

• For each HTTP request, Fuzz applies a fixed-delay retry strategy:
  • Up to 360 retry attempts with a 10-second interval between retries.
  • This provides a maximum retry window of approximately 60 minutes per request.
• If all retry attempts fail, the error is logged with the Webhook_SendHttp exception type and the event is discarded to prevent queue buildup.

Health Monitoring

The webhook executor exposes health metrics for monitoring:

• Last queue consumption: Timestamp of the last dequeued message.
• Queue size: Current number of pending messages (alerts if > 5, critical if > 100).
• Last webhook request: Timestamp and duration of the last HTTP request (alerts if > 500ms, critical if > 5000ms).

Example HTTP Request

Below is an example of a signed HTTP request sent by Fuzz for a ChargePointStatus webhook:

POST /webhook/events HTTP/1.1
Host: partner.example.com
Content-Type: application/json
Content-Length: 438
x-request-id: 3c977fbe-ee7b-4f61-bdd5-035a77e56437
Signature-Input: sig1=created=1696176000;keyId="webhook";alg="rsa-pss-sha256";headers="@method @path x-request-id"
Signature: MEUCIQDX4p6vK8fN2mR7sT1uV3wX5yZ0aBcDeFgHiJkLmNoPqRsTuVw

{
  "eventId": "3c977fbe-ee7b-4f61-bdd5-035a77e56437",
  "eventType": "ChargePointStatus",
  "siteId": "site123",
  "timestamp": "2023-10-01T12:00:00+02:00",
  "payload": {
    "stationId": "station456",
    "chargePointId": "cp789",
    "connectorId": 1,
    "status": "Charging",
    "errorCode": "NoError",
    "info": "Connector operating normally"
  }
}

Signature Headers

All requests are signed following the RFC 9421 standard:

Header	Description
x-request-id	Unique identifier for the request, generated as a UUID.
Signature-Input	Declares the signature parameters: created timestamp, keyId identifier, signing algorithm (alg), and the list of HTTP components included in the signature (@method, @path, x-request-id).
Signature	The cryptographic signature over the declared components, generated using the Fuzz edge keystore.

Verifying the Signature

The public key used to verify webhook signatures is available via the JWKS endpoint:

https://auth.fuzz.energy/.well-known/jwks.json

Use the key with kid: "sign" to validate the signature. This allows you to cryptographically verify that each webhook request originates from Fuzz and has not been tampered with in transit.