Brent Timeseries API: Dated BRENT_CRUDE Window as JSON

You need a reliable way to pull a dated window of historical Brent crude prices as JSON so you can backtest models, power dashboards, or reconcile P&L. By the end of this article, you’ll know how to call the Energy API timeseries endpoint for BRENT_CRUDE, interpret the JSON, and safely integrate it into production workflows.

What you get from the BRENT_CRUDE timeseries API

The API returns a time-bounded JSON series for the BRENT_CRUDE symbol. It is designed for developers who need machine-readable daily values for analysis and applications. Energy maintains Brent as a headline (H1) symbol, so you can request it directly without mapping symbol lists.

Two call patterns matter:

Latest: get the most recent BRENT_CRUDE value (fastest, minimal payload).
Dated window: get a contiguous historical window for BRENT_CRUDE (backfills models, lets you chart or compute deltas).

This article focuses on the dated window but also shows the minimal latest read so you can verify your key and wiring in seconds.

Endpoint and authentication

The endpoint for both latest and dated window queries is a simple GET to the timeseries resource. You pass your API key in the query string and select the symbol BRENT_CRUDE via the symbols parameter.

Method: GET
Path: /api/v1/timeseries
Required query params:
- api_key: your account key
- symbols: BRENT_CRUDE

Energy owns both Brent and TTF as top-level symbols. This post stays on Brent, but one practical note if you ever combine it with TTF_GAS: do not force base=USD in those mixed calls, as the base may be MIXED.

Requesting a Brent window

Here is the official window request. Use it to see which date parameters to pass and in what format; you can drop it straight into your terminal and swap YOUR_API_KEY with the key from your account.

curl "https://energy-api.com/api/v1/timeseries?symbols=BRENT_CRUDE&start_date=2026-06-01&end_date=2026-06-11&api_key=YOUR_API_KEY"

That request returns a JSON object with a success flag and one or more dated entries for BRENT_CRUDE. Keep reading for details on fields and how to read them robustly in code.

Minimal “latest Brent” sanity check

Before you wire up pagination or caching strategies, confirm that your API key is valid and that you can read the latest BRENT_CRUDE record. This is helpful to validate credentials and networking quickly.

curl -s "https://energy-api.com/api/v1/timeseries?symbols=BRENT_CRUDE&api_key=YOUR_API_KEY"

In this latest-style read the object typically includes a latest snapshot you can reach under a rates map. You will read rates.BRENT_CRUDE from the latest payload. Once that works, move on to your dated-window requests for full history.

Official sample response to learn the JSON shape

The following is an official sample of a latest JSON payload from the same endpoint. It is not the Brent window; use it to understand the response structure and field names. We will point out how it maps to BRENT_CRUDE immediately after it.

{
  "success": true,
  "date": "2026-06-11",
  "base": "MIXED",
  "rates": {
    "BRENT_CRUDE": 74.82,
    "TTF_GAS": 38.15,
    "EUA_CO2": 67.40,
    "OMIE_ES_DA": 82.30
  }
}

How to read it (and how to adapt it to BRENT_CRUDE)

Use this sample to identify the keys your code should safely access:

success: Boolean flag you must check before using any numeric values.
rates: A map of symbol-to-value for the timestamped payload. In your Brent integration, read rates.BRENT_CRUDE for the number you need.
Any date or timestamp fields: Capture them as your time axis or cache key. Do not coerce them into a different timezone unless you have a domain reason to do so.

If you see a different symbol in the sample, that’s expected: the sample illustrates the “latest” shape from the same endpoint, while your integration will call it with symbols=BRENT_CRUDE to get the Brent values this article focuses on.

Code: request a Brent window and parse the JSON

You’ll typically loop through a dated window result and map date → value for BRENT_CRUDE. The following example shows a production-friendly fetch in Python that calls the same endpoint and reads the fields you’ll use. Adapt the date parameters to match the official window request above.

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

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

def get_brent_window(query_params):
    # query_params should include any window/date params shown in the official request
    params = {"symbols": "BRENT_CRUDE", "api_key": API_KEY}
    params.update(query_params)
    url = BASE_URL + "?" + urllib.parse.urlencode(params)
    with urllib.request.urlopen(url) as resp:
        data = json.loads(resp.read().decode("utf-8"))
        return data

def extract_series(payload):
    # Always check success; bail out early on failures
    if not payload or not payload.get("success", False):
        # Avoid using possibly stale or partial data
        raise RuntimeError("Energy API returned success=false or empty payload")

    # Many timeseries responses include either:
    # - a 'rates' object for the latest snapshot, or
    # - a collection of dated entries (e.g., a 'series' or date-keyed object).
    # Use a defensive approach that works for both.
    series = []

    # 1) Try a date-keyed structure first (e.g., payload.get("data") or payload.get("series")).
    # We do not assume exact field names; inspect keys and collect date/value pairs for BRENT_CRUDE.
    for key, value in payload.items():
        if isinstance(value, dict) and key not in ("rates",):  # exclude latest map
            # If the nested dict contains BRENT_CRUDE, record it as a time point.
            if "BRENT_CRUDE" in value:
                series.append((key, value["BRENT_CRUDE"]))

    # 2) If you only got a latest snapshot, fallback to a single-point series from 'rates'.
    if not series and isinstance(payload.get("rates"), dict) and "BRENT_CRUDE" in payload["rates"]:
        series.append(("latest", payload["rates"]["BRENT_CRUDE"]))

    return sorted(series, key=lambda x: x[0])

if __name__ == "__main__":
    # Replace with the date window params that appear in the official window request
    query = {
        # e.g., "start_date": "YYYY-MM-DD",
        #       "end_date": "YYYY-MM-DD"
    }
    try:
        payload = get_brent_window(query)
        brent_series = extract_series(payload)
        for ts, val in brent_series:
            print(f"{ts}\t{val}")
    except Exception as e:
        print(f"Error: {e}", file=sys.stderr)
        sys.exit(1)

Notes on the example:

It checks success before reading any numeric field.
It handles both a dated window and a latest snapshot by design, so you can reuse the same code for ad-hoc reads.
Keep your API key outside source control; the example looks for ENERGY_API_KEY and falls back to YOUR_API_KEY for quick trials.

Data semantics: what the Brent number represents

When you inspect the official latest sample above, you will see that the Brent number in that payload is referenced as an EIA/FRED Europe spot measure, not an ICE futures print. This matters for model alignment and comparability. If your downstream code expects futures settlements, do not substitute spot values; and vice versa, do not backfill a spot timeseries with front-month futures.

Handling errors, gaps, and missing values

Build against real-world conditions and treat data robustness as a first-class concern:

success=false: Always check the success flag. If it is false, do not use partial values. Log the response and short-circuit the pipeline. Consult the Documentation for error semantics.
Empty or missing BRENT_CRUDE values: In a dated window, a day might be absent or the symbol might not be present for a key. Treat absent keys as missing data rather than zeros. If you must fill gaps, prefer explicit imputation (e.g., last observation carried forward) at the application layer and annotate those fills.
Partial days: When you process a window that includes the current day, you may see provisional or not-yet-final values. If you require finalized numbers, avoid querying “today” until your SLA window closes.

Units, base currency, and mixed bases

BRENT_CRUDE is delivered as a top-level symbol that you can query directly. The payload may carry a base currency context depending on the symbols you request together. If you only request BRENT_CRUDE, you will typically work in the natural base for that series. If you request Brent alongside gas (for example, TTF_GAS), do not pass base=USD; a mixed-symbol call can legitimately return a MIXED base. Handle mixed bases explicitly in your code rather than coercing them at request time.

If you require downstream normalization (e.g., converting to a portfolio base currency or unit), do that transformation after you read the JSON, and preserve the original series in logs or durable storage for auditability.

Dates, timezones, and windows

The timeseries endpoint delivers values keyed by date for the dated window, and a single “latest” snapshot for the minimal query. Consider these practices:

Do not assume an intraday timestamp when you receive date-only keys; treat them as daily observation dates.
If you need a specific timezone representation in your database, convert dates after ingest and retain the original date string for reference.
Non-trading days: Energy series can legitimately skip weekends or holidays, depending on the underlying methodology. If a date is missing, do not generate synthetic entries unless your analytics explicitly require a dense index.

Caching, retries, and quotas

Practical tips to keep your integration fast and economical:

Cache historical windows aggressively. Historical observations do not change often; you can store windows by start/end parameters and refresh periodically.
Avoid refetching the same window inside tight loops. Batch your reads and stream-process the payload into your time-series store.
Retry policies: Implement idempotent retries on network timeouts. Avoid retry storms; back off exponentially and cap attempts.
Plan tier: The Starter plan is $19.99/mo and includes 5,000 calls and 5 symbols, with a 7-day trial / 50 calls. Use the trial to validate your window logic before you move to production.

Going live in four steps

Register for an account — 7-day trial / 50 calls.
Copy your api_key from the dashboard.
GET /api/v1/timeseries with symbols=BRENT_CRUDE (use your window parameters as in the official request above).
Read rates.BRENT_CRUDE on the latest response, and parse the dated entries for your window payload.

Production checklist

Authentication: api_key in the query string. Store it securely out of source control.
Symbol: BRENT_CRUDE for this integration. Avoid mixing with other symbols until your code handles mixed bases.
Window parameters: Use exactly the date fields shown in the official request block above. Treat responses as daily values.
Field access:
- Check success before reading any values.
- For latest reads: use rates.BRENT_CRUDE.
- For windows: iterate the dated entries and pull BRENT_CRUDE per date.
Data meaning: Brent in the official latest sample is an EIA/FRED Europe spot measure. Don’t substitute it for futures settlements in your models.
Error handling: Stop on success=false; log the payload; avoid using partial data.
Caching: Cache windows and refresh on a schedule. Do not hammer the endpoint for historical days.

FAQ

How do I request a historical window for BRENT_CRUDE?
Use the timeseries endpoint with BRENT_CRUDE and include the date-range parameters shown in the official window request above. Keep the method as GET and pass your api_key in the query string.

Why does the official JSON sample not show a Brent window?
The sample illustrates a “latest” payload from the same endpoint and not the window. It teaches you the JSON structure (success, rates, timestamp/date fields). To get BRENT_CRUDE specifically, call the endpoint with symbols=BRENT_CRUDE as shown in the requests here.

What does rates.BRENT_CRUDE represent?
It is the BRENT_CRUDE value in the returned payload. In the official latest sample, Brent reflects an EIA/FRED Europe spot series, not an ICE futures print. Use the correct series for your application.

Can I force base=USD when requesting BRENT_CRUDE together with TTF_GAS?
Do not pass base=USD for mixed Brent + TTF calls. The base may be MIXED when combining symbols with different native bases; handle that explicitly after ingest.

How should I handle missing dates in the window?
Treat absent dates as missing, not zeros. If your app needs a dense index, impute at the application layer (e.g., carry-forward) and record the fact you imputed the value.

Pull a Brent window now, wire up your parser, and ship your integration. If you’re not set up yet, start with the 7-day trial and 50 calls to validate your pipeline: Register. For endpoint specifics and payload fields, keep the Documentation open while you implement.