EV Charging API and Webhooks: A Practical Integration Guide

Charging data rarely stays in the charging platform. Finance wants energy costs in the accounting system, fleet managers want consumption per vehicle next to telematics data, and management wants charging figures in the same dashboards as everything else. Copying CSV files every month works for a while, but it does not scale.

An EV charging API solves this by letting other systems read charging data and react to charging events automatically. This guide explains why and where to integrate, the difference between REST APIs and webhooks, what data is typically available, how to secure webhooks with HMAC signatures, and how to roll out an integration safely. It includes a generic pseudo-code example you can adapt to any language.

Why integrate charging data?

A charging management system (CSMS) is the source of truth for sessions, energy and charger status. Other systems need parts of that data:

• ERP and accounting: post charging costs per site, department or cost center without manual entry.
• Fleet management: add energy per vehicle and per driver to vehicle records. See our fleet charging management guide for how cost allocation works.
• Business intelligence (BI): combine utilization and energy data with other business data in one reporting tool.
• Property and facility systems: allocate charging energy to tenants, residents or hotel guests.
• Internal notifications: inform a dispatcher when a vehicle has finished charging, or open a ticket when a charger faults.

Integration removes repetitive manual work, reduces transcription errors and makes data available sooner.

REST API vs webhooks

Most charging platforms offer two complementary integration methods.

In practice, robust integrations use both. Webhooks deliver events quickly, and a periodic REST call reconciles the data and fills any gaps, for example if your endpoint was down for maintenance.

Typical data in an EV charging API

• Sessions: start and end time, station, connector, energy in kWh, identifier (card), driver and vehicle plate where available.
• Stations and connectors: identifiers, location, OCPP version, current status.
• Drivers and cards: which card belongs to which driver, and whether it is active or blocked.
• Vehicles: plates and the drivers they are linked to.
• Energy summaries: totals per station, driver, vehicle or period.

The exact resources, field names and filters differ between platforms, so always work from the official API documentation.

Webhook security: signatures, idempotency and retries

A webhook endpoint is a public URL. Anyone who knows it can send requests to it. Three practices make webhook handling safe and reliable.

1. Verify the HMAC signature

With HMAC signing, the platform and your system share a secret. For each delivery, the platform computes an HMAC-SHA256 value over the request body using that secret and sends it in a signature header. Your system computes the same value and compares the two. If they match, the request came from someone who knows the secret and the body was not changed on the way.

• Compute the HMAC over the raw request body, exactly as received. Parsing and re-serializing JSON can change spacing or key order and break the signature.
• Compare signatures with a constant-time function to avoid timing attacks.
• Store the secret like a password: in a secrets manager or environment variable, never in source code.
• If the platform includes a timestamp in the signed data, reject old deliveries to limit replay attacks.

2. Make handlers idempotent

Webhook delivery is usually "at least once". The same event can arrive twice, for example when your response was lost on the network. Store an identifier of each processed event, such as an event ID if the payload provides one, or a combination of session ID and event type, and ignore duplicates.

3. Respond fast and handle retries

Return a success status (a 2xx code) quickly and do heavy work in a background job. Slow handlers can time out and trigger redeliveries. Check the platform documentation for its retry behavior, and use scheduled REST calls to reconcile anything that was missed.

Example flow with pseudo-code

The following example shows a generic webhook handler that verifies the signature, removes duplicates and queues a "session stopped" event for processing. The header name, event names and payload fields are placeholders; use the values given in your platform's API documentation.

function handle_webhook(request):    raw_body  = request.raw_body            # bytes, before any JSON parsing    received  = request.header(SIGNATURE_HEADER)   # see API documentation    secret    = env("WEBHOOK_SECRET")    expected  = hex(hmac_sha256(key = secret, message = raw_body))    if not constant_time_equals(expected, received):        return response(status = 401)    event = json_parse(raw_body)    event_key = event.id or (event.session_id + ":" + event.type)    if processed_events.contains(event_key):        return response(status = 200)       # duplicate, already handled    processed_events.add(event_key)    queue.push(event)                       # heavy work happens later    return response(status = 200)function worker(event):    if is_session_stopped(event):        cost_center = lookup_cost_center(event.driver, event.vehicle)        erp.post_energy(cost_center, event.energy_kwh, event.ended_at)function nightly_reconciliation():    sessions = api.get_sessions(date = yesterday)   # REST API, API key    for session in sessions:        if not erp.has_session(session.id):            erp.post_energy(...)

Most languages provide an HMAC-SHA256 function and a constant-time comparison function in their standard library or a well-known cryptography package. Use those rather than writing your own.

Integration with Üreticy

Üreticy provides a REST API with API keys that you create and manage in the dashboard, and HMAC-signed webhooks for events such as session started and session stopped. The public API documentation describes the resources, event types, payloads and the signature header used for verification.

Because Üreticy manages OCPP 1.6J, 2.0.1 and 2.1 chargers in one dashboard, a single integration can cover a mixed charger estate. Learn more on the charging API and webhooks page.

Rollout tips

1. Start with one use case. For example, monthly energy per cost center posted to the ERP system.
2. Use separate API keys per integration. This allows you to revoke one integration without affecting others.
3. Grant the minimum access needed. A reporting integration should not be able to change configuration.
4. Test with real sessions. Compare API results with the dashboard and exported reports before going live.
5. Log every webhook delivery. Record the time, event type and result of signature verification to simplify troubleshooting.
6. Plan for key rotation. Know how to replace API keys and webhook secrets without downtime.
7. Monitor the integration. Alert when no webhooks arrive for an unusual period or when reconciliation finds gaps.

When you compare charging platforms, the quality of the API and webhooks deserves a place on the checklist. See how to choose OCPP software for a complete evaluation list.

Frequently asked questions

Connect charging sessions to your ERP, fleet or BI tools with a REST API and HMAC-signed webhooks. See the Üreticy charging API or read the API documentation.