- Onboarding & offboarding: registering the site & asset with Axle, and assigning responsibility for charging
- Charging: sending information about the user’s requirements, plug-in and plug-out events, and receiving charging schedules
- Reporting: sending charging session data
View end-to-end flow for smart charging integration
View end-to-end flow for smart charging integration
1. Onboarding & offboarding
Onboard your site and asset
Register the site and EV charger with Axle and enrol them in thefull_asset_schedule_control proposition — the proposition that lets Axle issue full charging schedules to the asset.
Onboard
Create or update a site and its assets, and enrol them in a proposition.
site.email in the onboard payload. A user email is required to process payments through our provider, Stripe. We also send payment-failure notifications and, if enabled, two-factor authentication codes to this address.
Stop participation
There are two ways to stop a user’s participation. Pick based on what’s actually happening:- Unenrol when the user is opting out of Smart Charging specifically — for example, they turn it off in your app or withdraw consent. The site and assets stay on the platform, any other propositions they’re enrolled in (such as Capacity Market) are unaffected, and they can re-enrol later and still access their payments.
- Offboard when the user is leaving entirely — for example, they’ve moved house, or your support team is removing them. This unenrols from every proposition and deletes the site and its assets per data-retention policies. Payments can no longer be accessed afterwards, so prompt the user to withdraw any outstanding balance first.
Unenrol site
Stop this proposition without deleting the site
Offboard site and assets
Remove the site and its assets
2. Charging
To deliver Smart Charging, we need to know the customer’s tariff, intent and plugin/plugout events. We also need you to be able to receive and implement updated charging schedules. We will issue charging schedules when a user plugs in; when a user updates their tariff or intent; or in response to wider market changes.Tariff
We need to know the user’s tariff in order to optimise charging. You should send an update whenever the tariff changes.Send tariff
Send or update a user’s tariff
Collect and communicate intent
We need to know how much energy is required and when the vehicle needs to be ready. Together, we refer to this as the user’s intent.Energy requirements
We need to know how much energy is required in kWh. There are different ways to arrive at this number.| User provides | Notes |
|---|---|
| kWh to add | User describes requirement in kWh |
| Hours to add | Requires approximation of charge power |
| Nothing | Can be approximated or fixed to e.g. 4 hours charging |
Ready-by time
We need to know the deadline to deliver the energy requirements. You can collect ready-by with a standard time picker. For more customisation, you can collect separate ready-by times for different:- days of the week
- vehicles
Sending intent
Our recommendation is to communicate intent whenever it changes, to ensure Axle scheduling always uses the most recent values.Send intent
Send or update a user’s charging intent
Plugin and plugout events
Notify Axle when the vehicle plugs in and unplugs.Controlling via car? Axle relies on a “car is home” signal from the car manufacturer before acting on plug-in events — no location or GPS data is needed, only a boolean indicating the vehicle is at home. In practice, this often means your API only forwards plug-in events to Axle when the car is at home; Axle treats every plug-in it receives as a home charge.
Plug-in event
Notify Axle when a vehicle plugs in.
Plug-out event
Notify Axle when a vehicle unplugs.
Receiving charging schedules
Axle will issue new schedules:- When the user first plugs in
- When the user is already plugged in and one of the following events happens:
- The user’s tariff is updated
- The user’s intent changes
- Axle reoptimises in response to changes in the wider market
async.
To issue schedules, we need you to make an endpoint available to which we can send API requests.
If you already have an existing API that you think will support smart charging,
we can discuss integrating with that directly. However, our recommendation is
to integrate with our OCPP style request format.
- Specification of charge energy in an industry-standard format
- Stacking of schedules allows fallbacks in case devices go offline. For instance, our schedules should be overlaid upon a “default” schedule which always charges consumers during off-peak times
Charging scenarios
Worked examples showing how different intents and tariffs affect the schedules Axle sends
Special case: Communicating parameters upon enrolment
At the time of enrolment, we expect to immediately receive the information we need to schedule a charge. This means you should:- Call either plug-in or plug-out to communicate the plug state of the charger at the moment of enrolment
- Set the user’s tariff
- Set the intent — this can be a default value or the user’s first input
3. Reporting
Send readings
Send half-hourly consumption readings so Axle can verify delivery and calculate rewards.Send readings
Notify Axle of asset consumption readings
Next Steps
Earning from EV Charging
Learn how to manage user payments and withdrawals

