A user owns a site — a physical property — and that site holds the assets (EV chargers, batteries and heat pumps) Axle can monitor and control. Enrolment, consents and payments all belong to the user via their site, so the operations below act on a site, not on individual users. Over their lifetime, sites move between different states depending on whether they exist on the platform and whether they’re enrolled in a proposition — the agreement that lets Axle participate in a market on the user’s behalf. This page describes those states, the API calls that move between them, and how to handle the everyday changes your users will throw at you: adding an asset, swapping a charger, opting out, or moving house.Documentation Index
Fetch the complete documentation index at: https://docs.axle.energy/llms.txt
Use this file to discover all available pages before exploring further.
Managing sites
| State | Exists on platform? | Enrolled in a proposition? | What it means |
|---|---|---|---|
| Unseen / Deleted | No | No | We don’t know about this site, or we’ve removed it. |
| Inactive | Yes | No | The site and its assets exist — you can look them up, update them, and add or remove assets — but they’re not participating in any proposition. |
| Active | Yes | Yes | The site is enrolled and participating. Schedules, dispatches and rewards are all live. |
Site transitions
Each arrow in the diagram is a single API call.| Endpoint | From → To | Use it when |
|---|---|---|
onboard | Unseen → Active | Preferred — the common path for opting-in. Creates the site and assets and enrols them in one call; reach for it by default. |
initialise | Unseen → Inactive | You want to create the site and assets, but do work before committing. |
enrol | Inactive → Active | The commitment point after initialise — this begins participation in a proposition (scheduling, readings, rewards). |
unenrol | Active → Inactive | Preferred — the common path for opting-out. The user is leaving a proposition but staying on the platform. Easily reversible; payments still accessible. |
offboard | Active → Deleted | The user is leaving entirely. Removes the site and its assets. |
Opting in
Most integrations sign a user up with a singleonboard call, which creates the site and its assets and enrols them in one go.
Split it into initialise + enrol only when you need to do work between creating the site and committing it to a proposition — see Advanced Onboarding for details.
Opting out
A user can stop participating in two ways:unenrol and offboard
In most cases, unenrol is the best way for a user to opt-out, and should be the default for a user-initiated opt-out action. It cleanly stops participation — no more readings, scheduling, or rewards — while leaving the site and its assets in place. Because the user remains on the platform, their payments remain accessible, and you can switch participation back on at any time by re-enrolling the same site.
This is especially relevant when a site is participating in another proposition, like the Capacity Market. Unenrol only stops the proposition you name, so unenrolling Flex Lite leaves their Capacity Market participation untouched.
| Unenrol | Offboard | |
|---|---|---|
| Participation (scheduling, readings, rewards) | Stopped | Stopped |
| Other propositions (CM, etc.) | Unchanged | Stopped |
| Site & assets | Accessible | Removed |
| Payments | Accessible | Cut off |
Managing assets within a site
The lifecycle above acts on the site. But a site can gain or lose assets without changing state — a user might add a battery to a property that already has a charger, or replace a charger that’s been swapped out. These are asset-level operations that leave the site enrolled and untouched:Create asset
Add an asset to an existing site
Delete asset
Remove a single asset from a site
Common scenarios
A user adds an asset (e.g. they install a second charger)
A user adds an asset (e.g. they install a second charger)
Use Create asset against the existing
site_id. The site stays enrolled, and the new asset starts participating once it’s eligible. There’s no need to re-onboard or re-enrol the site.Save the returned asset_id — you’ll need it to send events for that asset.A user removes an asset (e.g. they sell their EV)
A user removes an asset (e.g. they sell their EV)
Use Delete asset with the
asset_id. The rest of the site is unaffected.If the user is removing their only asset and won’t be participating any more, consider whether you want to unenrol the site instead — or offboard it if they’re leaving for good. See opting out for which to reach for.A user replaces or upgrades an asset (e.g. they swap out their charger)
A user replaces or upgrades an asset (e.g. they swap out their charger)
A user opts out
A user opts out
See Opting out for the full guidance on choosing between unenrolling and offboarding a site, and on handling any outstanding payment balance.
A user wants to come back after opting out
A user wants to come back after opting out
A user moves house
A user moves house
A site is tied to a physical property (and its MPAN), so a move is really two separate users at two properties:
- Offboard the old site. The user no longer controls the assets at their previous address, so offboard it.
- Onboard them at the new property as a fresh site, if they’re taking eligible assets with them or the new home already has them.
Someone moves into a property that was previously enrolled
Someone moves into a property that was previously enrolled
The previous occupant should have been offboarded when they left. The new occupant is a different user, so onboard them as a new site against the same MPAN. Don’t re-use the old site — its consents and payments belong to the previous user, and it stays linked to their account.
Where next?
Flex Lite
Insert pauses into existing charging schedules with a light integration
Smart Charging
Hand full charge-plan control to Axle for maximum flexibility revenue
Advanced Onboarding
Split onboarding into initialise + enrol
API Reference
Full request and response specs for every endpoint