Energy Latest API: Brent, TTF, and EUA as JSON

You need a single, reliable endpoint to fetch Brent crude oil, Dutch TTF natural gas, and EU carbon allowances in one call, and you need to ship it with correct currencies and dates. By the end of this guide, you’ll know exactly how to request the Energy API “latest” mix for BRENT_CRUDE, TTF_GAS, and EUA_CO2, parse the JSON, store prices and currencies correctly, and handle edge cases like missing symbols or success=false.

What you get from one request

The Energy API provides a one-shot “latest” endpoint that returns oil, gas, and carbon together. You’ll call GET /api/v1/latest with an api_key and the symbols you care about: BRENT_CRUDE, TTF_GAS, and EUA_CO2. From the response, you will read a success flag, an observation date, a set of prices (rates) keyed by symbol, and a set of currencies keyed by symbol. Store the rate and currency for each symbol together in your database.

If you need EUR-quoted instruments, leave base off the request. Adding base=USD can filter out EUR symbols. The live TTF_GAS currency in the sample response below is USD; a previous documentation mix from 2026-06-11 showed TTF in EUR (38.15). Always read currencies.* from the response you actually get, rather than hard-coding a currency assumption.

The one-call request for Brent, TTF, and EUA

Use the official request below to query BRENT_CRUDE, TTF_GAS, and EUA_CO2 in one call. Replace YOUR_API_KEY with your key.

curl "https://energy-api.com/api/v1/latest?symbols=BRENT_CRUDE,TTF_GAS,EUA_CO2&api_key=YOUR_KEY"

Live sample response and how to read it

The response below is from the live Energy-API print dated 2026-09-29 (not 1 October). Use the observation date in the payload for your own data freshness checks and cache keys.

{
  "success": true,
  "date": "2026-09-29",
  "base": "MIXED",
  "rates": {
    "BRENT_CRUDE": 113.96,
    "TTF_GAS": 17.93,
    "EUA_CO2": 77.163
  },
  "currencies": {
    "BRENT_CRUDE": "USD",
    "TTF_GAS": "USD",
    "EUA_CO2": "EUR"
  }
}

How to use the fields you’ll actually need:

success: Boolean that tells you if the call succeeded. If false, do not trust any rates; handle the error path (see “Errors and missing values” below).
date (or equivalent observation date field shown in your JSON): The observation date for these prices. Persist it alongside each symbol’s price and currency.
rates.* (per-symbol numeric values): The latest price for each requested symbol. Store and display them together with the correct currency.
currencies.* (per-symbol currency codes): The currency each symbol is quoted in for this response. Do not assume a currency; always read currencies.SYMBOL.
symbols or requested symbols listing (if present): Confirms which instruments were considered. If a symbol is not present in rates/currencies, treat it as unavailable for this print.

Note on TTF_GAS: In this live sample, the TTF_GAS currency is USD. Earlier documentation (2026-06-11) showed TTF at 38.15 EUR. Your integration should rely on currencies.TTF_GAS from the response you receive.

Quick start: go live in minutes

Step 1 — Register

Start a 7-day trial (Starter is $19.99/mo for 5,000 calls and 5 symbols; trial includes 50 calls). Sign up here: Register.

Step 2 — Copy your api_key

After confirming your account, copy your api_key from the dashboard.

Step 3 — Request Brent, TTF, and EUA

Call GET /api/v1/latest with symbols=BRENT_CRUDE,TTF_GAS,EUA_CO2. Do not add base if you need EUR-quoted symbols; a base=USD filter can drop them from the response.

Step 4 — Store rates and currencies

Persist both the numeric price and the currency for each symbol in your data store. Key your cache by symbol+date (and base, if you choose to add it later).

Copy-paste client example (Python)

This example sends the same request as above and captures the three fields you’ll use most often: success, rates, and currencies, plus the observation date. Replace YOUR_API_KEY with your own.

import os
import sys
import requests

API_KEY = os.getenv("ENERGY_API_KEY", "YOUR_API_KEY")
BASE_URL = "https://energy-api.com/api/v1/latest"

params = {
    "api_key": API_KEY,
    # Leave base off if you need potential EUR-quoted instruments preserved.
    "symbols": "BRENT_CRUDE,TTF_GAS,EUA_CO2",
}

try:
    resp = requests.get(BASE_URL, params=params, timeout=10)
    resp.raise_for_status()
except requests.RequestException as e:
    print(f"HTTP error calling Energy API: {e}", file=sys.stderr)
    sys.exit(1)

data = resp.json()

# Always check success first
if not data.get("success", False):
    # If available, inspect message or error details for logging
    print(f"Energy API returned success=false: {data}", file=sys.stderr)
    sys.exit(2)

# Read the observation date exactly as provided by the API
observation_date = data.get("date") or data.get("observation_date")

rates = data.get("rates", {})
currencies = data.get("currencies", {})

def pick(symbol):
    price = rates.get(symbol)
    ccy = currencies.get(symbol)
    if price is None or ccy is None:
        return None
    return {
        "symbol": symbol,
        "price": price,
        "currency": ccy,
        "date": observation_date,
    }

for sym in ["BRENT_CRUDE", "TTF_GAS", "EUA_CO2"]:
    entry = pick(sym)
    if entry is None:
        print(f"Missing data for {sym} on {observation_date}", file=sys.stderr)
    else:
        print(entry)

Handling currencies, units, and base

Each symbol carries its own currency in the response under currencies.*. For example, live TTF_GAS may be USD in one print and EUR in a different dataset snapshot. Your UI and database logic should treat currency as first-class data, never inferred.

Do not add base=USD if you need EUR instruments preserved. A base=USD filter can exclude EUR-quoted symbols.
Store both rate and currency per symbol per observation date. This makes audits and backfills straightforward when markets change quoting conventions.
Units: consume the symbols exactly as provided (BRENT_CRUDE, TTF_GAS, EUA_CO2). If you require conversion or normalization, do it downstream using the currency field you received.

Dates, timezones, and caching strategy

Use the observation date from the response as the single source of truth. In the live sample above, the date is 2026-09-29. Do not assume “current day” on your server is the same as the observation date; read and display the date from the payload.

Timezone: the API returns a single observation date; treat it as the canonical label for this price set in your system. If you localize for UI, still store the raw observation date you received.
Caching: cache by (symbol, observation-date). If your deploy consumes all three symbols together, you can also cache at the “mix” level keyed by (BRENT_CRUDE|TTF_GAS|EUA_CO2, observation-date).
Refresh cadence: re-request when you need the latest. If markets are closed or data hasn’t updated yet, the observation date may remain the same. Don’t overwrite newer data with older observations; compare dates.
Pagination: not applicable for /api/v1/latest. The endpoint returns the current mix in one payload.

Errors and missing values

Always check data.success. If it’s false, treat the response as unusable and surface an error in logs or monitoring. For symbol-level gaps, a symbol may be missing from rates or currencies. Handle that defensively:

Absent symbol in rates: treat as unavailable; keep the previous observation if your business rules allow, but never fabricate a price.
Absent symbol in currencies: do not display the rate without its currency. Suppress the value until currency is available.
Partial availability: it’s valid to receive BRENT_CRUDE and EUA_CO2 but not TTF_GAS for a given observation. Your code should skip only the missing symbol(s) and continue for the rest.

End-to-end integration checklist

Request GET /api/v1/latest with api_key and symbols=BRENT_CRUDE,TTF_GAS,EUA_CO2.
Leave base off if you require potential EUR-quoted instruments (a base=USD filter can drop them).
Check success. If false, stop and log.
Read the observation date from the payload. Persist it with each symbol.
For each symbol, store both rate and currencies.*[symbol]. Never assume the currency.
Cache by observation date to avoid clobbering newer data with older prints.

Going beyond Brent, TTF, and EUA

The same endpoint supports other products—wheat and gold among them—via the symbols parameter. If the official sample above shows a different instrument in any section, that’s only for demonstration; request BRENT_CRUDE, TTF_GAS, and EUA_CO2 exactly as shown in the request section to retrieve the energy mix in this article’s title.

Refer to the Documentation for full symbol coverage and any parameter details not covered in this quick-start.

FAQ

Q: How do I ensure TTF_GAS shows the right currency?
A: Always read currencies.TTF_GAS from the response you get. Do not hard-code USD or EUR. The live sample above shows USD for TTF_GAS; earlier documentation showed EUR. Your UI and storage should use the currency from currencies.* for each symbol.

Q: Should I add base=USD to normalize currencies?
A: Not if you need EUR-quoted instruments. A base=USD filter can drop them. The safest approach is to request without base and persist both rate and currency per symbol.

Q: What observation date should I display?
A: Display the date in the JSON payload. In the live sample, that’s 2026-09-29. Don’t substitute the server’s local date; use the API’s observation date for accuracy and cache keys.

Q: What if success=false or a symbol is missing?
A: If success=false, treat the entire payload as an error and stop. If a specific symbol is missing from rates or currencies, skip it for that observation and keep the others. Never display a rate without its matching currency.

Q: Can I fetch other commodities with the same call?
A: Yes. Add other products (for example wheat or gold) to the symbols parameter. Keep the same parsing logic: read success, observation date, rates.*, and currencies.* for each requested instrument.

Ready to pull the energy mix into your app? Start your 7-day trial and get your api_key here: Register. For parameter reference and symbol lists, see the Documentation.