Historical Germany Carbon Intensity Prices

You need reliable, queryable historical carbon intensity for Germany that you can drop into a data pipeline, chart, or model. By the end of this guide you will be able to fetch and parse the Germany Carbon Intensity timeseries (symbol CARBON_INT_DE) from the Energy API using a reproducible curl call and a small Python script, understand the response shape (including error envelopes), and handle common edge cases like empty windows and unit checks.

What the Germany Carbon Intensity symbol represents

The Energy API exposes Germany’s grid carbon intensity under the following catalog entry:

• Symbol name: Germany Carbon Intensity
• Symbol code: CARBON_INT_DE
• Unit: gCO2/kWh

Carbon intensity expresses the grams of CO₂ emitted per kilowatt-hour of electricity generated. Because it is a physical intensity measure (not a price), you should not try to convert it with a monetary base or FX parameter. Keep it unit-stable and treat it like any other engineering timeseries.

Endpoint, method, and authentication

The historical timeseries is retrieved from a single endpoint:

• HTTP method: GET
• Path: /api/v1/timeseries
• Query parameters: start, end, symbols, api_key
• Auth: api_key query parameter (use YOUR_API_KEY; never store keys directly in client apps without vault/secret management)

Do not pass currency base parameters for this symbol. Specifically, do not add base=USD, and do not co-request TTF_GAS or EUA_CO2 with a conflicting base requirement. Keep the request focused and unit-consistent.

Plan note: Starter is $19.99/mo with a 7-day trial and 50 calls. To obtain an API key, create an account via the registration flow linked below.

Quickstart: copy-pasteable curl

Use this exact call to request CARBON_INT_DE over a fixed date window. Replace only the api_key value with YOUR_API_KEY (keep everything else as is). This is the official sample format for the timeseries endpoint:

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_DE" --data-urlencode "api_key=YOUR_API_KEY"

Tip: start and end are inclusive dates. Use calendar dates (YYYY-MM-DD). If you receive an empty or error response, first shrink the window to a few days and confirm symbol coverage before expanding further.

Response envelopes you will encounter

You will see two general classes of responses from the endpoint: a success envelope (with rates and optionally currencies) and an error envelope. Below are complete, copyable examples you can test your parser against.

Sample success envelope (generic structure)

This official sample shows a successful response format. The symbol in this sample is not CARBON_INT_DE; use it to understand field names and types only.

{
"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 notes you will actually use:

• success: Boolean gate for your parser. Always check this first.
• rates: Dictionary keyed by symbol. For timeseries windows, your integration should iterate over the time dimension as the API returns it and read values for rates.CARBON_INT_DE keyed by date.
• currencies: Meta field keyed by symbol. For CARBON_INT_DE, this is not a money series; still, the API may include a currency field for consistency across the catalog. Your logic should read currencies.CARBON_INT_DE but not attempt FX conversion.
• date/base/dates fields: The API may provide a reference date, map of per-symbol dates, and a base. Do not rely on base for unit scaling of CARBON_INT_DE; the unit is gCO2/kWh.

Sample error envelope (the live call did not succeed)

This is the real error envelope captured for the CARBON_INT_DE request window shown above. Use it verbatim in your tests and ensure your code surfaces the message to logs or users.

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

How to handle this in code:

• If success is false, do not attempt to access rates. Inspect error for routing (e.g., retry later, shrink date window, or check symbol availability).
• When building charts, gracefully display a “no data for this window” notice. Do not render zeroes as stand-ins.

Same error envelope repeated for validation testing

If you build contract tests, include the same error JSON to confirm your error-path logic is stable across retries and alternative date windows.

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

Error envelope for empty or unsupported ranges (use for negative tests)

Use the same canonical error body again to test parsing consistency when a user selects an unsupported historical span.

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

Python: end-to-end retrieval and parsing

This script calls the same endpoint, propagates query parameters, and implements robust handling of both success and error envelopes. Keep YOUR_API_KEY as the literal placeholder during local scaffolding.

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

API_URL = "https://energy-api.com/api/v1/timeseries"

def fetch_timeseries(start, end, symbols, api_key):
params = {
"start": start,
"end": end,
"symbols": symbols,
"api_key": api_key
}
url = API_URL + "?" + urllib.parse.urlencode(params)
req = urllib.request.Request(url, method="GET")
try:
with urllib.request.urlopen(req, timeout=30) as resp:
data = resp.read().decode("utf-8")
return json.loads(data)
except urllib.error.HTTPError as e:
sys.stderr.write(f"HTTPError: {e.code} {e.reason}\n")
raise
except urllib.error.URLError as e:
sys.stderr.write(f"URLError: {e.reason}\n")
raise

def main():
# Configure your window and API key
start = "2026-01-01"
end = "2026-03-31"
symbol = "CARBON_INT_DE"
api_key = "YOUR_API_KEY"

payload = fetch_timeseries(start, end, symbol, api_key)

# Always gate on success
if not payload.get("success", False):
# Matches the real envelope example:
# {"success":false,"error":"No rate data available for the requested symbols."}
err = payload.get("error", "Unknown error")
print(f"Timeseries request failed: {err}")
sys.exit(2)

# Success path: read by symbol and date
# The catalog guidance for timeseries is to read rates.CARBON_INT_DE keyed by date,
# plus currencies.CARBON_INT_DE if present.
rates = payload.get("rates", {})
currencies = payload.get("currencies", {})

# Guard for missing symbol
if symbol not in rates:
print(f"Symbol {symbol} not present in rates.")
sys.exit(3)

# Print the value(s) in a deterministic way. For multi-date windows,
# iterate whatever date keying the API returns for the symbol.
value = rates.get(symbol)
print(f"{symbol} value(s): {value}")

if symbol in currencies:
print(f"{symbol} currency meta: {currencies[symbol]}")

if __name__ == "__main__":
main()

Integration notes:

• Timeouts: 30s is usually sufficient for historical spans; adapt to your platform.
• Retries: Only retry idempotent GETs, and only when network errors occur. Do not hammer on application-level errors.
• Output handling: Do not coerce missing symbols into zeroes. Always gate on success.

Verifying units and avoiding currency pitfalls

The Germany Carbon Intensity series is in gCO2/kWh. It is not a price, so do not request a monetary base and do not mix it in a single call with monetary instruments that require base selection. The catalog explicitly warns: do not pass base=USD when you also need TTF_GAS or EUA_CO2. For CARBON_INT_DE alone, omit base entirely and read the numeric values as an intensity measure.

If the API includes a base or currency field in the envelope (e.g., base: EUR in generic samples), treat it as metadata that is irrelevant to the meaning of CARBON_INT_DE. Your parser should read currencies.CARBON_INT_DE without applying FX conversion or scaling.

Handling empty windows, data gaps, and caching

If you receive the “No rate data available for the requested symbols.” error, take these steps:

• Confirm the symbol is exactly CARBON_INT_DE.
• Reduce the date window to a few days to test availability.
• Adjust polling: do not retry aggressively on application-level “no data” errors. Log and notify instead.

Where to cache:

• Application cache: Cache successful envelopes keyed by (symbol, start, end) for short TTLs when building charts.
• Persistent store: If you are backfilling historical archives, persist raw JSON and a normalized table (date, symbol, value, unit).

Non-trading days concept: Electricity and carbon intensity data are generated continuously, but publication can be batched. Your pipeline should accept irregular timestamps and not assume strictly daily datapoints. When data for a window is missing, do not fill with zeros; either skip plotting or mark as missing.

End-to-end troubleshooting with concrete examples

Use the following canonical responses to exercise your error-path logging and UI feedback. These are the same complete bodies you will see from the API.

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

Pair this with your standard retry policy: network-level retries only; application-level errors should not be retried blindly. Provide a user-facing hint such as “Try a different date window.”

Practical field mapping for pipelines

When you normalize CARBON_INT_DE into a table or dataframe, target a simple schema:

• date: primary time index (string or date type in YYYY-MM-DD)
• symbol: CARBON_INT_DE
• value: numeric intensity in gCO2/kWh
• unit: “gCO2/kWh” (constant per row for this symbol)
• currency: optional; if present in the envelope, store but do not use for computations

Reading guide: The timeseries contract is that you read rates.CARBON_INT_DE keyed by date, plus currencies.CARBON_INT_DE. When present, also map date metadata from dates.CARBON_INT_DE.

Operational safeguards

• Input validation: Verify start <= end, both in YYYY-MM-DD.
• Symbol set: Keep the call to a single symbol until you confirm data flow. Add more symbols later if you need multi-instrument windows.
• Change monitoring: Alert if you observe a sudden absence of data in windows where it was previously available.
• Unit tests: Include fixtures for both a success envelope (use the official generic sample) and the real error envelope shown above.

FAQ

How do I authenticate?
Pass your key via the api_key query parameter. Use YOUR_API_KEY as the placeholder in templates and scripts you share internally.

What unit should I expect for CARBON_INT_DE?
gCO2/kWh. Do not attempt FX conversion; this is not a monetary series.

Why am I seeing “No rate data available for the requested symbols.”?
The requested window may not have coverage, or the symbol may be misspelled. Shrink the date range, verify the symbol is CARBON_INT_DE, and try again.

Can I request CARBON_INT_DE with TTF_GAS or EUA_CO2 in the same call?
Avoid combining symbols that require monetary base parameters. The catalog note states: Do not pass base=USD when you also need TTF_GAS or EUA_CO2. Keep CARBON_INT_DE requests base-less and unit-stable.

What plan do I need to get started?
Starter is $19.99/mo with a 7-day trial (50 calls). You can register and get an API key immediately.

Get a key and ship your integration. Create your account via Register, then review full parameter details and envelope fields in the Documentation.