Skip to main content
This pathway is for battery manufacturers (OEMs) who run their own cloud platform and want their users to be able to join the Axle VPP. You send us telemetry, we handle optimisation, market participation and customer relations. We’ll send dispatch instructions to an endpoint you provide for you to execute on your own fleet. The integration has three parts:
  1. Onboarding
  2. Telemetry
  3. Dispatch

​
1. Onboarding

Each battery needs a site_id and asset_id in Axle’s system before you can send telemetry or receive dispatch for it — these are the identifiers used throughout the rest of the integration. There are two ways to get there.
If you already collect address, consent and asset details yourself, call Axle’s onboarding API directly.

Onboard site and asset

Register a site and battery, returns site_id and asset_id.
Example request
{
  "site": {
    "mpan": "1234567890123",
    "postcode": "SW1A 1AA",
    "street_address": "10 Downing Street",
    "gave_boundary_meter_consent_at": "2025-01-01T12:00:00Z"
  },
  "asset": {
    "external_id": "battery-001",
    "type": "battery",
    "properties": {
      "power_kw": 5.0,
      "capacity_kwh": 13.5
    }
  },
  "dispatch_consent": {
    "dispatch_methods": ["vpp_limited_control"]
  }
}
Your backend authenticates as described in Authentication.
For events only mode you should use vpp_limited_control in the dispatch_methods array. If you want to allow full control of the battery, use full_asset_schedule_control instead.

​
2. Telemetry

Send regular readings for each battery so we can optimise it and verify delivery. We rely mainly on two readings:
  • Battery state of charge — battery_state_of_charge_pct (0–100)
  • Grid import/export at the site boundary — boundary_import_kw
Grid power is bidirectional, so the sign tells us the direction: positive = import from the grid, negative = export to the grid. If you can also send inverter power (battery_inverter_import_kw) and solar generation (solar_power_kw), we’ll use them to improve optimisation and determine event earnings. Push readings to the readings endpoint, which lists every accepted label and its sign convention.

Send telemetry

Push battery and boundary readings to Axle.
If pushing readings doesn’t suit your platform, we can also pull readings from custom endpoints you provide — get in touch to discuss your setup.

​
3. Dispatch

During a grid event we send a dispatch instruction to a webhook URL you provide. Each instruction covers a single event and sets a target power for every affected asset over a fixed window. You supply the webhook URL when you set up your integration — get in touch to register it. 
{
  "event_id": "eab8c867-7c4d-4116-a587-02c9d1f13a16",
  "issued_timestamp": "2026-06-29T17:02:37.448917+00:00",
  "start_time": "2026-06-30T20:30:00+00:00",
  "end_time": "2026-06-30T21:30:00+00:00",
  "assets": [
    { "asset_id": "3c361164-5187-4b4b-8e8a-7b3f67c4d5a8", "power_kw": -6.915 },
    { "asset_id": "1a161164-5187-4b4b-8e8a-7b3f67c4d5a8", "power_kw": -4.915 }
  ]
}
power_kw uses the same sign convention as telemetry: positive = charge (import into the battery), negative = discharge (export). Apply the target power to each asset for the window between start_time and end_time.

Dispatch webhook

Full schema for the dispatch instruction we send to your webhook.
If you already have your own dispatch API, we can work with custom dispatch endpoints instead of the webhook above — get in touch to discuss your setup.

​
Important points

  • Customers should be able to override dispatch instructions at any time.
  • The battery should return to its original mode of operation after the dispatch event has finished