Historical Great Britain Carbon Intensity Prices

You need a reliable way to pull historical Great Britain grid carbon intensity as a clean time series so you can backtest, monitor, or alert on emissions per kilowatt-hour. By the end of this guide, you will be able to call the Energy API timeseries endpoint for the Great Britain Carbon Intensity symbol, handle empty data safely, and parse the response into a structure you can store and chart.

What you are querying: Great Britain Carbon Intensity (CARBON_INT_GB)

This guide targets a single Energy API symbol:

• Symbol name: Great Britain Carbon Intensity
• Symbol code: CARBON_INT_GB
• Unit: gCO2/kWh

The series is emissions intensity of electricity (grams of CO2 per kilowatt-hour) for Great Britain. For historical analysis, you will request a date range and the API will return a timeseries keyed by date. You will authenticate with an api_key query parameter.

Endpoint, authentication, and pricing

The timeseries endpoint accepts a start date, end date, and one or more symbols, all passed as query parameters along with your API key.

• Method: GET
• URL: https://energy-api.com/api/v1/timeseries
• Auth: api_key query parameter (use YOUR_API_KEY in examples)
• Starter plan: $19.99/mo, 7-day trial / 50 calls

When mixing symbols across certain commodity classes, do not pass base=USD when you also need TTF_GAS or EUA_CO2. For CARBON_INT_GB alone, you do not need a base parameter.

Copy-paste cURL request

This call requests the Great Britain Carbon Intensity series for Q1 2026. Replace YOUR_API_KEY with your credential when you run it.

curl -G "https://energy-api.com/api/v1/timeseries" --data-urlencode "start=2026-01-01" --data-urlencode "end=2026-03-31" --data-urlencode "symbols=CARBON_INT_GB" --data-urlencode "api_key=YOUR_API_KEY"

Official sample response (verbatim from live source)

The following is the official sample envelope from the live source. It demonstrates field names and shapes you may encounter. Note that the symbol shown here is OMIE_ES_DA, not CARBON_INT_GB. Use this to understand the envelope; do not treat the embedded value as the carbon intensity series.

{
"success": true,
"date": "2026-10-12",
"base": "EUR",
"rates": {
"OMIE_ES_DA": 184.8822
},
"dates": {
"OMIE_ES_DA": "2026-10-12"
},
"currencies": {
"OMIE_ES_DA": "EUR"
},
"base_filter_note": null
}

Field pointers you will actually use for CARBON_INT_GB:

• success: boolean indicating whether data was returned
• rates: container for symbol-labeled data (for time series, expect data keyed by date under your symbol)
• dates: container with per-symbol date metadata
• currencies: container with per-symbol currency/unit metadata; for CARBON_INT_GB this points to the measurement unit context rather than a traded currency
• date: the API response date stamp (not your time series date range)
• base and base_filter_note: present for some commodity series; you do not need a base for CARBON_INT_GB

Real CARBON_INT_GB API response observed

When querying the CARBON_INT_GB symbol, you may receive an error envelope indicating that no data is available for the requested window. The following is the real error response you must handle; copy it exactly in your tests to ensure your parser is robust.

{"success":false,"error":"No rate data available for the requested symbols."}

Interpretation:

• success is false, so you should not expect timeseries values in rates.
• error contains a human-readable reason that you can log or surface in observability.
• Next action: adjust your date range, verify the symbol code equals CARBON_INT_GB, or try again later if you know the provider window has delayed publication.

Additional complete JSON examples to validate your parser

Use these error envelopes as-is to write unit tests for failure-path logic. They are the same shape but you can exercise different control paths in your code.

Example A: Same request, retried

{"success":false,"error":"No rate data available for the requested symbols."}

Example B: Narrower date window

{"success":false,"error":"No rate data available for the requested symbols."}

Example C: Longer historical backfill attempt

{"success":false,"error":"No rate data available for the requested symbols."}

The key is to assert that your client checks success before attempting to read rates or currencies, and that it surfaces the error string for diagnostics.

End-to-end Python example for CARBON_INT_GB

The following Python sample calls the timeseries endpoint, checks the success flag, and demonstrates how you would process the rates payload if present. It purposefully accommodates an empty-data scenario like the real response shown above.

import os
import sys
import json
import urllib.parse
import urllib.request

API_URL = "https://energy-api.com/api/v1/timeseries"
API_KEY = "YOUR_API_KEY" # replace when running locally

params = {
"start": "2026-01-01",
"end": "2026-03-31",
"symbols": "CARBON_INT_GB",
"api_key": API_KEY,
}
query = urllib.parse.urlencode(params)
url = f"{API_URL}?{query}"

try:
with urllib.request.urlopen(url, timeout=20) as resp:
payload = resp.read().decode("utf-8")
data = json.loads(payload)
except Exception as e:
print(f"HTTP error: {e}", file=sys.stderr)
sys.exit(1)

# Always check the success flag first
if not isinstance(data, dict) or not data.get("success", False):
# Mirrors the real envelope observed for CARBON_INT_GB
err = data.get("error", "Unknown error")
print(f"API returned no data for CARBON_INT_GB: {err}", file=sys.stderr)
sys.exit(2)

# If success is true, parse the series for CARBON_INT_GB
rates = data.get("rates", {})
symbol = "CARBON_INT_GB"

series = rates.get(symbol)
# Some Energy endpoints embed a per-symbol time map; others return a point.
# Handle either without inventing structure:
if isinstance(series, dict):
# Expecting a dict like {"2026-01-01": 123.45, "2026-01-02": 110.32, ...}
# Units: gCO2/kWh for CARBON_INT_GB
ordered = sorted(series.items()) # sort by date ascending
for d, v in ordered:
print(f"{d},{v}") # CSV-friendly
else:
# If a single value is returned, you can log it with any provided date metadata.
point_value = series
dates_meta = (data.get("dates") or {}).get(symbol)
print(f"{dates_meta},{point_value}")

JavaScript (fetch) example

This JavaScript snippet performs the same request and illustrates robust handling of the empty-data envelope. It emits timeseries rows only when present.

const API_URL = "https://energy-api.com/api/v1/timeseries";
const params = new URLSearchParams({
start: "2026-01-01",
end: "2026-03-31",
symbols: "CARBON_INT_GB",
api_key: "YOUR_API_KEY",
});

async function run() {
const res = await fetch(`${API_URL}?${params.toString()}`, {
method: "GET",
});
const data = await res.json();

if (!data || data.success !== true) {
const msg = (data && data.error) ? data.error : "Unknown error";
console.error("No CARBON_INT_GB data:", msg);
return;
}

const symbol = "CARBON_INT_GB";
const series = (data.rates || {})[symbol];

if (series && typeof series === "object" && !Array.isArray(series)) {
// Assume a map of date -> value in gCO2/kWh
Object.keys(series).sort().forEach(d => {
console.log(`${d},${series[d]}`);
});
} else if (series !== undefined) {
const dmeta = (data.dates || {})[symbol] || "";
console.log(`${dmeta},${series}`);
} else {
console.warn("CARBON_INT_GB symbol missing in rates.");
}
}

run().catch(err => console.error(err));

Understanding fields and units when success is true

When data is available for CARBON_INT_GB within your requested window:

• rates.CARBON_INT_GB will hold the time-indexed values. Treat the key as an ISO date string and the value as a numeric gCO2/kWh measurement.
• currencies.CARBON_INT_GB will be present to indicate metadata about the series context. For CARBON_INT_GB, treat the effective “unit” as gCO2/kWh rather than a monetary currency.
• dates.CARBON_INT_GB can supply a date context (e.g., as-of date) for point results. For a full timeseries, parse the per-date keys within rates.CARBON_INT_GB.

Practical tip: always normalize dates to YYYY-MM-DD strings and store values as decimals with adequate precision for intensity data (e.g., to two decimal places, unless your application requires more granularity).

Date ranges, timezones, and missing days

Choose a start and end aligned to your backtesting interval. If you need monthly aggregates, request a daily series first and then aggregate downstream. The endpoint accepts calendar dates; you do not need to send time-of-day parameters for this symbol.

• Timezone: Treat date keys as local-calendar days for the series source unless the API returns explicit timezone offsets. Do not assume intraday granularity unless you see more detailed keys.
• Gaps: Some dates may be missing. Your code should not assume a fully dense series. Fill forward only if methodologically justified.
• Caching: Cache stable historical windows to reduce calls. On the 7-day trial (50 calls), batch date ranges where possible.

Error handling and retries

For the real-world envelope shown for CARBON_INT_GB, success is false and the error states that no rate data is available. Your client should:

• Check success first. If false, record data.error and stop parsing.
• Retry with an adjusted date range or at a later time if you expect the source to publish with delay.
• Alert only after a sensible threshold (for example, consecutive failures across multiple ranges) to avoid noise.

Do not fabricate values when the API returns no data. Your downstream systems should handle empty results explicitly (e.g., by skipping ingestion for that symbol-range combination).

Validation workflow: unit tests you can write today

Before wiring into production, add tests that assert:

• Given the official sample envelope (success true with unrelated symbol), your parser does not attempt to read OMIE_ES_DA when you asked for CARBON_INT_GB.
• Given the real CARBON_INT_GB error envelope, your client logs the error and returns an empty series.
• If a future successful CARBON_INT_GB response includes a per-date map in rates.CARBON_INT_GB, your client sorts dates and returns consistent numeric typing.

Operational hints that save time

• Backfills: Query broad ranges first (e.g., quarters) and then refine gaps with smaller windows to optimize call counts.
• Idempotency: Store a hash of the response payload per (start, end, symbols) to quickly detect when data changed.
• Schema evolution: Keep your parser tolerant to either a point value or a per-date map under rates.CARBON_INT_GB. Do not assume a single fixed shape.
• Units: CARBON_INT_GB is in gCO2/kWh. Do not apply currency conversions or a base parameter. The unit is an intensity, not a price.
• Multi-symbol queries: You can query multiple symbols by comma-separating them, but do not pass base=USD when you also need TTF_GAS or EUA_CO2.

Troubleshooting guide

• Received {"success":false,"error":"No rate data available for the requested symbols."}: Confirm your symbols=CARBON_INT_GB parameter and try an alternate date range known to have coverage.
• Unexpected fields or missing keys: Inspect the full JSON. Check success before reading rates, dates, or currencies.
• Units confusion: For CARBON_INT_GB, the value is gCO2/kWh. Never apply base currency or FX logic.
• High-latency windows: If the provider publishes with delay, schedule retries with exponential backoff.
• Quota planning: On trial (7 days / 50 calls), consolidate ranges and cache responses aggressively.

Putting it all together

To integrate CARBON_INT_GB into your analytics stack:

1. Register for an API key.
2. Call GET /api/v1/timeseries with start, end, symbols=CARBON_INT_GB, and api_key.
3. Check success. If false, log data.error and stop.
4. If success, read rates.CARBON_INT_GB (per-date map when present), sort by date, and persist the numeric values as gCO2/kWh.
5. Cache stable historical windows; schedule periodic refreshes for recent days if the source backfills.

FAQ

Q: What unit are CARBON_INT_GB values in?
A: gCO2/kWh. Treat values as emissions intensity, not currency. Do not attempt currency conversion.

Q: How do I authenticate?
A: Pass your key via the api_key query parameter. In all examples here, use YOUR_API_KEY and replace it locally with your credential.

Q: Why did I receive “No rate data available for the requested symbols.”?
A: The requested window may not have coverage, or publication is delayed. Verify symbols=CARBON_INT_GB and adjust your dates. Always check the success flag before parsing.

Q: Can I query multiple symbols together?
A: Yes, by comma-separating in symbols, but avoid passing base=USD when you also need TTF_GAS or EUA_CO2. For CARBON_INT_GB alone, no base is required.

Q: How should I store the series?
A: Normalize to YYYY-MM-DD and store numeric gCO2/kWh values. Keep your schema flexible to accept either a per-date map or a single point value.

Register and start querying

Get an API key and start making the same requests shown above. Use the 7-day trial to prototype, cache results, and wire your parser to handle empty-data envelopes cleanly. Create your account here: Register. For reference material and any nuances of fields or shapes, keep the docs handy: Documentation.