CSMS-API: So integrieren Sie das EV-Laden mit Parken, Gebäuden und Ihren übrigen Systemen

Sie haben eine funktionierende Ladestation und ein System, das sie verwaltet. Ladevorgänge werden abgerechnet, Fahrer zahlen, Rechnungen werden erstellt. Und dann kommt eine Frage auf, die jedes Unternehmen mit wachsender EV-Infrastruktur früher oder später stellt: „Wenn das alles schon läuft — kann ich das Laden mit meinem Parkraumsystem, mit der Gebäudeautomation, mit unserem Backend oder mit der App verbinden, die meine Kunden bereits nutzen?“.

Die Antwort lautet: Ja — und genau dafür ist eine CSMS-API da.

In diesem Artikel erklären wir, was eine API in einem Ladeverwaltungssystem (CSMS) ist, wie ihre zwei Säulen funktionieren — die REST API und Webhooks — und wie Sie über diese eine Integrationsschicht das EV-Laden mit Parkraum-, Gebäude- und Flottensystemen verbinden. Unterwegs ordnen wir die Standards, nach denen jeder Integrator irgendwann fragt: OCPP, OCPI, ISO 15118 und AFIR. Am Ende zeigen wir, wie Sie starten: wo Sie Zugang erhalten, wie Sie ein Token generieren und wo die vollständige Dokumentation zu finden ist.

Dies ist kein Artikel darüber, ob sich eine Integration lohnt. Es ist ein praktischer Leitfaden dazu, wie man sie umsetzt und worauf man achten muss.

Die Ladestation ist ein Gerät. Das CSMS ist das Gehirn. Die API ist das Nervensystem.

Beginnen wir mit dem Ordnen der Begriffe, denn in Integrationsgesprächen kommt es leicht zu Missverständnissen.

Eine Ladestation ist ein Gerät: Anschluss, Leistung, Energiezähler, Modem. Für sich allein kann sie ein Auto laden, weiß aber nicht, wer lädt, zu welchem Preis, wem eine Rechnung zu stellen ist oder ob der Fahrer sie überhaupt nutzen darf.

Das CSMS (Charging Station Management System) ist die Software, die all das verwaltet: Sie registriert Stationen, autorisiert Fahrer, führt Ladevorgänge, berechnet Gebühren, erstellt Rechnungen, überwacht Störungen und erstellt Berichte. Wenn Sie verstehen möchten, woraus ein solches System besteht und wie es aufgebaut ist, haben wir das separat im Artikel was ein CSMS ist und wie es aufgebaut ist beschrieben.

Die API ist die Schicht, über die andere Systeme mit dem CSMS sprechen. Sie sorgt dafür, dass das Laden aufhört, eine Insel zu sein, und Teil eines größeren Ganzen wird — eines Parkplatzes, eines Gebäudes, einer Flotte oder einer Plattform, die Ihre Kunden bereits nutzen. Ohne API ist jede Integration Handarbeit, CSV-Export und „Daten zwischen Systemen abtippen“. Mit API ist es ein einziger Aufruf und ein einziges Ereignis.

Die öffentliche EV24® API ist genau ein solcher Abnehmer im Kern der Plattform: Daten fließen von den Stationen, über OCPP, ins CSMS — und von dort, über die API, zu Ihren Systemen. Die Architektur dieser Schicht zeigen wir auf der Seite EV24® Partner-API.

Die zwei Säulen der Integration: REST API und Webhooks

Jede ausgereifte CSMS-Integration ruht auf zwei sich ergänzenden Mechanismen. Den Unterschied zwischen ihnen zu verstehen ist die wichtigste architektonische Entscheidung, die Sie am Anfang treffen.

Die REST API arbeitet im Pull-Modell — Sie fragen die Plattform ab und führen Operationen aus. Möchten Sie eine Station hinzufügen, eine SIM-Karte ausgeben, ein RFID-Token erstellen oder eine Kundenliste abrufen? Sie senden eine Anfrage und erhalten eine Antwort. Die Kommunikation läuft immer in Richtung: Ihr System → EV24®.

Webhooks arbeiten im Push-Modell — die Plattform benachrichtigt Sie, wenn etwas passiert. Statt jede Minute zu fragen „ist der Ladevorgang schon beendet?“, erhalten Sie eine einzige HTTP-Anfrage in dem Moment, in dem das Laden tatsächlich endet. Die Kommunikation läuft in Richtung: EV24® → Ihr System.

In der Praxis arbeiten diese beiden Mechanismen zusammen. Das klassische Muster sieht so aus: Ein Webhook signalisiert ein Ereignis („Ladevorgang beendet“), und die REST API erlaubt es, die Details nachzuladen oder die nächste Operation auszuführen („Ladedaten abrufen“, „Status in meinem System aktualisieren“). So müssen Sie die Plattform nicht in einer Schleife abfragen — Sie reagieren genau dann, wenn es etwas zu verarbeiten gibt.

Warum das für Leistung und Kosten wichtig ist

Eine Integration, die ausschließlich auf Abfragen (Polling) beruht, ist teuer und langsam: Entweder fragen Sie zu oft und erzeugen unnötigen Datenverkehr, oder zu selten und Ihr System reagiert verzögert. Webhooks lösen das an der Quelle — ein Ereignis erreicht Sie einmal, sofort, und nur dann, wenn es wirklich passiert ist. Das ist der Unterschied zwischen einem System, das „ab und zu nachschaut“, und einem, das „sofort Bescheid weiß“.

Was Sie tatsächlich über die EV24® API tun

Theorie ist Theorie, aber einen Integrator interessiert eines: Was genau kann ich tun. Nachfolgend die häufigsten Operationen, die über die API ausgeführt werden — gruppiert nach Bereich und der zugewiesenen Berechtigung (Scope), denn der Zugriff auf jede von ihnen wird separat gesteuert.

Ein wichtiger Hinweis: Der Zugriff auf die API basiert auf einem Token und auf Scopes, die einschränken, was ein bestimmtes Token tun darf. Ein Token mit reinem Lesezugriff auf Stationen erstellt kein RFID-Token und lädt keinen Kunden ein. Das ist kein „alles oder nichts“ — es sind präzise vergebene Berechtigungen, abgestimmt auf die Rolle der Integration.

Anatomie eines guten Webhooks: Ende des Ladens

Am besten versteht man Integration an einem konkreten Ereignis. Nehmen wir das in der Praxis wichtigste: das Ende eines Ladevorgangs.

Im traditionellen Modell müsste Ihr System regelmäßig fragen: „Ist der Ladevorgang 12345 schon beendet?“. Im Webhook-Modell sendet die Plattform Ihnen eine POST-Anfrage in dem Moment, in dem das Laden tatsächlich endet. Die Benachrichtigung enthält, was Sie für die weitere Verarbeitung brauchen: die Kennung des Ladevorgangs, die Kennung von Station und Anschluss, die verbrauchte Energie, die Autorisierungsart sowie die Verknüpfung mit Fahrer und Fahrzeug.

Drei Regeln, an die jeder denken muss, der Webhooks empfängt:

• Herkunft prüfen. Die Plattform fügt jeder Anfrage einen von Ihnen konfigurierten Authorization-Header hinzu. Der empfangende Dienst sollte ihn prüfen, bevor er irgendetwas verarbeitet.
• Mit einem 2xx-Code antworten. Nach korrekter Annahme der Benachrichtigung geben Sie 2xx zurück. Im Fehlerfall (Netzwerk, ein Code außerhalb von 2xx) wiederholt die Plattform den Versuch gemäß ihrer Wiederholungsrichtlinie.
• Idempotent sein. Dasselbe Ereignis kann mehr als einmal eintreffen. Ihr System muss das so behandeln, dass ein einzelner Ladevorgang nie zweimal abgerechnet wird — am einfachsten über eine eindeutige Ereigniskennung.

Diese drei Regeln unterscheiden eine Integration, die „auf dem Demo läuft“, von einer, die jahrelang in Produktion läuft.

Standards, die Sie kennen müssen, bevor Sie mit der Integration beginnen

Der EV-Lademarkt ist einer der am besten standardisierten Bereiche der Energiewirtschaft. Das ist eine gute Nachricht: Sie integrieren nicht mit einem geschlossenen, proprietären Puzzle, sondern mit einem System, das bekannte Protokolle spricht. Nachfolgend die Standards, die in einem Integrationsgespräch früher oder später auftauchen — und die Rolle, die sie spielen.

Es lohnt sich, zwei Schichten zu trennen. OCPP, OCPI und ISO 15118 sind die „Lade“-Standards — sie beschreiben, wie Geräte, Plattformen und Fahrzeuge miteinander sprechen. Damit befasst sich das CSMS und kümmert sich für Sie darum. REST, Webhooks und OAuth2 sind die „Integrations“-Standards — so spricht Ihr System mit der API. Der größte Wert eines guten CSMS liegt genau darin, dass es die Komplexität der Welt von OCPP und OCPI in eine einfache, anwendungsnahe API kapselt. Wenn Sie das Fundament dieses Puzzles vertiefen möchten, haben wir einen eigenen Artikel zum OCPP-Protokoll, und die regulatorischen Anforderungen behandeln wir im Text zu AFIR und öffentlichen Ladestationen.

Integration mit Parkraumsystemen

Das ist eines der häufigsten und lukrativsten Szenarien. Parken und Laden sind zwei Dienste, die physisch am selben Ort stattfinden — und ohne Integration werden sie in zwei getrennten Welten abgerechnet.

Stellen Sie sich einen Parkplatz an einem Einkaufszentrum oder einem Bürogebäude vor. Ein Fahrer fährt ein, eine Kamera liest das Kennzeichen (LPR/ANPR), das Parkraumsystem (PMS) beginnt, die Standzeit zu berechnen. Ist das Auto ein Elektrofahrzeug, steckt der Fahrer es an die Ladestation. Ohne Integration erhält er zwei Rechnungen, aus zwei Systemen, oft mit zwei Zahlungsmethoden. Mit Integration — ein einziger Dienst.

Wie es technisch aussieht:

• Fahrererkennung. Das Parkraumsystem identifiziert das Fahrzeug (Kennzeichen, Ticket, App) und prüft oder erstellt über die REST API das zugehörige Token, das das Laden autorisiert.
• Start und Ende eines Ladevorgangs. Das Laden führt das CSMS, und ein Webhook über das Ende des Ladevorgangs erreicht das Parkraumsystem mit der verbrauchten Energie und der Zeit.
• Gemeinsame Abrechnung. Das PMS verbindet die Kosten der Standzeit mit den Energiekosten auf einer Rechnung — oder wendet Geschäftsregeln an, z. B. „erste Ladestunde gratis für Kunden des Einkaufszentrums“.
• Steuerung der Infrastruktur. Ladeereignisse können Aktionen auf der Parkseite auslösen (z. B. einen Platz freigeben, das Personal über einen belegten EV-Stellplatz nach Ladeende informieren).

Der geschäftliche Effekt ist messbar: Der Parkplatz „verliert“ keine Energieerlöse mehr, und der Fahrer erhält einen einheitlichen Dienst. Die gesamte Integration ruht auf zwei Elementen, die Sie bereits kennen: der REST API zur Verwaltung von Token und Daten und dem Webhook über das Ladeende für die Abrechnung.

Integration mit Gebäudesystemen

Der zweite große Bereich ist die Gebäudeautomation und -verwaltung. Hier steht anderes auf dem Spiel als auf einem Parkplatz — es geht weniger um Abrechnung und mehr um Leistung, Sicherheit und Energiekosten.

Ein Gebäude hat eine begrenzte Anschlussleistung. Stehen in der Tiefgarage eines Bürogebäudes zwanzig Ladestationen, können sie nicht alle gleichzeitig mit voller Leistung laden, weil sie das Anschlusslimit überschreiten oder zu kostspieligen Überschreitungen der bestellten Leistung führen würden. Hier kommt die Integration mit dem Gebäudemanagementsystem (BMS) und dem Energiemanagement (HEMS/EMS) ins Spiel.

Typische Szenarien der Gebäudeintegration:

• Dynamische Leistungsaufteilung (Lastmanagement). Das Gebäudesystem übergibt dem CSMS Informationen über die verfügbare Leistung, und dieses verteilt sie in Echtzeit auf die Stationen. Ausführlicher schreiben wir dazu im Artikel zum Lastmanagement beim Laden.
• Prioritäten und Zeitpläne. Das Gebäude kann festlegen, dass das Laden in den Bürostoßzeiten eine niedrigere Priorität hat als die Klimaanlage und nachts die höchste.
• Photovoltaik und Energiespeicher. Überschussenergie aus den Panels lässt sich zum Laden lenken, statt sie ins Netz einzuspeisen; das CSMS erhält ein Signal über die verfügbare „grüne“ Leistung.
• Reaktion auf verfügbare Leistung. Wenn im Gebäude in der Spitze Leistung fehlt, wird das Laden gedrosselt, statt andere Systeme abzuschalten — und kehrt zur vollen Leistung zurück, sobald Kapazität frei wird.

In diesen Szenarien arbeitet die API in beide Richtungen: Das Gebäude liest den Ladezustand und steuert die verfügbare Leistung, und Ereignisse aus den Ladevorgängen erreichen das Energiesystem. Wichtig zu betonen: Es ist das CSMS, das die Kommunikation mit den konkreten Ladestationen über OCPP übernimmt, während das Gebäude mit einer einzigen, einheitlichen API-Schicht spricht. Ohne sie würde jedes neue Gerät eine separate Integration bedeuten.

Integration mit Flotte und Partner-App

Das dritte Szenario, neben Parken und Gebäuden, ist die Integration mit einem Flottensystem oder mit einer App, die der Partner seinen Nutzern bereits anbietet. Hier spielt die API die Rolle einer „Lade-Engine“, verborgen unter fremder Marke und fremder Oberfläche.

Ein Flottenbetreiber möchte das Laden dort sehen, wo er Kraftstoff, Wartung und Kosten sieht — also im eigenen Flottensystem und nicht in einem weiteren, separaten Portal. Über die REST API ruft er die Liste der Stationen und Token ab, weist Karten konkreten Fahrern oder Fahrzeugen zu und empfängt über Webhooks jeden beendeten Ladevorgang mit der verbrauchten Energie und der Fahrerkennung. Abrechnung und Energiekostenbericht entstehen automatisch, neben den übrigen Flottenkosten.

Ähnlich funktioniert die Integration mit einer Partner-App. Der Partner baut sein eigenes Nutzererlebnis — Login, Karte, Verlauf — während die Ladeoperationen (Autorisierung, Ladevorgang, Abrechnung) über die EV24® API laufen. Der Endkunde weiß nicht, dass „darunter“ ein CSMS arbeitet; er sieht eine einheitliche App einer Marke. Das ist ein White-Label-Modell auf der Integrationsschicht: Die gesamte Komplexität des Ladens ist programmatisch verfügbar, während Marke und Oberfläche dem Partner gehören.

In all diesen Fällen wiederholt sich dasselbe Muster, das sich durch den ganzen Artikel zieht: die REST API zur Verwaltung von Daten und Konfiguration, Webhooks zur Reaktion auf Ereignisse. Es ändert sich nur das System auf der anderen Seite — Parken, Gebäude, Flotte oder App.

Die häufigsten Fehler bei der Integration mit einer API

Bevor wir zum Start kommen, lohnt es sich, die Fallen zu nennen, die Rollouts am häufigsten verzögern oder sie schon in Produktion kaputtmachen. Jede von ihnen wird erst sichtbar, wenn der Datenverkehr wächst.

• Sich ausschließlich auf Polling verlassen. Eine Integration, die nur auf zyklischem GET-Abrufen von Status beruht, ist langsam und teuer. Wenn Sie auf Ereignisse reagieren, nutzen Sie Webhooks — Polling bleibt für Situationen, in denen Sie wirklich fragen müssen.
• Keine Idempotenz. Die Annahme, jedes Ereignis komme genau einmal an, endet früher oder später in doppelter Abrechnung. Ein Eindeutigkeitsschlüssel (die Ereigniskennung) ist keine Option, sondern Pflicht.
• Einen Webhook als vertrauenswürdige Eingabe behandeln. Der Endpunkt, der Benachrichtigungen empfängt, ist öffentlich. Ohne Prüfung des Authorization-Headers setzen Sie sich gefälschten Anfragen aus.
• Zu weit gefasste Token. Ein einzelnes „Alles-Token“ ist ein Risiko und erschwert die Diagnose. Vergeben Sie Scopes, die auf eine konkrete Integration abgestimmt sind.
• Paginierung ignorieren. Suchen liefern Ergebnisse seitenweise. Eine Integration, die „nur die erste Seite“ abruft, beginnt nach einigen Monaten, Daten zu verlieren.
• Keine Behandlung von Wiederholungen und Limits. Ihr Empfänger wird manchmal nicht verfügbar sein, und die API wendet Ratenlimits an. Planen Sie eine Warteschlange, exponentielle Wiederholungen und die Behandlung von Rate-Limit-Antworten.

Die gute Nachricht ist, dass all diese Fehler bekannt sind und alle einfache, bewährte Lösungen haben. Es genügt, in der Entwurfsphase an sie zu denken und nicht erst nach dem ersten Vorfall.

Sicherheit der Integration — was Sie nicht auslassen dürfen

Die Integration über eine API bedeutet, einen Kanal zu Daten über Infrastruktur, Fahrer und Zahlungen zu öffnen. Einige Regeln, die bei EV24® in das Zugriffsmodell eingebaut sind und an die Sie sich auf der Integratorseite halten sollten:

• Ein Bearer-Token statt Passwörtern. Sie authentifizieren sich an der API mit einem Token im Header Authorization. Das Token lebt auf dem Server Ihrer Integration, nie im Browser-Client.
• Scopes statt Vollzugriff. Jedes Token erhält nur die Berechtigungen, die es wirklich braucht. Eine Abrechnungsintegration braucht kein Recht, RFID-Token zu erstellen.
• Rotation und Widerruf. Das Generieren eines neuen Tokens macht das vorherige sofort ungültig; ein Token lässt sich auch manuell widerrufen. Sobald der API-Zugang deaktiviert wird, funktionieren alle zugehörigen Token nicht mehr.
• Webhook-Prüfung. Der jeder Benachrichtigung beigefügte Authorization-Header ist Ihr Mechanismus, um zu bestätigen, dass die Anfrage wirklich von der Plattform stammt.
• Idempotenz und Logging. Speichern Sie die Kennungen behandelter Ereignisse und protokollieren Sie Aufrufe. Das hilft bei der Diagnose und schützt vor doppelter Abrechnung.

Sicherheit ist hier kein Zusatz — sie ist die Eintrittsvoraussetzung. Eine gut entworfene Integration behandelt das Token wie ein Produktionsgeheimnis und einen Webhook wie eine nicht vertrauenswürdige Eingabe, die geprüft werden muss.

So starten Sie

Der Start einer Integration mit der EV24® API ist ein Prozess, kein einmaliges „Einschalten“. Kurz sieht er so aus:

1. API-Zugang erhalten. Ein Administrator aktiviert den API-Dienst für das Partner- oder Kundenprofil und weist Scopes zu, die dem Umfang der Integration entsprechen.
2. Token generieren. Im Portal, im Bereich der API-Einstellungen, generieren Sie ein Token. Es wird nur einmal angezeigt — speichern Sie es sicher.
3. Webhooks konfigurieren. Geben Sie die Adresse an, an die Benachrichtigungen gehen sollen, setzen Sie den Authorization-Header und wählen Sie die Ereignisse (z. B. Ende des Ladens).
4. Bauen und testen. Führen Sie die ersten REST-Aufrufe aus, empfangen Sie den ersten Webhook, kümmern Sie sich um Idempotenz und Fehlerbehandlung.
5. In Produktion gehen. Schalten Sie die Integration nach den Tests auf Produktionsdaten um und aktivieren Sie das Monitoring.

Der Ausgangspunkt ist die Seite EV24® Partner-API, auf der Sie die Architektur und die Möglichkeiten der Integrationsschicht sehen. Den vollständigen technischen Weg — vom Zugang über die Konfiguration der Berechtigungen bis zu den ersten Aufrufen — finden Sie in der EV24® API-Dokumentation für Integratoren. Die interaktive Spezifikation aller Endpoints ist unter api.ev24.cloud verfügbar.

Zusammenfassung

Eine Ladestation lädt ein Auto. Aber geschäftlicher Wert entsteht erst, wenn das Laden Teil eines größeren Ganzen wird: eines Parkplatzes, der Standzeit und Energie auf einer Rechnung abrechnet; eines Gebäudes, das Leistung klug aufteilt und Energie aus Panels nutzt; einer Flotte und eines Backends, die Ladevorgänge in Echtzeit sehen. Dieser „Klebstoff“ ist eine CSMS-API.

Zwei Säulen — die REST API für Operationen auf Abruf und Webhooks für Echtzeit-Ereignisse — decken praktisch jedes Integrationsszenario ab. Marktstandards (OCPP, OCPI, ISO 15118, AFIR) schaffen Ordnung darunter, und ein gutes CSMS kapselt ihre Komplexität in eine einfache, sichere API. Stationen hinzufügen, SIM-Karten ausgeben, Token verwalten, Kunden onboarden und Ladevorgänge automatisch abrechnen — all das hört auf, Handarbeit zu sein, und wird zu Code.

Wenn Sie bereits die Infrastruktur und ein System haben, das sie verwaltet, ist der nächste Schritt natürlich: Verbinden Sie das Laden mit dem Rest Ihrer Welt. Beginnen Sie mit der Partner-API-Seite und der Dokumentation für Integratoren.