Reference · built on requestConnectorEnergy, EV & distributed resources

OpenADR 3

REST demand-response protocol from the OpenADR Alliance: programs, events, reports, subscriptions, and VENs in one OpenAPI document.

Request accessPricing ↗

About

OpenADR 3 is the OpenADR Alliance's REST successor to the SOAP-based OpenADR 2.0b, which it complements rather than replaces. A utility's or aggregator's business logic writes program, event, and report resources to a VTN; VENs, the systems that control loads, read those resources and write reports back. The whole API is one OpenAPI document, openadr3.yaml, declared under the Apache 2.0 license. A normative Definitions document fixes enumerations such as PRICE, SIMPLE, and USAGE payloads, and a User Guide covers continuous pricing, load shed, targeting, inverter management, and state of charge. Version 3.1.0 adds MQTT notifications beside webhooks and compact price payloads.

Through Fibric your site acts as a VEN: it reads events and prices from the VTN and proposes the load response and the report for your approval.

This is a reference listing. It documents what Fibric would read from OpenADR 3 and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Programs through GET /programs and /programs/{programID}: programName, intervalPeriod, programDescriptions, payloadDescriptors, attributes, and targets
  • Events through GET /events: programID, eventName, priority, targets, reportDescriptors, payloadDescriptors, intervalPeriod, and intervals of payloads
  • Event payload types such as PRICE, SIMPLE, and USAGE, read against the enumerations in the Definitions document
  • Reports through GET /reports: eventID, clientName, reportName, payloadDescriptors, and per-resource interval data
  • VENs and their resources through GET /vens and /resources, each resource being a load a VEN manages
  • Subscription callbacks: the VTN POSTs to your callbackUrl on CREATE, UPDATE, or DELETE of subscribed object types, or publishes on MQTT topics listed under /notifiers in 3.1.0

Proposed actions

  • Target capability: propose a report through POST /reports and updates through PUT /reports/{reportID} (scope write_reports)
  • Target capability: propose a subscription through POST /subscriptions naming objects, operations, and a callbackUrl (scope write_subscriptions)
  • Target capability: propose registering or updating a VEN and its resources through POST /vens and POST /resources (scope write_vens)
  • Target capability: when Fibric runs as business logic for your own VTN, propose creating an event through POST /events (scope write_events)

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Answer a price event with a load plan

    Read the next PRICE intervals from the event and propose which loads to shift or curtail per interval, with the expected kW. You approve; Fibric posts the report.

    With Price Shift

  • Respond to a demand-response dispatch

    When a SIMPLE event arrives on the callbackUrl, propose the shed actions for your building or chargers and the USAGE report the program expects.

    With Event Response, Peak Demand

  • Keep a battery aligned with the program

    Combine PRICE intervals with the state-of-charge reporting conventions from the User Guide to propose charge and discharge windows and the report back.

    With Battery Dispatch

  • Run a local price server for your site

    A gateway VEN to the grid price server can act as VTN to loads and EVSE on site; Fibric proposes the local price intervals it publishes.

    With Tariff Window

Requirements

  • A VTN run by your utility, aggregator, or price server, with client credentials issued for your VEN
  • The VTN's base URL and version path, in the form <baseUrl>/openadr3/3.0.1/programs
  • A reachable HTTPS callbackUrl for subscription webhooks, or an MQTT client for 3.1.0 notifiers
  • The openadr3.yaml, Definitions, and User Guide for your VTN's version, obtained through the Alliance's registration form
Authentication
OAuth 2.0 client credentials returning a JWT bearer token; the VTN's token endpoint sits at /auth/token or is discovered from GET /auth/server, and scopes such as read_targets, read_ven_objects, write_reports, and write_subscriptions bound what a VEN may read and write.

Limits

  • A VEN reads only objects whose targets match its own (read_targets) or whose clientID is its own (read_ven_objects); read_all belongs to business logic
  • The VTN holds no logic; it stores resources that clients manage, so how an event is interpreted follows the Definitions enumerations, not the VTN
  • Only business logic can write programs and events; a VEN writes reports, subscriptions, and its own VEN and resource records
  • 3.0.0, 3.0.1, 3.1.0, and 3.1.1 differ in schema, so a VEN must be checked against the version in the VTN's path

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request OpenADR 3 ↗

Questions and answers

Is OpenADR 3 compatible with OpenADR 2.0b?
No, and it does not replace it. The Alliance calls 3 a functional equivalent of 2.0b with a REST API instead of SOAP and OAuth2 client credentials instead of PKI certificates. Commercial VTNs are expected to implement both after a grace period; closed systems may certify on one.
How does a VEN learn about a new event?
By searching GET /events, or by creating a subscription with objectOperations: the object types, the operations (READ, CREATE, UPDATE, DELETE), and a callbackUrl the VTN POSTs to. OpenADR 3.1.0 adds MQTT notifiers as an alternative, with topic names listed under /notifiers.
Where is the specification?
The OpenAPI file openadr3.yaml, the Definitions, and the User Guide come from openadr.org after a registration form; the Alliance says they are license free but copyright OpenADR Alliance. The YAML itself declares Apache 2.0, and a public mirror carries versions 3.0.0 through 3.1.1.
Ask about OpenADR 3

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with OpenADR 3 through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy