Energy Data API: Connect Solar, Battery, EV & Meter Data in One Integration

The integration problem costs more than you think

Every energy hardware brand has its own API. SolarEdge uses a REST API with OAuth. Victron Energy has a MQTT-based protocol. OCPP chargers speak WebSocket with a specific message schema. P1 smart meters use a serial telegram format. Tesla vehicles have a proprietary API with rate limits and authentication requirements that change with each software update.

For a developer building an energy management system, a VPP, or a monitoring dashboard, this means months of integration work before the first line of business logic can be written. Each connector has to handle authentication, connection management, error handling, unit conversion, and data validation independently. And each time a hardware vendor releases a firmware update or changes their API, your connector breaks.

The engineering cost of maintaining a library of 20 device integrations is not 20x the cost of maintaining one. It is exponentially higher, because integrations interact: a shared data pipeline that serves all devices must handle the lowest common denominator, and a change in one integration can cause regressions across others. Teams that build in-house integration libraries consistently underestimate this ongoing maintenance burden.

A unified energy data API solves this by moving the integration complexity off your team's plate entirely. You integrate once; every device brand the platform supports is immediately available to your application.

What is an energy data API?

An energy data API is a single REST interface that aggregates, normalizes, and delivers data from multiple energy hardware types. Instead of your application speaking OCPP to chargers, SunSpec to inverters, and a proprietary protocol to batteries, it speaks one language: a well-documented JSON API with consistent endpoints, standard units, and predictable response schemas.

The key word is normalized. Raw device data is full of inconsistencies: one inverter reports power in watts, another in kilowatts. One charger timestamps readings in local time without timezone, another uses Unix milliseconds. One battery management system reports state of charge as a decimal (0.85), another as a percentage (85). A good energy data API resolves all of these inconsistencies before data reaches your application.

Normalization also covers the object model. An energy data API should present a consistent hierarchy — projects contain buildings, buildings contain devices, devices expose timeseries — regardless of what physical protocol the underlying hardware uses.

How EDX's API works

The EDX platform exposes energy hardware data through a RESTful API organized around a four-level hierarchy.

Core endpoints

• GET /projects — List all projects associated with your API key. A project is the top-level organizational unit, typically corresponding to a client, site portfolio, or deployment.
• GET /projects/{id}/buildings — List buildings or sites within a project. Each building has metadata: address, grid connection point, installed capacity.
• GET /buildings/{id}/devices — List all connected energy devices in a building: inverters, batteries, chargers, meters, heat pumps. Each device has a type, brand, model, and current status.
• GET /devices/{id}/timeseries — Query historical timeseries data for a specific device. Supports time range parameters, resolution (1-minute, 15-minute, hourly), and field selection. Returns JSON arrays with ISO 8601 timestamps and values in standard units.

Authentication

All API calls are authenticated with API keys passed in the Authorization header. Keys are scoped at the project level and can be restricted to read-only access. This makes it safe to issue keys to third-party dashboards or analytics tools without granting write access or access to other projects. Key rotation and revocation are self-service through the EDX platform.

Real-time streaming

For applications that need low-latency data — dashboards, EMS dispatch systems, VPP optimization engines — EDX provides WebSocket endpoints. After authenticating, you subscribe to a building or device stream and receive push updates as new telemetry arrives from the hardware. This eliminates the polling overhead and reduces data latency to near-real-time.

API design principles

A good energy data API is not just a thin wrapper around device protocols. It makes deliberate choices that reduce integration friction and long-term maintenance cost.

• RESTful design: resources are nouns (devices, timeseries), operations are HTTP verbs. Predictable URL patterns mean less time reading documentation.
• OpenAPI specification: the full API is documented in an OpenAPI 3.x spec, enabling automatic client generation in any language. No more reverse-engineering undocumented behavior.
• Consistent JSON responses: every endpoint returns the same envelope structure — data, meta, and errors — so your error handling code works the same way across all endpoints.
• Standard units: power in kW, energy in kWh, temperature in degrees Celsius, current in amperes, voltage in volts. No implicit unit assumptions anywhere in the API.
• Versioned endpoints: breaking changes are never made to a published API version. New versions are introduced with a deprecation timeline, giving you time to migrate.

Real-time vs batch: when to use each

Not every application needs real-time data. Choosing the right access pattern reduces cost and complexity.

Use WebSocket streaming when your application needs to react to data as it arrives: live dashboards, EMS dispatch, VPP optimization, or alerting systems. Streaming keeps a persistent connection and pushes updates at the device's reporting interval — typically every 1 to 15 seconds.

Use REST historical queries for everything else: billing calculations, reporting, model training, or backfilling a data warehouse. REST queries are stateless, cacheable, and easier to debug. They support flexible time ranges and resolution parameters, so you can pull exactly the granularity you need without receiving more data than necessary.

A common pattern is to use REST queries for initial data loads and historical analysis, then switch to WebSocket streaming once your application is processing live data. The same API key and authentication flow works for both.

Getting started: five steps to your first integration

1. Get an API key: request access through the EDX contact page. You'll receive a project-scoped API key and a reference to the OpenAPI specification.
2. Explore the hierarchy: call GET /projects to see your available projects, then drill down to buildings and devices. Inspect the device list to confirm the asset types and brands connected to your project.
3. Query device timeseries: pick a device and call GET /devices/{id}/timeseries with a time range. Verify the response format, units, and timestamp behavior against your expectations.
4. Stream live data: open a WebSocket connection and subscribe to a building or device. Observe the push update frequency and confirm it matches your application's needs.
5. Build your product: with a reliable, normalized data feed in place, you can focus entirely on the logic that differentiates your product — not on device protocol handling.

For software teams building on top of energy data, EDX is designed to be the data layer so you can focus on your application layer. Learn more about the software builders use case or read about how EDX fits into a VPP architecture.

Frequently asked questions

What authentication method does the EDX API use?

The EDX API uses API key authentication. Keys are scoped to specific projects and can be restricted to read-only access. Each key is associated with a specific data consumer, enabling fine-grained access control and audit logging of who accessed which data.

What data formats does the energy data API return?

All EDX API responses are JSON. Energy values use standard SI units: power in kW, energy in kWh, temperature in degrees Celsius, and current in amperes. Timestamps are ISO 8601 with UTC timezone. This consistency eliminates unit conversion bugs that commonly appear when integrating data from multiple device brands directly.

How does real-time streaming work?

EDX provides WebSocket endpoints for real-time data streaming. After authentication, you subscribe to a device or building stream and receive push updates as new telemetry arrives. This is more efficient than polling for applications that need sub-minute latency, such as dashboards, EMS dispatch, or VPP optimization engines.

One integration. Any device brand. Normalized data from day one. That is what an energy data API should deliver.

Ready to stop building connectors? See the EDX platform or book intro to talk through your hardware portfolio.