The Platform

The DER integration layer your software needs

One API. Every device vendor. No bespoke integrations. Derapi handles the protocols so you can ship the product.

Integration sprawl is burning your engineering capacity

Software developers and product teams building energy management apps, demand-response platforms, and grid-edge automation tools face the same structural problem: every solar inverter brand, EV charger vendor, and smart thermostat manufacturer ships a different API with different authentication schemes, data formats, and rate limits.

A developer who wants their app to control both a SolarEdge inverter and an Enphase micro-inverter must build and maintain two separate integrations — and add a third for Schneider EV chargers. Teams building across the DER stack spend 40-60% of engineering cycles on integration maintenance, not product features.

Average DER software product touches 6-12 hardware vendor APIs. Each integration takes 3-8 weeks of initial development. Integration maintenance consumes an estimated 30-50% of ongoing engineering capacity at energy software companies.

One normalized layer between your code and the hardware

Input

Developer API key + device target

Developer API key, target device category (solar, storage, EV charger, HVAC, or smart appliance), and desired operation (read telemetry, send command, subscribe to events). Derapi resolves the device ID to the hardware vendor on the developer's behalf, handling auth and routing server-side so your application code stays clean and portable across vendors.

Processing

Protocol translation & normalization

Derapi's normalization layer translates each vendor's proprietary protocol (IEEE 2030.5, OpenADR 2.0, OCPP 1.6/2.0, Modbus/TCP, proprietary REST/MQTT) into a single unified JSON schema. Authentication is handled server-side against each vendor's credentials vault, and the protocol translation runs in Derapi's infrastructure, not yours.

Output

Normalized JSON response

A single REST or WebSocket response in Derapi's normalized schema — device status, telemetry readings, or command acknowledgement — regardless of the underlying hardware manufacturer. Webhooks and event streams follow the same normalized schema, so your application never needs to branch on vendor type. Update, upgrade, or swap device vendors without changing any application code.

Five capabilities in the Derapi platform

Each feature targets a specific part of the integration problem DER software teams face.

Unified device schema with normalized JSON fields for DER hardware

Unified Device Schema

Every DER device type returns the same normalized JSON structure

Derapi defines an open device taxonomy with standardized fields for each DER category. Developers write against one schema that works across SolarEdge, Enphase, Tesla Powerwall, and 40+ additional vendors. When a vendor updates their API, Derapi updates the adapter — the developer's code never changes.

Multi-protocol translation handling IEEE 2030.5 and OCPP standards

Multi-Protocol Translation

IEEE 2030.5, OpenADR 2.0, OCPP 1.6/2.0, Modbus, and proprietary REST — all handled server-side

Derapi's protocol adapters cover IEEE 2030.5 for utility-grade solar and storage, OpenADR 2.0a/b for demand response signals, OCPP 1.6 and 2.0 for EV charging station management, Modbus/TCP for industrial inverters and commercial HVAC, and direct REST/MQTT bridges for cloud-connected consumer devices.

Encrypted credential vault for secure DER device vendor authentication

Credential Vault

Device-vendor OAuth tokens and API keys stored encrypted — your app never holds third-party credentials

Vendor credentials are stored in Derapi's encrypted credential vault using AES-256 at rest and TLS 1.3 in transit. The developer's application passes only a Derapi device ID in API calls. Vault entries rotate automatically when vendor tokens expire, and audit logs record every credential access.

Event subscription engine with webhook delivery for DER device state changes

Event Subscription Engine

Subscribe to device state changes and grid signals with webhooks or WebSocket streams — no polling required

Derapi's event engine normalizes device events (inverter curtailment, battery charge completion, EV charge session start/stop, thermostat setpoint override) into a uniform event schema. Guaranteed delivery with a 72-hour retry window. Fan-out to multiple subscriber endpoints included.

Derapi API sandbox with simulated DER device fleet for software testing

Sandbox Environment

Full API sandbox with simulated DER device fleets — test demand-response scenarios without hardware

The sandbox mirrors the production API surface with simulated devices spanning solar arrays, residential storage, EV charging stations, and smart thermostats. Inject synthetic telemetry, trigger simulated grid events, and test command sequences. Fully isolated from production device networks. State maintained for 30 days.

Supported vendor integrations

SolarEdge Monitoring API Enphase Enlighten API Tesla Fleet Energy API ChargePoint CPMS / OCPP 2.0 EcoFactor HVAC control API OpenADR 2.0 Virtual Top Node Swell Energy demand response platform

Built for DER software teams

Derapi is designed for engineering teams building distributed energy resource software: demand response platforms, virtual power plant operators, energy management system (EMS) vendors, grid-edge automation startups, and EV fleet charging software developers. If your product interacts with physical DER hardware — solar inverters, battery systems, EV chargers, HVAC units, or smart appliances — you are the customer Derapi was built for.

Teams that benefit most are those integrating with 3 or more hardware vendors, building features that depend on real-time telemetry, or maintaining existing integrations that consume significant engineering overhead. Derapi works equally well for seed-stage startups standardizing on a clean architecture from day one, and for Series B companies looking to offload integration maintenance and redirect capacity to product development.

Get a Derapi API key today

Request access, explore the sandbox, and have normalized device telemetry running in your application within the hour.