Every charging platform evaluation eventually reaches the engineer who has to make it work with everything else the business already runs - the ERP that owns the chart of accounts, the CRM that owns the customer record, the data warehouse that owns the reporting. That person is rarely in the first demo, and the questions they ask are not the ones the demo answers. This is the post for them: what a CSMS integration surface actually consists of, which mechanism to use for which job, and the specific things to confirm before a contract is signed rather than during implementation.
Three mechanisms, three different jobs
“API-first” usually gets presented as one capability. In practice an integration surface has three distinct parts, and most integration problems come from using the wrong one for the job.
| Mechanism | Direction | Use it for | Wrong job for it |
|---|---|---|---|
| REST API | You call the platform | Reading current state, creating and updating records, issuing commands - provision a charger, assign a tariff, look up a session, start or stop remotely | Learning that something happened. Polling an endpoint every 30 seconds to detect faults is a bug, not an integration. |
| Webhooks | The platform calls you | Reacting to discrete business events in near real time - session ended, payment captured, charger went offline, incident opened | Bulk history. Replaying six months of sessions through a webhook endpoint is slow and fragile. |
| Event streams | You consume a continuous feed | High-volume telemetry and analytics pipelines - feeding a warehouse, building operational dashboards, keeping a replica in sync | Transactional workflows that need an immediate synchronous answer, like authorizing a session. |
A healthy integration uses all three: webhooks to know when something happened, the REST API to fetch the authoritative detail for it, and an event stream or scheduled export to keep analytics and finance systems populated without hammering the transactional API.
The integrations that actually get built
Across charging operations, the same four integrations come up in nearly every deployment, and they have different reliability requirements:
- Finance and ERP. Session and invoice data flowing into the accounting system, usually as a scheduled export or a reconciliation feed rather than per-event calls. Correctness and completeness matter far more than latency - a session that arrives ten minutes late is fine, one that arrives twice is a restatement.
- CRM and customer service. Support agents need to see a customer's sessions, payments and disputes without logging into a second console. This is usually read-heavy REST plus a few webhooks for status changes.
- Data warehouse and BI. The analytics team wants session-level data in whatever they already run their reporting on. An event stream or a bulk export beats an API loop every time, and avoids the common failure of analytics load degrading the operational platform.
- Internal operations tooling. Alerting into the incident channel the operations team already watches, ticket creation in an existing system, custom internal dashboards. Mostly webhooks, with the REST API for enrichment.
Seven questions that decide whether the integration is survivable
1. Are webhooks retried, and for how long?
Your endpoint will be down at some point - a deployment, a certificate expiry, a cloud incident. What happens to the events that fired during that window is the single most important question in this list. A platform that retries with backoff over hours, and lets you replay a time range afterwards, is one you can recover from. A platform that fires once and drops the event leaves you with a permanent, silent gap in your records that nobody notices until a month-end reconciliation doesn't balance.
2. Is delivery at-least-once, and are events idempotent?
Any retrying delivery system will eventually deliver the same event twice. That is normal and expected - what matters is that each event carries a stable unique identifier so your side can recognize a duplicate and discard it. Build every webhook consumer to be idempotent from day one; the alternative is double-charging a customer or double-posting revenue the first time a retry fires.
3. Can events arrive out of order?
Over an unreliable network, a “session ended” event can land before the “session started” event that preceded it. Consumers that assume ordering break in exactly this situation. The practical defense is to treat each event as a pointer rather than a payload: when an event arrives, call the REST API to fetch the current authoritative state of that object instead of reconstructing state from the sequence of events you happen to have received.
4. How are webhook calls authenticated, in both directions?
You authenticate to the platform with an API key or OAuth credential. The platform authenticates to you with a signature on the webhook payload - typically an HMAC over the body using a shared secret, which your endpoint verifies before acting. Without that, your webhook URL is an unauthenticated endpoint on the public internet that anyone who learns it can post fabricated session records to. Confirm signature verification exists, and confirm you can rotate the secret without downtime.
5. What are the rate limits, and what happens at the ceiling?
Rate limits are a sign of a platform that protects itself, not a limitation to negotiate away. What you need to know is the actual number, whether it is per key or per tenant, and whether exceeding it returns a clean rate-limit response with a retry hint or simply starts failing requests. Scoped API keys - a key that can read sessions but not issue remote commands - matter for the same reason: an integration that only needs to read should not hold credentials that can stop a live charging session.
6. How is the API versioned, and what is the deprecation policy?
You are building against this surface for years. Ask how breaking changes are introduced, how long old versions remain supported, and how deprecations are communicated. A vendor that cannot answer this is a vendor whose next release is your next unplanned sprint.
7. Is there a sandbox, and is the documentation real?
A non-production environment where your team can create chargers, simulate sessions and receive test webhooks is the difference between integrating in parallel with deployment and integrating after it. Ask to see the API documentation during evaluation, not after signature - its quality is a reliable proxy for how seriously the integration surface is treated internally.
Why the underlying data model matters more than the endpoints
An integration surface can only be as coherent as the system behind it. When a platform is assembled from a CSMS, a separate billing engine and a separate payment stack, the API surface inherits those seams: the session identifier the charging API returns is not the identifier the billing API expects, timestamps are recorded in different systems with different clocks, and your integration layer quietly becomes the place where three vendors' data models get reconciled. That work is invisible in a demo and permanent in production. One session record from authorization through to settlement is an integration property before it is a marketing claim - the same property that makes revenue reconciliation tractable.
Don't forget the audit trail
Everything an integration does through the API is an administrative action taken by a machine, and it needs the same accountability as one taken by a person. When an automated job assigns a tariff or stops a session, the audit record should show which credential did it, when, and what the result was. This matters most in the incident you have not had yet - the integration that started mass-updating tariffs because of a bad deploy, where the question is what changed, by whom, and in what order. It pairs directly with how operator identity and access are handled for human users.
CarChargeOS exposes a REST API, webhooks and event streams as a first-class part of the platform, with scoped API keys and rate limiting, alongside integrations for payments, ERP and finance, CRM, identity and BI - see the integration and interoperability sections on the platform page, or bring your stack to a technical walkthrough.
Frequently asked questions
Should we use webhooks or poll the API?
Webhooks for anything event-driven, the API for reading authoritative state. Polling is a fallback, not a design - it either wastes most of its calls or adds latency, and at scale it usually does both. The one legitimate use for a scheduled poll is a daily sweep that catches anything a webhook delivery may have missed, which is a reconciliation safety net rather than the primary mechanism.
Do we need to understand OCPP to integrate with a CSMS?
No. OCPP is the protocol between the charger and the platform; your business systems integrate with the platform's own API, which exposes sessions, tariffs, customers and payments as business objects rather than charger messages. Understanding OCPP helps when troubleshooting hardware behavior, but it is not a prerequisite for building an ERP or CRM integration.
Can we build our own driver app or operator dashboard on the API?
Technically that is what an API-first platform allows, but it is worth being deliberate about why. The white-label apps and console already exist and are maintained against OS and store changes; building your own means owning that forever. A custom front end makes sense for a genuinely differentiated experience or an embedded flow inside an existing app your customers already use - not as a way to avoid configuring the one you were given. That trade-off is the same one covered in build vs. buy vs. white-label.