Building a Low-Latency Edge Aggregator with Energy API and WebRTC for Distributed Energy Resource Control

Distributed energy resources (DERs) like batteries, rooftop PV, EV chargers, and flexible HVAC loads want two things at once: market-aware dispatch and millisecond-class actuation on the edge. If your controller cannot see price curves, carbon intensity, and supply constraints in time, it leaves value on the table. If it cannot push control setpoints quickly and reliably to sites, it violates SLAs and misses grid events. The traditional answer—poll every data portal separately and stitch formats together in a central service—adds seconds of latency, brittle ETL, and an endless maintenance backlog.

This post walks through how to design and implement a low-latency edge aggregator for DER control that blends two proven ingredients: normalized wholesale and grid intelligence from Energy API, and WebRTC data channels for sub-second command propagation. The goal is practical: assemble a production-ready pipeline that pulls consistent energy and carbon signals (electricity, gas, oil, coal, carbon allowances, and grid carbon intensity) and drives geographically distributed assets with tight feedback loops—all without spending weeks untangling OMIE, ENTSO-E, EIA/FRED, or ESIOS feeds.

You will learn how to: query multiple commodities in a single API call; stream day-ahead intraday curves to edge controllers; expose deterministic auction forecasts to schedule batteries before publication day; embed emissions intensity limits into real-time setpoint logic; and use WebRTC to orchestrate low-latency delivery and acknowledgments. We will cover core endpoints, implementation details in cURL/JavaScript/Python, error handling, and design patterns that keep the system fast, robust, and auditable.

Why Energy API

Market and grid data is only useful if it is timely, correct, and consistent. The most common failure mode we see in DER platforms is not the control logic—it’s fragile data plumbing that can’t keep up with provider changes or timezone edge cases. Energy API eliminates those bottlenecks by normalizing heterogeneous feeds into one consistent JSON surface.

• One surface, many sources: Replace five to ten provider-specific integrations with a single REST interface. You no longer reconcile symbol naming, publication schedules, daylight savings transitions, or unit conversions across OMIE, ENTSO-E, EIA, FRED, and ESIOS. Your code becomes shorter and far more maintainable.
• Same schema across commodities: Electricity, gas, oil, coal, ETS carbon, and grid carbon intensity present uniform shapes. That means shared parsers, common caching layers, and straightforward feature reuse—ship alerts, dashboards, and cost calculators in hours rather than weeks.
• Intraday electricity curves when available: Where sources publish 15-minute or hourly curves, you get the whole day’s shape through a stable endpoint rather than parsing CSVs or PDFs. That’s critical for battery charging windows, smart EV charging, and demand response.
• Operational clarity out of the box: Health endpoints and deterministic day-ahead lookups cut ambiguity. If a provider pauses publication, you’ll see it immediately; if an auction publishes tomorrow’s price, you can retrieve it without scraping or hand-built calendars.

Quick Start

All requests use a common base URL and return JSON. Below, we’ll fetch the most recent values for three symbols—Brent crude, TTF gas, and EU ETS allowances—in a single call. This pattern lets you wire a single polling loop to update many downstream consumers.

Base URL:

https://energy-api.com/api/v1

First request:

curl -G https://energy-api.com/api/v1/latest \
--data-urlencode "symbols=BRENT_CRUDE,TTF_GAS,EUA_CO2" \
--data-urlencode "api_key=YOUR_API_KEY"

Example response:

{
"success": true,
"date": "2026-06-11",
"base": "MIXED",
"rates": {
"BRENT_CRUDE": 74.82,
"TTF_GAS": 38.15,
"EUA_CO2": 67.40
},
"dates": {
"BRENT_CRUDE": "2026-06-11",
"TTF_GAS": "2026-06-11",
"EUA_CO2": "2026-06-11"
},
"currencies": {
"BRENT_CRUDE": "USD",
"TTF_GAS": "EUR",
"EUA_CO2": "EUR"
}
}

Key fields:

• success: Always check this boolean before parsing body content.
• date: The primary as-of date for the batch response. Some symbols can have slightly different dates if a provider hasn’t published yet; see dates per symbol.
• rates: Keyed by symbol, numeric quote in the symbol’s native currency.
• dates: Per-symbol quote date. Useful when combining across mixed publication calendars.
• currencies: Per-symbol currency code. Use this to gate conversions or multi-currency UI labels.

Architecture Blueprint: Edge Aggregator + Energy API + WebRTC

To achieve low-latency dispatch, separate the concerns of market intelligence and actuation:

• Core aggregator (cloud or regional): Polls Energy API for electricity intraday curves, day-ahead auction results, live fuel benchmarks, and grid carbon intensity. Normalizes to your canonical internal schema and caches a short rolling window (e.g., 48 hours).
• Edge controllers (site-level): Maintain a persistent WebRTC data channel with the aggregator for state updates and control setpoints. Calculate local safety limits, apply asset constraints, and execute commands. Send telemetry and acknowledgments back over the same channel.
• Signaling service: Uses standard HTTPS signaling to exchange SDP offers/answers and ICE candidates, and brokers STUN/TURN configuration to traverse NATs. Once the P2P data channel is up, it carries control and state with low overhead.

Typical flow:

1. Aggregator pulls /electricity/hourly and /forecast for target symbols (e.g., OMIE_ES_DA, EPEX_DE_DA). Also pulls /emissions/latest or /carbon-intensity to enforce carbon-aware setpoints.
2. Aggregator derives dispatch curves (charge/discharge windows, EV charging ramps) and streams compact JSON frames over WebRTC to edges: {symbol, timeslot, setpoint, reason_code}.
3. Edges respond with ack and telemetry. If a channel degrades, fallback to short-polling /latest-derived setpoints via HTTPS until the WebRTC path recovers.

Latency budget:

• Data fetch: Most endpoints are fast; parallelize /latest for multi-commodity and cache. Refresh electricity intraday curves on schedule aligned with the source (e.g., day-ahead publish).
• Serialization: Ship only deltas and near-horizon slices to edges (e.g., next 2 hours at 5-minute granularity).
• Networking: Prefer regional aggregator deployments close to edges and TURN relays as a last resort. WebRTC data channels over UDP minimize overhead.

Core Endpoints for Low-Latency DER Control

Below are the high-leverage endpoints to wire first. For each, we include path, key parameters, a sample request, a realistic JSON reply, and how to use the fields.

1) /electricity/hourly — Intraday curves for dispatch planning

Path: GET /electricity/hourly

Purpose: Retrieve the full hourly (or 15-minute) curve for a symbol on a given date. Use this to compute charge windows, flexible load shifts, and baseline costs.

Key params:

• symbol: Electricity symbol (e.g., OMIE_ES_DA, EPEX_DE_DA, AEMO_NSW1)
• date: YYYY-MM-DD (publish date for the curve)

Example request:

curl -G https://energy-api.com/api/v1/electricity/hourly \
--data-urlencode "symbol=OMIE_ES_DA" \
--data-urlencode "date=2026-06-12" \
--data-urlencode "api_key=YOUR_API_KEY"

Example response:

{
"success": true,
"symbol": "OMIE_ES_DA",
"date": "2026-06-12",
"timezone": "Europe/Madrid",
"frequency": "hourly",
"currency": "EUR",
"curve": [
{"time": "2026-06-12T00:00:00+02:00", "price": 68.32},
{"time": "2026-06-12T01:00:00+02:00", "price": 65.10},
{"time": "2026-06-12T02:00:00+02:00", "price": 61.88},
{"time": "2026-06-12T03:00:00+02:00", "price": 60.41}
/* ... 24 entries total ... */
],
"source": "OMIE"
}

How to use it:

• curve: Ordered list of timestamped prices; align to site timezone or stay in source timezone for reproducibility. For price-based dispatch, generate setpoints by ranking slots by price and applying asset constraints.
• timezone and frequency: Critical to slot alignment when switching between 15-minute and hourly markets or around DST boundaries.
• source: Keep this in logs for audits of schedule origin.

2) /forecast — Day-ahead auction results for next publish

Path: GET /forecast

Purpose: Deterministic lookup of the next published day-ahead price for auction-sourced electricity symbols. This is not a predictive model; it returns already-published results for the next delivery day as soon as they are available from the source.

Key params:

• symbol: Auction symbol (e.g., OMIE_ES_DA, EPEX_DE_DA)

Example request:

curl -G https://energy-api.com/api/v1/forecast \
--data-urlencode "symbol=EPEX_DE_DA" \
--data-urlencode "api_key=YOUR_API_KEY"

Example response:

{
"success": true,
"symbol": "EPEX_DE_DA",
"publish_date": "2026-06-11",
"delivery_date": "2026-06-12",
"timezone": "Europe/Berlin",
"frequency": "hourly",
"currency": "EUR",
"curve": [
{"time": "2026-06-12T00:00:00+02:00", "price": 71.22},
{"time": "2026-06-12T01:00:00+02:00", "price": 69.10}
/* ... */
],
"note": "Deterministic: already-published auction results"
}

How to use it:

• delivery_date: The date you’ll dispatch against. Prepare setpoints in advance and stream them to edges for validation.
• publish_date: Helps you ensure you pulled the latest curve post-auction.
• curve: Same structure as /electricity/hourly; build your day-ahead schedule and store a versioned copy for auditability.

3) /latest — Multi-commodity sanity checks and hedging context

Path: GET /latest

Purpose: Fetch the most recent price for one or more symbols in one call. It’s common to annotate electricity schedules with contemporaneous EUA_CO2, TTF_GAS, or oil benchmarks to quantify fuel and emissions context or to implement guardrails (do not charge if EUA above X and carbon intensity above Y).

Key params:

• symbols: Comma-separated list; can span categories (BRENT_CRUDE, TTF_GAS, EUA_CO2, OMIE_ES_DA)
• base: Optional currency filter

Example request:

curl -G https://energy-api.com/api/v1/latest \
--data-urlencode "symbols=OMIE_ES_DA,EUA_CO2,TTF_GAS" \
--data-urlencode "api_key=YOUR_API_KEY"

Example response (abbreviated fields explained earlier):

{
"success": true,
"date": "2026-06-11",
"base": "MIXED",
"rates": {
"OMIE_ES_DA": 66.70,
"EUA_CO2": 67.40,
"TTF_GAS": 38.15
},
"dates": {
"OMIE_ES_DA": "2026-06-11",
"EUA_CO2": "2026-06-11",
"TTF_GAS": "2026-06-11"
},
"currencies": {
"OMIE_ES_DA": "EUR",
"EUA_CO2": "EUR",
"TTF_GAS": "EUR"
}
}

How to use it:

• Use as a health and guardrail fetch on every schedule compute tick, enriching electricity setpoints with current EUA and gas context.
• If building a blended cost model, capture currency codes to avoid mixing units; apply conversions consistently in your UI and analytics.

4) /carbon-intensity — Carbon-aware dispatch

Path: GET /carbon-intensity

Purpose: Retrieve grid carbon intensity in gCO2eq/kWh. When carbon intensity is high, charge storage (if price allows); when low, prioritize consumption and compute jobs, or export where permitted.

Key params:

• country: ISO-2 (e.g., DE, ES, FR). Some aggregations also provide EU-wide intensity.

Example request:

curl -G https://energy-api.com/api/v1/carbon-intensity \
--data-urlencode "country=DE" \
--data-urlencode "api_key=YOUR_API_KEY"

Example response:

{
"success": true,
"country": "DE",
"unit": "gCO2eq/kWh",
"date": "2026-06-11",
"value": 341,
"source": "ENTSO-E/Ember",
"notes": "Aggregated national grid intensity"
}

How to use it:

• value: Compare against internal thresholds to switch modes (e.g., carbon-minimizing vs. cost-minimizing). Combine with /electricity/hourly to define windows that satisfy both price and carbon constraints.
• source: Store with schedule artifacts for audit and ESG reporting.

5) /timeseries — Trend analysis for policy and tuning

Path: GET /timeseries

Purpose: Retrieve historical series for one or more symbols between dates. Use this to tune controllers, validate savings, and build forecasting heuristics around recurring patterns (e.g., weekend troughs).

Key params:

• start, end: YYYY-MM-DD
• symbols: Comma-separated list; can span categories
• base: Optional currency filter

Example request:

curl -G https://energy-api.com/api/v1/timeseries \
--data-urlencode "start=2026-05-01" \
--data-urlencode "end=2026-05-15" \
--data-urlencode "symbols=OMIE_ES_DA,EUA_CO2" \
--data-urlencode "api_key=YOUR_API_KEY"

Example response:

{
"success": true,
"base": "MIXED",
"start_date": "2026-05-01",
"end_date": "2026-05-15",
"rates": {
"OMIE_ES_DA": {
"2026-05-01": 64.30,
"2026-05-02": 59.80
/* ... */
},
"EUA_CO2": {
"2026-05-01": 68.10,
"2026-05-02": 67.90
/* ... */
}
},
"frequencies": {
"OMIE_ES_DA": "daily",
"EUA_CO2": "daily"
},
"currencies": {
"OMIE_ES_DA": "EUR",
"EUA_CO2": "EUR"
}
}

How to use it:

• rates: A dictionary per symbol keyed by date. Ideal for charting and data validation. Align this with your dispatch logs to compute realized vs. counterfactual costs and emissions.
• frequencies and currencies: Drive UI labels and analytic joins without guessing metadata.

6) /status — Data provider health

Path: GET /status

Purpose: Visibility into last fetch status per data provider. Automate runbooks: if a source is temporarily delayed, keep previous values and flag monitoring rather than falling back to stale scrapes or stopping control.

Example request:

curl -G https://energy-api.com/api/v1/status \
--data-urlencode "api_key=YOUR_API_KEY"

Example response:

{
"success": true,
"providers": [
{"name": "OMIE", "last_fetch": "2026-06-11T12:04:10Z", "status": "ok"},
{"name": "ENTSO-E", "last_fetch": "2026-06-11T11:59:52Z", "status": "ok"},
{"name": "EIA", "last_fetch": "2026-06-11T10:15:30Z", "status": "ok"},
{"name": "FRED", "last_fetch": "2026-06-11T09:45:10Z", "status": "ok"},
{"name": "ESIOS", "last_fetch": "2026-06-11T12:00:01Z", "status": "ok"}
]
}

How to use it:

• Use status to conditionally widen your cache TTLs and switch alerting thresholds if upstream is delayed, preventing noisy incidents.

Endpoint Catalog at a Glance

A complete overview of available endpoints and how they fit into DER control and analytics:

• GET /symbols — Discover active symbols with metadata. Auto-generate config UIs and validation lists.
• GET /latest — Most recent price for one or more symbols, across categories.
• GET /historical — Prices for all symbols on a specific past date with backfill to latest prior publish if needed.
• GET /timeseries — Historical series between two dates, keyed by date for charting and trend logic.
• GET /fluctuation — Start/end values and changes over a period; handy for PnL and alert thresholds.
• GET /ohlc — Weekly/monthly/quarterly OHLC candles for volatility-aware strategies and dashboards.
• GET /electricity/latest — Latest prices for all electricity symbols; filter by country for targeted views.
• GET /electricity/hourly — Full intraday curve (15-min or hourly) for dispatch scheduling.
• GET /electricity/pvpc — Hourly Spanish PVPC retail reference prices; useful for retail benchmarking and cost pass-through modelling.
• GET /gas/latest — TTF_GAS (EU) and HENRY_HUB (US) in one call; fuel context for power price regimes.
• GET /emissions/latest — EU ETS allowance price (EUA_CO2); emissions cost context.
• GET /coal/latest — Coal benchmarks (API2 Rotterdam, Newcastle) for fuel-mix background.
• GET /carbon-intensity — Grid carbon intensity by country; core for carbon-aware dispatch.
• GET /forecast — Deterministic next day-ahead electricity auction results for supported symbols.
• POST /cost-estimate — Simple monthly wholesale cost estimate (latest price × kWh/month); quick budgeting.
• GET /status — Provider health to drive resilience strategies.

Implementation Guide: Data Fetching, Aggregation, and WebRTC Delivery

Below are pragmatic examples and design patterns to move from endpoints to a robust, low-latency system.

Batch multi-commodity refresh in Python

import os
import time
import requests

BASE = "https://energy-api.com/api/v1"
API_KEY = os.environ.get("ENERGY_API_KEY")

SYMBOLS = [
"OMIE_ES_DA", # Spain day-ahead electricity
"EUA_CO2", # EU ETS carbon
"TTF_GAS" # EU gas
]

def fetch_latest(symbols):
params = {
"symbols": ",".join(symbols),
"api_key": API_KEY
}
r = requests.get(f"{BASE}/latest", params=params, timeout=10)
data = r.json()
if not data.get("success"):
raise RuntimeError(f"Latest fetch failed: {data}")
return data

def fetch_intraday(symbol, date):
params = {"symbol": symbol, "date": date, "api_key": API_KEY}
r = requests.get(f"{BASE}/electricity/hourly", params=params, timeout=10)
data = r.json()
if not data.get("success"):
raise RuntimeError(f"Intraday fetch failed: {data}")
return data

def fetch_intensity(country):
params = {"country": country, "api_key": API_KEY}
r = requests.get(f"{BASE}/carbon-intensity", params=params, timeout=10)
data = r.json()
if not data.get("success"):
raise RuntimeError(f"Carbon intensity fetch failed: {data}")
return data

if __name__ == "__main__":
latest = fetch_latest(SYMBOLS)
print("Latest:", latest["rates"], latest["dates"])
# Example: refresh intraday for tomorrow after auction publish
intraday = fetch_intraday("OMIE_ES_DA", "2026-06-12")
print("Curve head:", intraday["curve"][:3])
intensity = fetch_intensity("ES")
print("Carbon intensity:", intensity["value"])

Tips:

• Parallelize requests when aggregating many symbols; keep individual per-call timeouts small, and retry transient network errors with exponential backoff.
• Persist both raw responses and your computed schedules with versioning (e.g., delivery_date + symbol + hash) for traceability.
• Normalize timestamps to the provider timezone presented by the endpoint and only convert for display, not for computation, to avoid DST pitfalls.

WebRTC data channel transport in JavaScript

Once your aggregator derives setpoints, use WebRTC data channels to push them to edges with low latency. Signaling (offer/answer/ICE) uses HTTPS via your signaling service; after connection, the data channel carries compact JSON frames.

// Aggregator side
const pc = new RTCPeerConnection({iceServers: [{urls: ["stun:stun.l.google.com:19302"]}]});
const channel = pc.createDataChannel("der-control", {ordered: true, maxRetransmits: 0}); // low latency

channel.onopen = () => {
console.log("Control channel open");
// Send an example setpoint frame
const frame = {
ts: Date.now(),
site_id: "site-123",
symbol: "OMIE_ES_DA",
window_start: "2026-06-12T01:00:00+02:00",
window_end: "2026-06-12T03:00:00+02:00",
action: "charge",
kw: 150,
reason_code: "PRICE_LOW_CARBON_MEDIUM"
};
channel.send(JSON.stringify(frame));
};

pc.onicecandidate = (e) => {
if (e.candidate) {
// POST to your signaling server to share ICE with the edge peer
}
};

// Create offer and share via signaling
(async () => {
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
// POST offer.sdp to signaling server for the edge
})();

Edge best practices:

• Acknowledge every setpoint with an application-level ack and include controller firmware version, applied constraints, and an acceptance status (accepted/deferred/rejected).
• If the data channel closes, fall back to short-polling your aggregator over HTTPS for the next-horizon schedule until the channel re-establishes.
• Use small, fixed schemas (e.g., 10–20 fields) and avoid sending full day curves repeatedly; send diffs or next 15–30 minutes of steps.

JSON frame schema for schedule delivery

{
"frame_type": "schedule_update",
"version": 1,
"generated_at": "2026-06-11T18:05:00Z",
"symbol": "OMIE_ES_DA",
"delivery_date": "2026-06-12",
"timezone": "Europe/Madrid",
"currency": "EUR",
"steps": [
{"t": "2026-06-12T01:00:00+02:00", "setpoint_kw": 150, "price": 65.10, "carbon": 320},
{"t": "2026-06-12T02:00:00+02:00", "setpoint_kw": 150, "price": 61.88, "carbon": 315}
],
"justification": {"policy": "COST_AND_CARBON_MIN", "eua_eur": 67.40, "gas_eur_mwh": 38.15}
}

Edges can validate that t slots align with timezone and that policy constraints match local capabilities before applying setpoints.

Complete Examples with cURL and JSON

Discover symbols to auto-configure controllers

Use /symbols to build dropdowns and validate configurations without hardcoding.

curl -G https://energy-api.com/api/v1/symbols \
--data-urlencode "category=electricity" \
--data-urlencode "api_key=YOUR_API_KEY"

{
"success": true,
"count": 3,
"symbols": [
{
"symbol": "OMIE_ES_DA",
"name": "OMIE Spain Day-Ahead",
"category": "electricity",
"country_code": "ES",
"currency_code": "EUR",
"frequency": "daily",
"description": "OMIE day-ahead auction price."
},
{
"symbol": "EPEX_DE_DA",
"name": "EPEX Germany Day-Ahead",
"category": "electricity",
"country_code": "DE",
"currency_code": "EUR",
"frequency": "daily",
"description": "EPEX Spot day-ahead price."
},
{
"symbol": "AEMO_NSW1",
"name": "AEMO NSW Region Price",
"category": "electricity",
"country_code": "AU",
"currency_code": "AUD",
"frequency": "intraday",
"description": "AEMO market price for NSW region."
}
]
}

Use count to sanity-check UI lists; frequency informs whether you expect intraday updates or daily auctions.

Historical backfill with /historical for reconciliation

curl -G https://energy-api.com/api/v1/historical \
--data-urlencode "date=2026-05-10" \
--data-urlencode "symbols=BRENT_CRUDE,TTF_GAS" \
--data-urlencode "api_key=YOUR_API_KEY"

{
"success": true,
"date": "2026-05-10",
"base": "MIXED",
"rates": {
"BRENT_CRUDE": 71.45,
"TTF_GAS": 36.20
},
"currencies": {
"BRENT_CRUDE": "USD",
"TTF_GAS": "EUR"
}
}

If a date falls on a non-publishing day, the endpoint returns the most recent value before it, ensuring continuity for PnL and benchmarking.

OHLC for risk and volatility visuals

curl -G https://energy-api.com/api/v1/ohlc \
--data-urlencode "symbols=EUA_CO2,TTF_GAS" \
--data-urlencode "period=monthly" \
--data-urlencode "start=2026-01-01" \
--data-urlencode "end=2026-06-01" \
--data-urlencode "api_key=YOUR_API_KEY"

{
"success": true,
"symbols": {
"EUA_CO2": [
{"period": "2026-01", "open": 72.1, "high": 75.5, "low": 68.3, "close": 70.8, "data_points": 22},
{"period": "2026-02", "open": 70.9, "high": 73.2, "low": 66.8, "close": 71.1, "data_points": 20}
],
"TTF_GAS": [
{"period": "2026-01", "open": 39.5, "high": 42.4, "low": 36.7, "close": 38.6, "data_points": 22}
]
}
}

Use OHLC to power candlestick charts, identify regime shifts, and modulate aggressiveness of arbitrage or shifting strategies.

Error Handling and Resilience Patterns

Robust DER platforms treat upstream variance as normal. Energy API uses clear error codes so you can respond intelligently:

• 401 — Missing or invalid api_key: Ensure the client includes proper credentials; log and quarantine misconfigured instances.
• 404 — No data for the given symbols or date: Either you requested a non-auction forecast for a non-supported symbol, or the symbol/date combination isn’t available. Fall back to last known good and alert.
• 422 — Validation error: Fix parameter formats (symbol typos, bad date format).
• 429 — Rate limit exceeded: Implement exponential backoff and avoid bursty fetch loops; stagger refreshes across sites.

Generic error response shape:

{
"success": false,
"error": "Human-readable message."
}

Best practices:

• Retry only idempotent GETs and apply jitter. Keep an LRU cache of recent results to satisfy non-critical reads during intermittent faults.
• Use /status to dynamically adjust polling intervals. When providers are healthy, you can run on standard cadence; when delayed, extend cache TTLs and flag monitors rather than hammering endpoints.
• For forecast planning, verify that publish_date increments as expected before overwriting schedules; retain the prior day’s schedule until the new one is fully validated.

Real-World Use Cases

Price- and Carbon-Aware EV Smart Charging

A fleet operator wants to charge when day-ahead prices are lowest and carbon intensity is below a threshold. The aggregator fetches /electricity/hourly for OMIE_ES_DA, pulls /carbon-intensity for ES, overlays the two, and streams a charging schedule via WebRTC to each depot’s edge controller. /latest provides EUA_CO2 and TTF_GAS context to adjust aggressiveness when fuel or carbon costs spike.

Battery Arbitrage with Day-Ahead Certainty

A C&I site runs a 2 MWh battery. The aggregator reads /forecast for EPEX_DE_DA to get the deterministic next-day curve, computes charge/discharge windows and reserve capacity, then sends steps over the WebRTC channel. During delivery day, it uses /electricity/hourly to confirm any intraday adjustments and logs actual performance with timestamps and curve points for settlement and audits.

ESG Dashboard and Operations Review

The sustainability team aggregates /timeseries for OMIE_ES_DA and EUA_CO2 into daily charts showing price and carbon trends, augmented by /carbon-intensity to contextualize emissions per kWh. They compute avoided emissions compared to a baseline and reconcile outliers by pulling specific days with /historical. Annotations note provider health windows using /status to explain any data gaps.

Performance Tips for Low Latency

• Batch and parallelize: Use /latest to fetch multiple symbols at once. Parallelize electricity curves across regions during day-ahead publication windows.
• Pre-compute edges’ next-horizon sets: At every price tick, compute and queue the next 15–30 minutes of setpoints and immediately send deltas on the WebRTC channel.
• Compact payloads: Send only necessary fields and use short keys in frames if bandwidth is constrained. Consider MessagePack on the data channel if both ends support it.
• Regional proximity: Deploy your aggregator close to your edge fleet’s dominant geography to minimize propagation delay and TURN relay distance.

Frequently Asked Questions

How often does the TTF gas price update?

TTF_GAS updates follow its source’s publication cadence and are exposed through /latest and /timeseries as soon as new values are available. Use /dates in the /latest response to confirm the specific as-of date for your calculations.

Can I get historical energy prices going back multiple years?

Yes. Use /timeseries with start and end dates to query historical windows for electricity, gas, oil, coal, and carbon. For reconciliation on a single date, use /historical, which backfills to the most recent prior publish if the chosen date is a non-publishing day.

Does the API support multiple commodities in one request?

Yes. /latest accepts a comma-separated symbols list that can span electricity, gas, oil, coal, and carbon. This is ideal for building context-rich control policies and dashboards without juggling separate queries.

Can I get the full intraday curve for electricity markets?

Yes, where sources publish intraday shapes. Use /electricity/hourly to retrieve 15-minute or hourly curves for a given symbol and date. Pair it with /forecast to stage next-day schedules immediately after the auction result is published.

How do I handle provider delays without breaking my edge controllers?

Check /status to monitor provider health and widen cache TTLs if a source is delayed. Keep fallback logic at the edge to use the last known schedule and short-poll the aggregator over HTTPS if the WebRTC data channel disconnects.

Conclusion + CTA

If you are building DER control, trading operations, or carbon-aware load shifting, the bottleneck should never be your data ingestion. With a single normalized interface across electricity, gas, oil, coal, carbon allowances, and grid carbon intensity, Energy API lets you spend your engineering budget on algorithms and control—not on parsing CSVs and normalizing timezones.

By pairing Energy API with WebRTC data channels, you can pull deterministic day-ahead curves, layer in real-time carbon and fuel context, and deliver sub-second setpoints to sites—backed by clear health signals and consistent schemas. This is the fastest path from prototype to a resilient, low-latency edge aggregator that passes audit and drives measurable savings and emissions reductions.

Ready to wire your controllers to clean, normalized market and grid intelligence? Explore the endpoints, run the examples above, and start shipping production features today. Try Energy API for free and build the edge you want with the reliability your grid partners demand.