Historical Italy Carbon Intensity Prices

You need reliable, queryable historical carbon intensity data for Italy to power dashboards, emissions reporting, or automated analytics. By the end of this guide you will be able to request the Italy Carbon Intensity timeseries using the Energy API, handle success and error envelopes, parse the response in code, and ship an integration that respects units, authentication, and catalog nuances.

What the Italy Carbon Intensity symbol represents and how to access it

This guide focuses on a single Energy API symbol:

Illustration: Historical Italy Carbon Intensity Prices

Symbol name: Italy Carbon Intensity
Symbol code: CARBON_INT_IT
Unit: gCO2/kWh

The Energy API exposes a timeseries endpoint where you pass a start date, end date, and one or more symbols. Authentication uses an api_key query parameter. Do not add extraneous parameters that are not in the documentation. In particular, do not pass base=USD when you also need TTF_GAS or EUA_CO2 in the same request; keep your query minimal and specific to the symbols you need.

Plan note: Starter $19.99/mo, trial 7 days / 50 calls. You can create an account here: Register. Reference docs are available at: Documentation.

Endpoint, parameters, and request shape

Use GET /api/v1/timeseries with URL-encoded query parameters:

start: inclusive ISO date (YYYY-MM-DD)
end: inclusive ISO date (YYYY-MM-DD)
symbols: one or more comma-separated symbols; use CARBON_INT_IT for Italy Carbon Intensity
api_key: your API key (use the literal YOUR_API_KEY in examples; replace with your real key in production)

The response is a JSON envelope. You will read dates and values for your symbol from the rates and currencies objects. For carbon intensity, values are in gCO2/kWh. When available, dates are keyed at the granularity the API serves (typically daily if the catalog lists daily availability). If the symbol is temporarily unavailable or retired, the endpoint returns a structured error envelope.

Make your first request (copy-paste cURL)

Below is the official, copy-pasteable cURL request against the live endpoint. Replace YOUR_API_KEY with your own key. This request is constrained to a Q1 2026 window and requests the Italy Carbon Intensity symbol only.

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

If you are testing from a CI job or secured environment, ensure your networking allows outbound TLS to energy-api.com and that your process does not log the raw api_key to stdout/stderr.

Understanding responses: success vs. error envelopes

There are two response patterns to plan for: a success envelope with rates and currencies, and a structured error envelope if the symbol is unavailable or parameters are invalid.

Official sample success envelope (schema example)

This official example shows the envelope fields you should expect on success. The symbol in the example is different (OMIE_ES_DA) and provided only to demonstrate structure and field names; do not infer Italy Carbon Intensity values from it. Your parser should not hardcode symbol names.

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

Field usage notes for your integration:

success: boolean flag; check this first.
date: server date of the snapshot or calculation.
base: base currency when applicable to price series. For carbon intensity, treat values as gCO2/kWh; do not attempt FX conversion.
rates: mapping from symbol to the numeric value. When you request CARBON_INT_IT, read rates.CARBON_INT_IT.
dates: mapping from symbol to the value date.
currencies: mapping from symbol to the currency or unit. For CARBON_INT_IT, interpret as the unit context (gCO2/kWh).
base_filter_note: nullable field; can convey notes about base filtering when relevant.

Real API response for CARBON_INT_IT at the time of writing

The live call did not succeed for the requested symbol. You should detect and surface this cleanly in your pipeline and, if needed, check the symbol catalog endpoint /api/v1/symbols for current availability.

{"success":false,"error":"Symbol CARBON_INT_IT is not currently available. See \/api\/v1\/symbols for the current catalog."}

In this case, do not attempt to parse rates or currencies. Instead, branch your logic to notify upstream code or operators that the symbol is not currently available and possibly retry only after verifying catalog status.

Schema example duplicated for validation tests

If you are writing unit tests for your parser, you can validate against the official success envelope structure (even though the symbol differs). Keep this block unmodified if you use it as a fixture.

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

Python example: fetch, validate, and parse CARBON_INT_IT

The following Python snippet calls the same endpoint, validates success, and shows how you would read the symbol value and unit when available, and how to handle the current unavailability error.

import os
import sys
import json
from urllib.parse import urlencode
from urllib.request import urlopen, Request
from urllib.error import HTTPError, URLError

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

def fetch_timeseries(start_date, end_date, symbol, api_key):
params = {
"start": start_date,
"end": end_date,
"symbols": symbol,
"api_key": api_key
}
url = f"{API_URL}?{urlencode(params)}"
req = Request(url, headers={"Accept": "application/json"})
try:
with urlopen(req, timeout=30) as resp:
raw = resp.read().decode("utf-8")
data = json.loads(raw)
return data
except HTTPError as e:
sys.stderr.write(f"HTTPError: {e.code} {e.reason}\n")
raise
except URLError as e:
sys.stderr.write(f"URLError: {e.reason}\n")
raise

def main():
# Replace YOUR_API_KEY with your actual key when running locally/prod
api_key = "YOUR_API_KEY"
symbol = "CARBON_INT_IT"
start_date = "2026-01-01"
end_date = "2026-03-31"

data = fetch_timeseries(start_date, end_date, symbol, api_key)

# Branch on success flag
if not isinstance(data, dict):
print("Unexpected response type")
sys.exit(1)

if not data.get("success", False):
# Expecting: {"success":false,"error":"..."}
error_msg = data.get("error", "Unknown error")
print(f"API reported error for {symbol}: {error_msg}")
# Optionally instruct operator to re-check /api/v1/symbols
sys.exit(2)

# When success == True, parse fields
# Note: For CARBON_INT_IT, read these keys when the symbol is available.
rates = data.get("rates", {})
dates = data.get("dates", {})
currencies = data.get("currencies", {})

if symbol not in rates:
print(f"No rate present for {symbol} in the response.")
sys.exit(3)

value = rates[symbol]
value_date = dates.get(symbol)
unit = currencies.get(symbol) # For CARBON_INT_IT, interpret as gCO2/kWh

print(f"{symbol} value: {value} on {value_date} ({unit})")

if __name__ == "__main__":
main()

Implementation notes:

Use the success boolean to branch early. Do not assume rates is present when success is false.
Timeouts and retries should be tuned to your environment. Avoid aggressive retry loops against error envelopes that indicate catalog unavailability; first confirm symbol status.
Cache responses per date range if you run repeated backfills; daily carbon intensity does not change retroactively in most workflows, but always follow your compliance rules.

Operational considerations: ranges, units, and resilience

Ranges and batching:

Choose start and end windows that match your reporting cadence. For quarterly reports, month or quarter windows are typical.
If you need multi-year backfills, split the work into contiguous windows to simplify retries and caching. The endpoint supports explicit start and end dates; do not assume implicit defaults.

Units and interpretation:

For CARBON_INT_IT, values are in gCO2/kWh. These are not monetary prices; avoid currency conversions and leave the base field untouched.
When combining this series with price or fuel symbols (e.g., Brent or TTF gas), never pass a base=USD filter together with TTF_GAS or EUA_CO2 in the same request. Keep separate calls per analytical stream to avoid unintended filtering.

Resilience and symbol lifecycle:

The error envelope shown above indicates that CARBON_INT_IT is not currently available. Before building alerts, consult the symbols catalog at /api/v1/symbols to verify availability and any renames or deprecations.
Guard your downstream transforms so an unavailable symbol does not crash batch runs. Prefer a soft failure with explicit error propagation and observability hooks.

Testing your integration with known responses

When you wire up parsers, use the official sample envelope to validate structure handling and ensure you decode top-level fields consistently. Keep logic data-driven by symbol keys so the same parser works when CARBON_INT_IT is available again.

Official sample JSON (useful as a parser fixture)

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

Real error envelope (current CARBON_INT_IT status)

{"success":false,"error":"Symbol CARBON_INT_IT is not currently available. See \/api\/v1\/symbols for the current catalog."}

Troubleshooting and edge cases

Common issues and mitigations:

Symbol not found or unavailable: As shown in the real response, treat this as a controlled, non-retryable error until you verify the catalog. If you rely on the symbol for SLAs, add a pre-flight catalog check to your pipeline.
Empty or partial windows: If you query a window that predates the symbol’s coverage, expect sparse or empty results (when available). Code defensively by checking for the presence of your symbol in rates and dates maps.
Timezone and dating: The envelope includes date fields by symbol. Align your reporting pipeline to use those symbol dates as authoritative. If your warehouse stores timestamps, normalize to UTC midnight for the symbol’s date to maintain idempotency.
Caching: Cache successful envelopes per (start, end, symbol set). In batch backfills, this saves calls and avoids rate-limit pressure during the trial (7 days / 50 calls) and Starter usage.

Observability tips:

Log the top-level success flag, the requested symbol set, and any error text verbatim for postmortems.
Emit metrics for request latency and the count of symbols missing from the rates map when success is true.

FAQ

Q: What symbol and unit should I use for Italy’s carbon intensity?
A: Use the symbol code CARBON_INT_IT. Values are in gCO2/kWh.

Q: How do I authenticate?
A: Pass your key via the api_key query parameter. In examples, use YOUR_API_KEY; replace it with your real key in production.

Q: Do I need a base currency for carbon intensity?
A: No. Carbon intensity is not a monetary series. Do not pass base=USD when mixing with energy price symbols like TTF_GAS or EUA_CO2; keep requests separate.

Q: What if the symbol is unavailable?
A: The API will return a structured error envelope (see above). Do not parse rates or currencies. Check /api/v1/symbols for the latest catalog and adjust your pipeline if the symbol is renamed or paused.

Q: Can I query multiple symbols at once?
A: Yes, pass a comma-separated symbols list. However, keep CARBON_INT_IT queries distinct if you need strict unit handling and want to avoid base filters that apply to price series.

Register and start integrating

Sign up to obtain your API key, run the cURL request immediately, then wire the Python sample into your pipeline. Starter $19.99/mo with a 7-day trial and 50 calls lets you validate quickly. Create your account here: Register. For endpoint details and field definitions, see the Documentation.