CSMS API: how to integrate EV charging with parking, buildings and the rest of your systems

You have a working charging station and a system that manages it. Sessions are settled, drivers pay, invoices are generated. And then a question comes up that every company growing its EV infrastructure asks sooner or later: “since all of this already works, can I connect charging to my parking system, to building automation, to our backend, or to the app my customers already use?”.

The answer is: yes — and that is exactly what a CSMS API is for.

In this article we explain what an API is in a charging management system (CSMS), how its two pillars work — the REST API and webhooks — and how to use that single integration layer to connect EV charging with parking, building and fleet systems. Along the way we tidy up the standards every integrator eventually asks about: OCPP, OCPI, ISO 15118 and AFIR. At the end we show how to get started: where to get access, how to generate a token, and where to find the full documentation.

This is not an article about whether it is worth integrating. It is a practical guide on how it is done and what to watch out for.

The charger is a device. The CSMS is the brain. The API is the nervous system.

Let’s start by clarifying the terms, because it is easy to misunderstand each other in integration conversations.

A charging station is a device: a connector, power, an energy meter, a modem. On its own it can charge a car, but it does not know who is charging, at what price, whom to invoice, or whether the driver is even allowed to use it.

The CSMS (Charging Station Management System) is the software that manages all of this: it registers stations, authorizes drivers, runs sessions, charges fees, issues invoices, monitors faults and reports. If you want to understand what such a system consists of and how it is built, we covered it separately in the article on what a CSMS is and how it is built.

The API is the layer through which other systems talk to the CSMS. It is what makes charging stop being an island and become part of a larger whole — a parking lot, a building, a fleet, or a platform your customers already use. Without an API, every integration is manual work, CSV exports and “copying data between systems”. With an API, it is a single call and a single event.

The EV24® public API is exactly one such consumer at the core of the platform: data flows from stations, through OCPP, into the CSMS — and from there, through the API, to your systems. We show the architecture of this layer on the EV24® Partner API page.

The two pillars of integration: REST API and webhooks

Every mature CSMS integration rests on two complementary mechanisms. Understanding the difference between them is the most important architectural decision you will make at the start.

The REST API works in a pull model — you query the platform and perform operations. Want to add a station, issue a SIM card, create an RFID token or fetch a list of clients? You send a request and get a response. Communication always goes in the direction: Your system → EV24®.

Webhooks work in a push model — the platform notifies you when something happens. Instead of asking every minute “has the session finished yet?”, you get a single HTTP request the moment charging actually ends. Communication goes in the direction: EV24® → Your system.

In practice, these two mechanisms work together. The classic pattern looks like this: a webhook signals an event (“session finished”), and the REST API lets you pull the details or perform the next operation (“fetch session data”, “update the status in my system”). This way you don’t have to poll the platform in a loop — you react exactly when there is something to process.

Why this matters for performance and cost

An integration built solely on polling is expensive and slow: either you ask too often and generate needless traffic, or too rarely and your system reacts with a delay. Webhooks solve this at the source — an event reaches you once, immediately, and only when it actually happened. That is the difference between a system that “checks every so often” and one that “knows right away”.

What you actually do through the EV24® API

Theory is theory, but an integrator cares about one thing: what exactly can I do. Below are the most common operations performed through the API — grouped by area and the assigned permission (scope), because access to each of them is controlled separately.

A key note: access to the API is based on a token and on scopes that limit what a given token can do. A token with read-only access to stations cannot create an RFID token or invite a client. This is not “all or nothing” — it is precisely granted permissions, matched to the role of the integration.

Anatomy of a good webhook: end of charging

Integration is best understood through a concrete event. Let’s take the most important one in practice: the end of a charging session.

In the traditional model your system would have to ask regularly: “has session 12345 finished yet?”. In the webhook model the platform sends you a POST request the moment charging actually ends. The notification contains what you need for further processing: the session identifier, the station and connector identifier, the used energy, the authorization method, and the link to the driver and vehicle.

Three rules everyone receiving webhooks must remember:

• Verify the origin. The platform attaches an authorization header you configured to every request. The receiving service should check it before processing anything.
• Respond with a 2xx code. After correctly accepting the notification, return 2xx. In case of an error (network, a non-2xx code), the platform retries according to its retry policy.
• Be idempotent. The same event may arrive more than once. Your system must handle it so that a single session is never settled twice — most simply, by a unique event identifier.

These three rules separate an integration that “works on a demo” from one that runs in production for years.

Standards you need to know before you start integrating

The EV charging market is one of the most standardized areas in energy. That is good news: you are not integrating with a closed, proprietary puzzle, but with a system that speaks well-known protocols. Below are the standards that will sooner or later come up in an integration conversation — and the role they play.

It is worth separating two layers. OCPP, OCPI and ISO 15118 are the “charging” standards — they describe how devices, platforms and vehicles talk to each other. The CSMS handles these and takes care of them for you. REST, webhooks and OAuth2 are the “integration” standards — this is how your system talks to the API. The greatest value of a good CSMS is precisely that it wraps the complexity of the OCPP and OCPI world in a simple, application-level API. If you want to dig into the foundation of this puzzle, we have a separate article on the OCPP protocol, and we discuss the regulatory requirements in the piece on AFIR and public charging stations.

Integration with parking systems

This is one of the most common and most profitable scenarios. Parking and charging are two services that physically happen in the same place — and without integration they are settled in two separate worlds.

Imagine a car park by a shopping mall or an office building. A driver enters, a camera reads the license plate (LPR/ANPR), the parking management system (PMS) starts charging for the stay. If the car is electric, the driver plugs it into the charger. Without integration they get two bills, from two systems, often with two payment methods. With integration — a single service.

How it works technically:

• Driver recognition. The parking system identifies the vehicle (plate, ticket, app) and through the REST API checks or creates the related token that authorizes charging.
• Starting and ending a session. Charging is run by the CSMS, and a webhook about the end of the session reaches the parking system with the used energy and time.
• Shared settlement. The PMS combines the cost of the stay with the cost of energy on a single bill — or applies business rules, e.g. “the first hour of charging free for mall customers”.
• Infrastructure control. Charging events can trigger actions on the parking side (e.g. releasing a spot, notifying staff about an occupied EV bay after charging ends).

The business effect is measurable: the car park stops “losing” energy revenue, and the driver gets one, coherent service. The whole integration rests on two elements you already know: the REST API for managing tokens and data, and the webhook about the end of charging for settlement.

Integration with building systems

The second big area is building automation and management. Here the stakes are different than in a car park — it is less about settlement and more about power, safety and energy costs.

A building has a limited connection capacity. If twenty chargers sit in the underground garage of an office building, they cannot all charge at full power at once, because they would exceed the connection limit or lead to costly overruns of the contracted capacity. This is where integration with the building management system (BMS) and energy management (HEMS/EMS) comes in.

Typical building integration scenarios:

• Dynamic power sharing (load balancing). The building system passes the CSMS information about available power, and it distributes that power between stations in real time. We write about this in more detail in the article on charging power management.
• Priorities and schedules. The building can define that during office peak hours charging has a lower priority than air conditioning, and at night — the highest.
• Photovoltaics and energy storage. Surplus energy from panels can be directed to charging instead of being fed back to the grid; the CSMS gets a signal about available “green” power.
• Reacting to available power. When the building runs short of power at peak, charging is turned down instead of shutting off other systems — and returns to full power as soon as capacity frees up.

In these scenarios the API works both ways: the building reads the charging state and controls the available power, and session events reach the energy system. It is worth stressing: it is the CSMS that takes on the conversation with specific chargers over OCPP, while the building talks to a single, coherent API layer. Without it, every new device would mean a separate integration.

Integration with a fleet and a partner app

The third scenario, alongside parking and buildings, is integration with a fleet system or with an app the partner already offers to its users. Here the API plays the role of a “charging engine” hidden under someone else’s brand and interface.

A fleet operator wants to see charging where it sees fuel, servicing and costs — that is, in its own fleet system, not in yet another separate portal. Through the REST API it fetches the list of stations and tokens, assigns cards to specific drivers or vehicles, and through webhooks receives every finished session with the used energy and the driver identifier. Settlement and the energy cost report are produced automatically, alongside the fleet’s other costs.

Integration with a partner app works similarly. The partner builds its own user experience — login, map, history — while the charging operations (authorization, session, settlement) run through the EV24® API. The end customer does not know that a CSMS is working “underneath”; they see a coherent single-brand app. This is a white label model at the integration layer: the whole complexity of charging is available programmatically, while the brand and interface belong to the partner.

In all of these cases the same pattern that runs through the whole article repeats: the REST API for managing data and configuration, webhooks for reacting to events. Only the system on the other side changes — parking, building, fleet or app.

The most common mistakes when integrating with an API

Before we get to launching, it is worth listing the traps that most often delay rollouts or break them in production. Each of them only becomes visible once traffic grows.

• Relying solely on polling. An integration built only on periodically GET-ting statuses is slow and expensive. If you react to events, use webhooks — leave polling for situations where you genuinely need to ask.
• No idempotency. Assuming each event will arrive exactly once will sooner or later end in double settlement. A uniqueness key (the event identifier) is not an option but a requirement.
• Treating a webhook as trusted input. The endpoint that receives notifications is public. Without verifying the authorization header you expose yourself to fake requests.
• Tokens that are too broad. A single “do-everything” token is a risk and makes diagnostics harder. Grant scopes matched to a specific integration.
• Ignoring pagination. Searches return results in pages. An integration that fetches “only the first page” will start losing data after a few months.
• No handling of retries and limits. Your receiver will sometimes be unavailable, and the API applies rate limits. Design a queue, exponential retries and handling of rate-limit responses.

The good news is that all of these mistakes are well known and all have simple, proven solutions. It is enough to think about them at the design stage, not after the first incident.

Integration security — what you must not skip

Integrating through an API means opening a channel to data about infrastructure, drivers and payments. A few rules that are built into EV24®’s access model and that you should follow on the integrator side:

• A Bearer token instead of passwords. You authenticate to the API with a token in the Authorization header. The token lives on your integration’s server, never in a browser client.
• Scopes instead of full access. Each token gets only the permissions it truly needs. A settlement integration does not need the right to create RFID tokens.
• Rotation and revocation. Generating a new token immediately invalidates the previous one; a token can also be revoked manually. Once API access is disabled, all related tokens stop working.
• Webhook verification. The authorization header attached to every notification is your mechanism for confirming that the request really comes from the platform.
• Idempotency and logging. Store the identifiers of handled events and log calls. This saves you during diagnostics and protects against double settlement.

Security is not an add-on here — it is the price of entry. A well-designed integration treats the token as a production secret and a webhook as untrusted input that must be verified.

How to get started

Launching an integration with the EV24® API is a process, not a one-off “switch on”. In short, it looks like this:

1. Get API access. An administrator enables the API service for the partner or client profile and assigns scopes matching the integration’s scope.
2. Generate a token. In the portal, in the API settings section, you generate a token. It is shown only once — store it securely.
3. Configure webhooks. Specify the address notifications should go to, set the authorization header and choose the events (e.g. end of charging).
4. Build and test. Make the first REST calls, receive the first webhook, take care of idempotency and error handling.
5. Go to production. After testing, switch the integration to production data and enable monitoring.

The starting point is the EV24® Partner API page, where you will see the architecture and capabilities of the integration layer. You will find the full technical path — from getting access, through configuring permissions, to the first calls — in the EV24® API documentation for integrators. The interactive specification of all endpoints is available at api.ev24.cloud.

Summary

A charger will charge a car. But business value only arises when charging becomes part of a larger whole: a car park that settles the stay and the energy on a single bill; a building that shares power wisely and uses energy from panels; a fleet and a backend that see sessions in real time. That “glue” is a CSMS API.

Two pillars — the REST API for on-demand operations and webhooks for real-time events — cover practically every integration scenario. Market standards (OCPP, OCPI, ISO 15118, AFIR) bring order underneath, and a good CSMS wraps their complexity in a simple, secure API. Adding stations, issuing SIM cards, managing tokens, onboarding clients and automatically settling sessions — all of it stops being manual work and becomes code.

If you already have the infrastructure and a system that manages it, the next step is natural: connect charging with the rest of your world. Start with the Partner API page and the documentation for integrators.