top of page

Stop Rebuilding Chargers: EV Charging API Integration for UK Developers

Writer: Swift Charging
Swift Charging
Oct 3
8 min read

Developer testing commercial EV charging integration

A production EV charging API integration must expose real-time availability, remote start and stop commands, session and billing records, connector metadata and secure authentication, all working together without gaps. Polling will not get you there reliably: event-driven updates through webhooks or WebSockets are the practical way to hit real-time expectations. Before writing a single line of code, check which protocols your charge point network actually supports.

 

TL;DR:  
  • Implement event-driven updates using webhooks or WebSockets to reliably meet the regulation-mandated 30-second status update requirement.

  • Model and manage static data, live status, control commands, and session records consistently to support features like billing, roaming, and control.

  • Use OCPP 2.0.1 for station control, OCPI for roaming and payment exchange, and only adopt ISO 15118 if Plug & Charge or vehicle-to-grid functions are essential.

  • Design a flexible architecture with a lightweight API facade and a robust backend to handle protocol complexities and ensure system reliability.

  • Prioritize reliable status updates and session management over early protocol feature adoption to ensure regulatory and user trust compliance.

 



Table of Contents

 

 

Data and command surface: what fields and endpoints you will need

 

Every integration rests on a handful of data objects, and getting these right early saves weeks of rework later. Reference data covers location, connector types, power rating, payment options, operating hours and tariffs: the static information a driver or app needs before they arrive. Status objects describe the live state of each EVSE and connector, and should carry consistent field names and timestamps so your system can reconcile events arriving out of order.

 

Control commands are where the integration becomes interactive, and they need to be designed defensively from day one.

 

  • RemoteStartTransaction and RemoteStopTransaction initiate and end a charging session remotely.

  • Unlock and Reserve commands manage physical access and booking.

  • Set charge profile commands push power limits or schedules to the charger.

  • Session records and CDRs capture what actually happened, including signed meter values needed for reconciliation and billing.

 

Get these four groups modelled consistently and most downstream features, from fleet dashboards to payment reconciliation, become a matter of composition rather than rebuilding.

 

Standards and protocols: OCPP, OCPI and ISO 15118 explained

 

Three standards do most of the work in this space, and each solves a different problem. OCPP governs communication between the charger and the central system, essentially the station’s management link. OCPI handles roaming and data exchange between charge point operators and e-mobility service providers, letting a driver use one app across many networks. ISO 15118 enables Plug & Charge authentication and underpins bidirectional charging scenarios.

 

Version choice matters more than it might first appear.

 

  • OCPP 1.6 is widely deployed and simpler to implement, but lacks a formal device model and modern security profiles.

  • OCPP 2.0.1, approved as the IEC 63584 standard, adds a device model, TransactionEvent reporting and stronger smart-charging capabilities, though it is not backward compatible with 1.6.

  • OCPI has become the de facto standard for roaming, with core modules including Versions, Credentials, Locations, Sessions, CDRs and Tariffs, and a Commands module that the EVRoaming Foundation recommends for remote driver control.

  • ISO 15118 adds certificate-based authentication and is the foundation for vehicle-to-grid charging, but it introduces real certificate lifecycle management overhead.

 

OCPP 2.0.1 includes formal IEC recognition, providing standards backing that supports long-term platform decisions.

 

A sensible default: implement OCPP for station control, OCPI for roaming and payment data exchange, and only take on ISO 15118 where Plug & Charge or vehicle-to-grid support is a genuine requirement. For a deeper comparison of device models and security profiles, our technical guide to the OCPP protocol covers the implementation detail.

 

Integration patterns and architecture: direct, wrapper or hub

 

Three architectural patterns dominate this space, and the right one depends on your team’s size and appetite for operational work.

 

  1. Direct OCPP integration gives you full control over charger behaviour but demands building and maintaining state machines, heartbeat monitoring and reconnection logic yourself.

  2. REST or webhook wrappers sit on top of the protocol complexity and let app teams ship features faster, at the cost of some flexibility.

  3. OCPI hubs or clearing houses avoid the need for many-to-many connections when you are integrating with multiple charge point operators for roaming, since a single interoperable interface replaces dozens of bespoke links, according to the EVRoaming Foundation.

 

For availability and session updates, event-driven design using webhooks or WebSocket push is the pattern that meets both regulatory timing requirements and user expectations for live status.

 

Pro Tip: Pair a lightweight REST façade for your app layer with a backend service that absorbs the protocol complexity: it keeps feature releases fast without exposing your front end to charger-level reconnection logic.


Layered EV charging integration architecture

Our dynamic load balancing guide walks through how this architecture supports smart-charging strategies in practice.

 

Developer workflow: auth, idempotency, metering and testing

 

A handful of workflow decisions determine whether an integration holds up under real traffic.

 

  • Authentication typically means choosing between API keys, OAuth or certificate chains, with ISO 15118 deployments adding ongoing certificate renewal and revocation management.

  • Idempotency keys on start and stop operations stop a retried request from triggering a duplicate session or a stuck state.

  • Metering relies on signed meter values and clock-aligned timestamps so CDRs reconcile cleanly with billing.

  • Testing should use protocol simulators, vendor sandboxes and staged chargers, with end-to-end tests covering webhook delivery and failure scenarios, not just the happy path.

  • Observability needs webhook replay queues and active monitoring of heartbeats and error alarms, since a silent charger is often worse than a loud failure.

 

Pro Tip: Log every status transition with a sequence number as well as a timestamp: out-of-order webhook delivery is common, and sequence numbers let you detect and correct it without guesswork.

 

Designing for the Public Charge Point Regulations 2026

 

If you are building for the market, compliance is not a bolt-on feature, it shapes your data model from the start. The Public Charge Point Regulations 2023 require operators to publish accurate, machine-readable reference and availability data, and to update EVSE status within 30 seconds of a change.

 

EVSE status must update within 30 seconds of a change under the regulations, which rules out slow polling as a viable architecture for compliant systems.

 

Practical implications for your API design:

 

  • OCPI is the natural data format to meet the machine-readable reference and availability requirement.

  • Status objects need to carry enough metadata to satisfy both the regulator and your own operational dashboards.

  • Contactless payment support and roaming connections are operational obligations alongside the data requirements, not optional extras.

  • Push-based updates, signed meter values and synchronised reference data together form a credible compliance baseline.

 

Our guide to UK charge point regulations sets out what operators must do in full.

 

Mapping API features to smart charging, fleets and payments

 

Different commercial scenarios draw on different parts of the API surface, and knowing which modules map to which use case saves a lot of wasted implementation effort.

 

  • Smart charging relies on ChargingProfiles, ChargingSchedule and the Commands module to push local or central setpoints to chargers, as described in the EVRoaming Foundation’s OCPI versions documentation.

  • Fleet management needs session metadata, driver identity, reservation handling and detailed billing records to allocate cost accurately across vehicles and depots.

  • Public roaming depends on Locations, Tokens, Tariffs and hub-based OCPI connectors so a single app can authenticate across many networks.

  • Direct payment terminals use the OCPI Direct Payment module flow, where a terminal requests a session and later submits financial advice confirmation for invoicing, as outlined in EVRoaming’s Direct Payment documentation.

 

Fleet operators planning electrification at scale will find more on grant-linked infrastructure decisions in our piece on future-proofing transport fleets.

 

Lessons from Swift Charging deployment projects

 

Commercial rollouts surface decisions that documentation alone rarely covers.

 

  • Projects for business sites, including those for Vanfridge and Carl Zeiss, favoured a wrapper API approach over direct protocol handling, which let app and reporting features ship without rebuilding charger connection logic for each site.

  • Contactless and roaming payment requirements were handled by routing payment events through the back-office platform rather than embedding payment logic in individual chargers.

  • Ongoing monitoring and maintenance agreements, paired with support identifying available grants, kept operational overhead predictable after go-live.

 

Why reliability has to come before feature parity

 

Chasing every protocol feature at launch is a common mistake. Regulatory deadlines and driver trust depend on dependable status updates and clean session records far more than they depend on an early feature checklist. Our recommendation: ship a lightweight wrapper API for your app layer, and let a robust backend absorb the protocol and certificate complexity behind it. If you are scoping a build, a technical conversation early on tends to save far more time than it costs.

 

— Swift Charging

 

How Swift Charging supports your integration and rollout

 

Building and maintaining charger-level protocol handling is a significant undertaking alongside shipping an app or management platform, and you do not have to carry it alone. Swift Charging supports UK businesses through the practical aspects of EV charging infrastructure, so your integration work sits on solid hardware and back-office foundations.


Swiftcharging

  • Site surveys and feasibility assessments for workplace, fleet or public charging projects.

  • Charger supply, installation and commissioning across AC and DC hardware.

  • Back-office software integration, including payment, RFID and load management.

  • Grant application support to help reduce installation costs where businesses are eligible.

 

Our commercial EV charging solutions cover everything from a single workplace installation to multi-site fleet charging, and our fleet EV charging services are built specifically for depot and route operators. Get in touch to arrange a technical scoping call.

 

Where to go deeper

 

 

Sources

 

 

FAQ

 

Is there a free API that can find EV charging stations?

 

Several charge point networks and aggregators publish open or low-cost APIs for location and availability data, often built on the OCPI standard. Coverage and update frequency vary by provider, so check each API’s documentation for its data refresh rate before relying on it for a live product.

 

What is the 80% rule for EV?

 

It is a vehicle and battery management consideration rather than an API specification.

 

Is CCS or NACS better?

 

Neither connector is universally better: CCS is the established standard across most of Europe and is widely supported by public and workplace charging infrastructure, while NACS has gained traction primarily in North America. Your choice depends on the vehicles and region you are deploying for, not on API design.

 

Does Octopus support V2G?

 

Some energy suppliers have trialled or launched vehicle-to-grid tariffs and programmes, though availability depends on compatible hardware and vehicle models and can change over time. Check the current offering directly with the supplier, since V2G support is not something a charging API alone can guarantee.

 

What does the Public Charge Point Regulations 2023 require from an API?

 

The regulations require operators to publish accurate, machine-readable reference and availability data and to update charger status within 30 seconds of a change. In practice, this means event-driven status updates rather than slow polling, typically delivered through an OCPI-based data model.

Recommended

 

 
 
bottom of page