Provenance-First Carbon Accounting: Using Energy API to Trace Scope 2 and Scope 3 Emissions Back to Source Generation

Provenance-first carbon accounting sounds simple in theory: connect every kilowatt-hour you consume and every upstream energy input embedded in your supply chain to the actual source generation and its carbon factors. In practice, it’s relentlessly hard. Electricity price curves live in different portals than grid carbon intensity. Gas, oil, coal, and carbon allowance prices all arrive on different schedules with different units and symbol naming. And the moment you try to scale beyond one region, the differences between OMIE, ENTSO-E, EIA/FRED, ESIOS, and others multiply into weeks of ETL glue work.

If you’re a developer, data engineer, or ESG product team, you don’t want to build and maintain parsers for a patchwork of government and exchange websites. You want reliable market and carbon signals with consistent schemas, so you can model Scope 2 (electricity) and Scope 3 (supply chain energy inputs) emissions back to their provenance with confidence. You want to move from proof-of-concept to production dashboards, calculators, alerts, and automated attestations in days—not months.

This post shows how to build provenance-first carbon accounting with the unified JSON surface of Energy API. We’ll trace Scope 2 and Scope 3 emissions back to source generation using day-ahead and intraday electricity curves, country-level grid carbon intensity, wholesale gas/oil/coal benchmarks, and EU ETS allowance prices—without juggling incompatible data formats. You’ll see how to join these signals, compute carbon per-kWh and per-MWh costs, and assemble audit-ready evidence of your calculations.

Why Energy API

Energy API aggregates official wholesale energy market data and normalizes it across electricity, gas, oil, coal, carbon allowances, and grid carbon intensity—exposing a single REST interface with one schema. Here are the developer-level differences that matter when you’re shipping provenance-first carbon features:

• One normalized REST surface across sources and commodities. You can request OMIE day-ahead prices, ENTSO-E/EEX electricity curves, TTF gas, Brent/WTI crude, API2 coal, EU ETS prices, and grid carbon intensity using the same request/response shape. This slashes glue code and lets you compose cross-commodity features quickly.
• Multi-symbol aggregation in one call. Query electricity, gas, and carbon together, and Energy API returns a keyed object with mixed currencies and dates included explicitly. That makes it trivial to align price and carbon factors in one pass.
• Intraday electricity curves with 15-minute or hourly granularity (where sources publish them). For hourly or quarter-hourly Scope 2 attribution, you need shapes, not just daily averages. With a dedicated electricity/hourly endpoint, you can bind consumption profiles directly to published auction outcomes.
• Deterministic day-ahead forecasts for auction-sourced symbols. The forecast endpoint returns already-published next-day results, perfect for planning, hedging, and scheduling without the uncertainty of predictive models. It’s a time-saver for day-ahead procurement logic and pre-calculating tomorrow’s carbon.

Together, these features make provenance-first workflows—from Scope 2 hourly matching to Scope 3 feedstock normalization—straightforward and reproducible. You can pull just what you need, when you need it, and prove where every factor came from.

Quick Start

Base URL for all requests:

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

Authentication uses a query parameter. Example: ?api_key=YOUR_API_KEY

Let’s fetch the most recent values for multiple commodities in one request—electricity (Spain day-ahead), gas (TTF), and EU ETS carbon allowances:

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

Sample JSON response:

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

Key fields you’ll use:

• rates: numeric values indexed by symbol; your primary input for cost/carbon math.
• dates: the effective publishing date per symbol; critical for aligning time coverage across mixed sources.
• currencies: currency per symbol; currency-aware math is essential when blending EUR-based and USD-based benchmarks.

With one response, you can calculate the carbon cost component per MWh using EUA_CO2 and an assumed emissions factor, or you can sanity check the relation between gas and power prices for a Scope 3 estimation model that ties feedstock to marginal generation.

Core Endpoints

1) Discoverability with GET /symbols

Assembling a multi-region Scope 2/3 model starts by discovering what’s available—symbols, categories, frequency, currency, and descriptions. The symbols endpoint provides machine-readable metadata so you can programmatically build lists of electricity, gas, oil, coal, carbon, and carbon intensity sources.

Endpoint:

GET /symbols

Key params:

• category: Filter by gas, electricity, oil, coal, carbon, or carbon_intensity
• base and provider: Optional filters if you want to target specific currencies or upstream sources

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

Sample JSON response:

{
"success": true,
"count": 4,
"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 for Spain."
},
{
"symbol": "EPEX_DE_DA",
"name": "EPEX Germany Day-Ahead",
"category": "electricity",
"country_code": "DE",
"currency_code": "EUR",
"frequency": "daily",
"description": "EPEX SPOT day-ahead auction price for Germany."
},
{
"symbol": "PVPC_ES_2TD",
"name": "PVPC Spain 2.0TD",
"category": "electricity",
"country_code": "ES",
"currency_code": "EUR",
"frequency": "hourly",
"description": "Spanish PVPC retail reference price (2.0TD)."
},
{
"symbol": "AEMO_NSW1",
"name": "AEMO NSW Region",
"category": "electricity",
"country_code": "AU",
"currency_code": "AUD",
"frequency": "5min",
"description": "AEMO NSW region wholesale electricity."
}
]
}

How to use it:

• Build symbol pickers in your UI auto-populated by country_code and category, so users can choose their regional electricity benchmark or carbon intensity data quickly.
• Automate Scope 3 coverage by scanning gas, oil, and coal categories for relevant feedstocks in your specific regions.

2) Hourly intraday curves with GET /electricity/hourly

For provenance-first Scope 2, you need to attribute consumption to generation at the right hour (or quarter-hour). The electricity/hourly endpoint returns the full intraday curve for the given symbol and date where the source publishes intraday or day-ahead hourly blocks.

Endpoint:

GET /electricity/hourly

Key params:

• symbol: Electricity symbol (e.g., OMIE_ES_DA, EPEX_DE_DA)
• date: YYYY-MM-DD (market date of delivery)

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"

Sample JSON response:

{
"success": true,
"symbol": "OMIE_ES_DA",
"date": "2026-06-12",
"currency": "EUR",
"granularity": "hourly",
"curve": [
{"time": "2026-06-12T00:00:00Z", "price": 76.10},
{"time": "2026-06-12T01:00:00Z", "price": 73.45},
{"time": "2026-06-12T02:00:00Z", "price": 70.20},
{"time": "2026-06-12T03:00:00Z", "price": 68.50},
{"time": "2026-06-12T04:00:00Z", "price": 69.00},
{"time": "2026-06-12T05:00:00Z", "price": 71.15},
{"time": "2026-06-12T06:00:00Z", "price": 78.90},
{"time": "2026-06-12T07:00:00Z", "price": 85.25},
{"time": "2026-06-12T08:00:00Z", "price": 92.30},
{"time": "2026-06-12T09:00:00Z", "price": 88.40},
{"time": "2026-06-12T10:00:00Z", "price": 83.60},
{"time": "2026-06-12T11:00:00Z", "price": 81.75},
{"time": "2026-06-12T12:00:00Z", "price": 80.10},
{"time": "2026-06-12T13:00:00Z", "price": 79.55},
{"time": "2026-06-12T14:00:00Z", "price": 78.35},
{"time": "2026-06-12T15:00:00Z", "price": 77.90},
{"time": "2026-06-12T16:00:00Z", "price": 80.40},
{"time": "2026-06-12T17:00:00Z", "price": 86.25},
{"time": "2026-06-12T18:00:00Z", "price": 91.15},
{"time": "2026-06-12T19:00:00Z", "price": 89.05},
{"time": "2026-06-12T20:00:00Z", "price": 84.80},
{"time": "2026-06-12T21:00:00Z", "price": 82.25},
{"time": "2026-06-12T22:00:00Z", "price": 80.60},
{"time": "2026-06-12T23:00:00Z", "price": 78.90}
]
}

Key fields:

• granularity: hourly or 15-min depending on the market; align your consumption time buckets accordingly.
• curve: array of time-stamped price points; join this to your meter data or schedule carbon attribution at the same resolution for deterministic Scope 2 reporting.

3) Grid carbon intensity with GET /carbon-intensity

Price tells you cost; intensity tells you kilograms of CO2e per kWh. The carbon-intensity endpoint returns gCO2eq/kWh by country—your essential factor to translate consumption into emissions when plant-level or supplier-specific EF is not available.

Endpoint:

GET /carbon-intensity

Key params:

• country: ISO-2 country code (e.g., DE, ES, FR)

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

Sample JSON response:

{
"success": true,
"country": "DE",
"unit": "gCO2eq/kWh",
"date": "2026-06-11",
"value": 365,
"source": "ENTSO-E / Ember"
}

How to use it:

• Multiply your hourly kWh by value/1000 to get kgCO2 for that period if you lack vendor-specific EF. For provenance-first logic, pair this with the electricity/hourly curve on the same timestamp to present a joined price + carbon view.
• Use country in lockstep with your electricity symbol’s country_code to avoid cross-region mismatches.

4) EU ETS allowance price with GET /emissions/latest

Carbon pricing influences marginal generation costs and can be an explicit line item in your carbon cost accounting. The emissions/latest endpoint returns the current EUA_CO2 price, standardized.

Endpoint:

GET /emissions/latest

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

Sample JSON response:

{
"success": true,
"symbol": "EUA_CO2",
"date": "2026-06-11",
"currency": "EUR",
"value": 67.40
}

Practical tip:

• Estimate an implicit carbon cost per MWh by applying EUA_CO2 to a marginal emissions factor for your market (e.g., gas or coal reference), and compare to your contract price. This supports decision-making on PPAs, RECs, or temporal load shifting.

5) Historical alignment with GET /timeseries

To validate claims and build auditable trends, you need clean time-aligned histories. The timeseries endpoint returns daily series for one or many symbols in one response, keyed by date—perfect for charting, regressions, and backtesting.

Endpoint:

GET /timeseries

Key params:

• start, end: YYYY-MM-DD range
• symbols: comma-separated list, possibly cross-commodity

curl -G https://energy-api.com/api/v1/timeseries \
--data-urlencode "start=2026-04-01" \
--data-urlencode "end=2026-06-10" \
--data-urlencode "symbols=EPEX_DE_DA,TTF_GAS,EUA_CO2,CARBON_INT_DE" \
--data-urlencode "api_key=YOUR_API_KEY"

Sample JSON response (truncated dates for brevity):

{
"success": true,
"base": "MIXED",
"start_date": "2026-04-01",
"end_date": "2026-06-10",
"rates": {
"EPEX_DE_DA": {
"2026-04-01": 65.30,
"2026-04-02": 66.90
},
"TTF_GAS": {
"2026-04-01": 34.10,
"2026-04-02": 34.85
},
"EUA_CO2": {
"2026-04-01": 66.25,
"2026-04-02": 66.90
},
"CARBON_INT_DE": {
"2026-04-01": 372,
"2026-04-02": 365
}
},
"frequencies": {
"EPEX_DE_DA": "daily",
"TTF_GAS": "daily",
"EUA_CO2": "daily",
"CARBON_INT_DE": "daily"
},
"currencies": {
"EPEX_DE_DA": "EUR",
"TTF_GAS": "EUR",
"EUA_CO2": "EUR",
"CARBON_INT_DE": "gCO2eq/kWh"
}
}

Field notes:

• rates: nested objects per symbol keyed by ISO date—ideal for left-join operations when building unified panels for analytics or ML.
• frequencies: clarifies daily vs other cadences; match your rolling windows accordingly.
• currencies: some series are not currency but “units” (e.g., gCO2eq/kWh). Always unit-check before combining values.

6) Day-ahead certainty with GET /forecast

For markets with day-ahead auctions, you often want the next published delivery day’s price to plan operations or pre-compute tomorrow’s emissions. The forecast endpoint returns the next already-published day-ahead result for supported auction symbols.

Endpoint:

GET /forecast

Key params:

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

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

Sample JSON response:

{
"success": true,
"symbol": "EPEX_DE_DA",
"delivery_date": "2026-06-12",
"currency": "EUR",
"value": 78.90,
"note": "Published day-ahead auction result."
}

How it helps:

• Schedule load and compute tomorrow’s Scope 2 emissions early by pairing forecast with expected consumption. If you also maintain a forecasted carbon intensity curve (or a conservative baseline), you can present users with a forward view of price + carbon to inform operations.

7) Fast comparisons with GET /gas/latest, /coal/latest, and GET /electricity/latest

Scope 3 involves upstream feedstocks and fuels. For benchmarking and quick comparisons, category endpoints return key symbols together. These lightweight calls let you staple cross-commodity context into a single panel or alert.

Examples:

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

{
"success": true,
"symbols": ["TTF_GAS", "HENRY_HUB"],
"date": "2026-06-11",
"rates": {
"TTF_GAS": 38.15,
"HENRY_HUB": 2.67
},
"currencies": {
"TTF_GAS": "EUR",
"HENRY_HUB": "USD"
}
}

Likewise for coal:

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

And for a fast inventory of electricity benchmarks:

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

Use case:

• Dashboards that present power benchmarks side-by-side with gas and coal enable context-aware Scope 3 attribution logic (e.g., marginal plant reasoning). Instant category calls simplify periodic refresh jobs and on-demand analytics pages.

8) Price deltas with GET /fluctuation and shape summaries with GET /ohlc

For P&L, hedging analyses, or alerting, you need summarized change metrics and volatility snapshots. The fluctuation endpoint returns start/end values, absolute change, and percentage change; the ohlc endpoint returns weekly, monthly, or quarterly candles for each symbol—ideal for trend dashboards or stress tests.

Examples:

curl -G https://energy-api.com/api/v1/fluctuation \
--data-urlencode "start=2026-05-01" \
--data-urlencode "end=2026-06-10" \
--data-urlencode "symbols=EUA_CO2,TTF_GAS,EPEX_DE_DA" \
--data-urlencode "api_key=YOUR_API_KEY"

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

Practical tip:

• Use fluctuation for status emails and in-app notifications on significant weekly carbon or energy price changes. Use ohlc to visualize regime shifts and to calibrate variance in your Scope 3 embodied energy calculators.

9) Retail reference and cost sanity check: GET /electricity/pvpc and POST /cost-estimate

When building B2C or SMB-facing tools, Spanish PVPC hourly prices are a canonical retail reference for transparency. The pvpc endpoint provides those hourly values. The cost-estimate endpoint gives a simple monthly wholesale-based cost estimate—handy for quick “what would my energy cost be” widgets that also contextualize carbon.

Examples:

curl -G https://energy-api.com/api/v1/electricity/pvpc \
--data-urlencode "date=2026-06-11" \
--data-urlencode "api_key=YOUR_API_KEY"

curl -X POST https://energy-api.com/api/v1/cost-estimate \
-H "Content-Type: application/json" \
-d '{"symbol":"OMIE_ES_DA","kwh_per_month":450}' \
--globoff "?api_key=YOUR_API_KEY"

Note: cost-estimate returns a simple multiplication of latest wholesale price × kWh/month and omits taxes, network charges, or profile effects; use it as a sanity check, not a final biller.

10) Operational confidence with GET /status

Production-grade provenance accounting depends on data pipeline health. The status endpoint returns the last fetch status per data provider so you can automate checks, set up monitors, and fail gracefully if a source experiences a delay.

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

Example response:

{
"success": true,
"providers": [
{"provider": "OMIE", "last_fetch": "2026-06-11T22:10:03Z", "status": "ok"},
{"provider": "ENTSO-E", "last_fetch": "2026-06-11T22:05:12Z", "status": "ok"},
{"provider": "ESIOS", "last_fetch": "2026-06-11T21:58:49Z", "status": "ok"},
{"provider": "EIA", "last_fetch": "2026-06-11T19:30:11Z", "status": "ok"},
{"provider": "FRED", "last_fetch": "2026-06-11T19:30:13Z", "status": "ok"}
]
}

Use it to:

• Gate daily ETL: only proceed to recompute carbon accounting tables when upstreams are green, otherwise pause and alert.
• Annotate dashboards with last_fetch timestamps for transparent data freshness.

Joining price and carbon for provenance-first Scope 2 and Scope 3

The central idea is to join electricity price curves with carbon intensity and track fuel/allowance benchmarks that shape marginal generation and embodied emissions. Here’s a practical approach:

• Scope 2 hourly: For each hour h, fetch electricity/hourly for your region and carbon-intensity for the same country. Compute cost_h = price_h × kWh_h and carbon_h = (intensity_h gCO2/kWh × kWh_h) / 1000. Roll up to daily/monthly totals and retain per-hour records for audit trails.
• Scope 3 energy inputs: Use TTF_GAS, COAL_ROTTERDAM, BRENT_CRUDE/WTI_CRUDE, and EUA_CO2 to estimate the carbon and cost influence of upstream energy in your suppliers’ processes. Even if you start with sectoral or region-level coefficients, these benchmarks anchor your factors in observable market signals, improving transparency.
• Provenance proof: Store symbol, date, currency, and the original API response snippet used for each calculation. That way, you can always reconstitute your claims and show exactly what market facts your numbers came from.

End-to-end example: cURL, Python, and JavaScript

The following examples fetch key signals, join them, and compute basic carbon-adjusted figures. They’re intentionally simple; adapt them to your stack, add retries/backoff where needed, and persist to your data warehouse.

Example: cURL one-shot multi-symbol fetch

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

Interpretation:

• EPEX_DE_DA: EUR/MWh price baseline for Germany.
• CARBON_INT_DE: gCO2eq/kWh grid intensity baseline.
• TTF_GAS + EUA_CO2: rough proxy for marginal cost/carbon pressure on power prices.

Example: Python hourly Scope 2 attribution

import requests
from datetime import date

API="https://energy-api.com/api/v1"
KEY="YOUR_API_KEY"

symbol = "EPEX_DE_DA"
delivery = "2026-06-12"
country = "DE"

curve = requests.get(f"{API}/electricity/hourly", params={
"symbol": symbol,
"date": delivery,
"api_key": KEY
}).json()

intensity = requests.get(f"{API}/carbon-intensity", params={
"country": country,
"api_key": KEY
}).json()

g_per_kwh = intensity["value"] # gCO2eq/kWh

# Example: flat 1.5 kWh per hour consumption profile for demo purposes
hours = curve["curve"]
kwh_profile = { pt["time"]: 1.5 for pt in hours }

records = []
for pt in hours:
ts = pt["time"]
price_eur_per_mwh = pt["price"]
kwh = kwh_profile[ts]
eur = (price_eur_per_mwh / 1000.0) * kwh # EUR/MWh to EUR/kWh × kWh
kgco2 = (g_per_kwh / 1000.0) * kwh
records.append({"time": ts, "price_EUR_MWh": price_eur_per_mwh, "kWh": kwh, "EUR": eur, "kgCO2": kgco2})

daily_eur = round(sum(r["EUR"] for r in records), 2)
daily_kgco2 = round(sum(r["kgCO2"] for r in records), 3)

print({"symbol": symbol, "date": delivery, "total_EUR": daily_eur, "total_kgCO2": daily_kgco2})

This snippet demonstrates the core provenance-first loop: electricity/hourly + carbon-intensity at country level, consumption profile, cost and carbon per hour, and a sum you can attest to. Replace the flat profile with actual meter data.

Example: JavaScript Scope 3 fuel and allowance panel

async function fetchJSON(url, params) {
const qs = new URLSearchParams(params);
const res = await fetch(url + "?" + qs.toString());
if (!res.ok) throw new Error("Request failed: " + res.status);
return res.json();
}

(async () => {
const API = "https://energy-api.com/api/v1";
const KEY = "YOUR_API_KEY";

const latest = await fetchJSON(API + "/latest", {
symbols: "TTF_GAS,BRENT_CRUDE,COAL_ROTTERDAM,EUA_CO2",
api_key: KEY
});

const { rates, dates, currencies } = latest;

// Example normalization structure for UI cards
const panel = Object.keys(rates).map(sym => ({
symbol: sym,
value: rates[sym],
asOf: dates[sym],
unit: currencies[sym]
}));

console.table(panel);
})();

Use this to render quick-glance cards in your web UI, then drill down with timeseries and ohlc for context “sparklines” and volatility bands.

Real-World Use Cases

1) Hourly Scope 2 attestation with price + carbon overlays

Build a dashboard that reconciles a facility’s hourly consumption with the actual day-ahead cleared prices and country-level carbon intensity. Use /electricity/hourly for intraday shapes and /carbon-intensity for gCO2eq/kWh. Optionally fetch /forecast to pre-compute tomorrow’s figures and alert operations teams if a peak/carbon spike is expected.

2) Supplier Scope 3 embodied energy estimator

Create an estimator that maps upstream supplier processes to benchmark fuel and allowance prices with /gas/latest, /coal/latest, /latest (for BRENT_CRUDE or WTI_CRUDE), and /emissions/latest. Calibrate process-specific emissions factors and show how day-to-day changes in TTF_GAS or EUA_CO2 would shift indirect emissions and costs. For transparency, cache the response payloads and provide users a “view sources” panel.

3) Carbon-aware P&L and hedging cockpit

Combine /timeseries, /fluctuation, and /ohlc to present finance teams with a carbon-adjusted P&L. Fold EUA_CO2 into your marginal cost model, and overlay EPEX_DE_DA or OMIE_ES_DA histories to identify dislocations. Pair with /status to ensure data recency before running daily reports. This helps align trading, procurement, and ESG reporting with a single set of facts.

Error handling, data quality, and operational tips

Production systems must be robust to publishing schedules, holidays, and occasional upstream maintenance windows. Energy API uses clear HTTP status codes and consistent error messages:

• 401: Missing or invalid api_key. Ensure you pass the api_key query parameter.
• 404: No data for given symbols/date. For non-publishing days, /historical returns the latest prior value; still handle true 404s with user-friendly messages.
• 422: Validation errors for missing/invalid params. Validate symbols and dates client-side and server-side.
• 429: Rate limit exceeded. Implement exponential backoff and jitter, and consider batching symbols in fewer calls.

Best practices:

• Use /status before large batch ETL to guard against partial-day updates; annotate dashboards with provider last_fetch.
• Always persist currency/unit metadata from responses. Don’t assume EUR or USD; carbon intensity uses gCO2eq/kWh.
• For intraday logic, align timezone handling. Energy API timestamps are ISO-8601; standardize in UTC internally, then localize for UI display.
• Normalize shapes: hourly vs 15-min. Resample consistently if you must blend markets with different granularities.
• Cache small reference calls (e.g., /symbols, /emissions/latest) sensibly to lower latency and increase resilience.

Putting it together: a provenance-first data model

To make your carbon accounting fully traceable, design your warehouse model around source provenance and reproducibility:

• facts_consumption_hourly: facility_id, ts_utc, kwh, meter_source.
• facts_power_price_hourly: market_symbol, ts_utc, price, currency, fetch_as_of.
• facts_intensity_daily: country, date, intensity_g_per_kwh, source_label.
• facts_benchmarks_daily: symbol, date, value, unit, source_label.
• facts_carbon_accounting_hourly: join of consumption with price + intensity; store inputs (symbol/date/unit) and the computed outputs (eur, kgco2) per hour.

This schema allows you to regenerate any number, prove where every factor came from, and upgrade logic (e.g., replacing country intensity with supplier-specific EF) without losing lineage. You can also snapshot Energy API responses used for filings to preserve a complete audit trail.

More endpoint examples for completeness

GET /latest across multiple commodities

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

Interpret for Scope 3 fossil baseline comparisons across oil/coal benchmarks and regional exposures.

GET /historical for point-in-time checks

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

Historical snapshots are ideal for backfilling accounting periods or reconciling statements at month close. If the date is a non-publishing day, you’ll receive the most recent prior value—which is usually what auditors expect when evaluating a weekend or holiday reference.

FAQ

How often does the TTF gas price update?

TTF_GAS is provided as a daily benchmark publication. Use /latest for the most current fix and /timeseries to pull date-keyed histories. For sensitivity or scenario work, combine TTF_GAS with electricity benchmarks (e.g., EPEX_DE_DA) to understand pass-through effects.

Can I get historical energy prices going back multiple years?

Yes, use /timeseries with a start and end date to pull multi-year histories for supported symbols. Many developers pair long-run /timeseries with /ohlc to create scalpel and macro lenses on the same data—detailed daily series plus summarized monthly or quarterly candles.

Does the API support multiple commodities in the same call?

Yes. /latest, /historical, /timeseries, and /fluctuation accept multiple symbols across electricity, gas, oil, coal, carbon, and carbon intensity. The response includes per-symbol currencies/units so you can safely normalize math.

How do I attribute hourly consumption to published electricity prices?

Call /electricity/hourly for your market symbol and date, then join its curve to your meter timestamps. Ensure timezone alignment and granularity matching (hourly vs 15-min). For carbon, pair with /carbon-intensity and compute kgCO2 = (gCO2/kWh × kWh)/1000 per interval.

How can I monitor data freshness before running my daily jobs?

Use /status to retrieve last_fetch timestamps and statuses per provider. Block or delay ETL if a critical provider shows a lag, and surface a friendly “data is updating” banner in your UI to keep stakeholders informed.

Conclusion + CTA

Provenance-first carbon accounting succeeds when your inputs are consistent, auditable, and easy to combine. Instead of stitching together OMIE, ENTSO-E, EIA/FRED, ESIOS, and carbon intensity feeds by hand, build on a normalized REST surface that lets you query electricity, gas, oil, coal, carbon allowances, and grid carbon intensity with one schema. With intraday curves, multi-symbol aggregation, and deterministic day-ahead forecasts, you can deliver precise Scope 2 hourly attribution and defensible Scope 3 estimations faster than ever.

If you’re ready to move from ad-hoc spreadsheets to production-grade systems, integrate Energy API into your data pipelines and dashboards. Assemble hourly cost and carbon overlays, generate audit-ready histories, and empower operations and finance teams with transparent, up-to-date market context. Start building today with Energy API and ship features your stakeholders can trust. Try Energy API for free and make provenance-first carbon accounting your default.