A virtual power plant (VPP) is not a new concept. Utilities have been aggregating demand response and generation assets for decades. What's different now is the scale of behind-the-meter DERs available for aggregation — residential and commercial solar, battery storage, smart thermostats, EV chargers — and the expectation from grid operators that these assets can be dispatched with the responsiveness of a peaker plant, not the 10-minute notice of a traditional demand response program.
The gap between that expectation and current reality is largely a data infrastructure problem. Each DER is owned by a different customer, connected to the grid through a different inverter or device with its own communication protocol, and metered by a utility that may or may not support near-real-time data access. Aggregating them into a dispatchable resource requires solving data normalization, latency, and control — simultaneously, at scale.
This article examines the data infrastructure requirements for commercial-scale VPP operation and how an API layer designed around DER data can address the normalization and visibility problem, even if the control layer requires additional work.
What VPP Operators Actually Need From Data Infrastructure
A VPP operator's core workflow involves three recurring data problems:
Portfolio inventory and status. At any moment, the operator needs to know which assets in their enrolled portfolio are online, their current output or state of charge, and any constraints on dispatch (vehicle departure time, homeowner opt-out, inverter communication loss). This requires near-real-time telemetry from each asset — which comes from the device, not from the utility.
Grid signal reception. When a grid operator (ISO or utility) issues a dispatch signal — increase generation by 50 MW in the next 5 minutes — the VPP operator needs to receive that signal, translate it into device-level instructions, and confirm compliance. This requires integration with the ISO's demand response or ancillary services market signaling system, which in CAISO means the Demand Response Auction Mechanism (DRAM) and associated SCADA links.
Settlement and performance tracking. After a dispatch event, the operator needs to calculate delivered performance against committed capacity, report to the ISO, and settle with enrolled customers. This requires post-event metering data — which, again, comes from the utility, often with a 24–72 hour delay.
Derapi's aggregation endpoints address the second data layer: portfolio-level visibility into the grid context for enrolled assets, including capacity commitment tracking, interconnect status for each asset, and the relevant grid signal parameters for the utility territory.
The Aggregation Endpoint Architecture
Derapi's VPP-facing endpoints operate on the concept of an asset portfolio — a named collection of DER assets that your application manages as a group:
POST /v1/vpp/portfolios
{
"name": "Portland Residential Battery Fleet Q1",
"assets": [
{ "asset_type": "bess", "zip": "97214", "capacity_kwh": 13.5, "max_discharge_kw": 7.6 },
{ "asset_type": "bess", "zip": "97202", "capacity_kwh": 27.0, "max_discharge_kw": 11.4 },
...
]
}Once a portfolio is created, the aggregation endpoint returns the combined grid context for that portfolio: total enrolled capacity by technology type, aggregate interconnect status, the utility demand response programs available in the territories where assets are located, and estimated dispatchable capacity given the portfolio's current SoC and constraint envelope.
GET /v1/vpp/portfolios/{portfolio_id}/statusThe response includes a dispatchable_capacity_kw estimate (the lower-bound dispatchable capacity given conservative SoC assumptions), a dr_programs array listing the demand response programs each asset subset is eligible for, and a interconnect_constraints object flagging any assets whose interconnect agreement limits export to the grid.
IEEE 2030.5 and the Protocol Reality
At the device communication level, VPP aggregation is complicated by protocol fragmentation. Residential inverters and batteries communicate over SunSpec Modbus, IEEE 2030.5 (SEP 2.0), OpenADR 2.0b, or proprietary cloud APIs depending on manufacturer and vintage. CAISO's Rule 21 tariff requires IEEE 2030.5 compliance for smart inverters in interconnection agreements executed after 2017, which has driven adoption among California-connected DERs. Outside California, the protocol landscape is less standardized.
Derapi's aggregation layer does not provide device-level telemetry or control. We're not saying API-layer infrastructure replaces the DERMS (distributed energy resource management system) that handles device communication. Those are separate layers: a DERMS handles the sub-second to second-level device communication and control; Derapi handles the grid-context data — interconnect terms, available DR programs, capacity commitment tracking — that the DERMS operator needs to make dispatch decisions.
The practical integration pattern is: your DERMS polls Derapi for grid signals and portfolio-level grid context; your DERMS dispatches to devices via their native protocol; your application reads post-dispatch status from Derapi's event log endpoint. The API layer is the data bus, not the control plane.
Scaling From Pilot to Commercial: The Data Bottlenecks
Most VPP pilots operate with 50–500 enrolled customers and achieve the necessary data quality through direct relationships with a small number of device manufacturers and utilities. Scaling to 5,000–50,000 enrolled customers introduces data problems that manual or semi-manual approaches can't solve.
Consider the enrollment qualification workflow: for each candidate asset, you need to verify that the asset's interconnect agreement permits export (not all residential solar interconnection agreements allow battery dispatch to the grid), that the utility territory has an active demand response program the asset can enroll in, and that the device's rated discharge capacity meets the minimum threshold for the program. At 500 customers, a manual check takes hours. At 50,000 customers, it requires an automated qualification pipeline.
Derapi's enrollment qualification endpoint automates the first two checks. Given a ZIP code, asset type, and system capacity, it returns the interconnect export eligibility flag, the available DR programs and their minimum capacity thresholds, and the program enrollment windows (some programs have open enrollment periods; others are continuously open). Your enrollment application calls this endpoint for each candidate customer before sending them through the enrollment flow, surfacing ineligible assets before the user completes the form.
FERC Order 2222 and Aggregation at the Wholesale Level
FERC Order 2222, finalized in 2020 and progressively implemented by ISOs through 2023–2025, requires ISOs to allow DER aggregations to participate in wholesale electricity markets. The practical effect is that a VPP operator can now offer capacity, energy, and ancillary services (including frequency regulation) into CAISO, PJM, MISO, and other wholesale markets — provided the aggregation meets minimum size thresholds and telemetry requirements.
The minimum size thresholds vary by ISO and market product. CAISO's Non-Generator Resource (NGR) designation, which covers battery aggregations, requires a minimum of 0.5 MW registered capacity and 15-minute metering. PJM's capacity market participation for DER aggregations requires a minimum of 100 kW per resource and compliance with PJM Manual 18 telemetry specifications.
Derapi's portfolio status endpoint includes a wholesale_market_eligibility object that checks these thresholds for your portfolio's current enrolled capacity, by ISO. If a portfolio falls below the threshold for a given market product, the response indicates the gap and the incremental enrollment needed to qualify. This is relevant for VPP operators actively growing their portfolio and trying to time their entry into wholesale markets.
What the Next 24 Months Look Like for VPP Infrastructure
The utility industry is moving toward standardized DER enrollment and dispatch interfaces, but the timeline is measured in years, not quarters. California's CPUC DER Action Plan and DOE's VPP Liftoff Report both point to IEEE 2030.5 and OpenADR 2.0b as the intended convergence standards for device communication, with utility customer data access improving through Green Button Connect — but Green Button Connect adoption is still uneven across utilities.
The data infrastructure gap — between what a VPP operator needs (near-real-time, structured, normalized portfolio data) and what utilities currently provide (monthly billing data, quarterly interconnect queue updates, inconsistent portal access) — is not closing quickly. Building on an API abstraction layer that normalizes these sources is a practical response to a fragmented market, not a stopgap until utilities build better systems. The fragmentation is structural; the normalization layer is the appropriate engineering response for any team trying to ship production VPP software in 2025 or 2026.