API to Get the Portugal OMIE Day-Ahead Price

You need a reliable way to fetch the Portugal OMIE day-ahead power price for finance workflows like risk reporting, PnL explain, and hedging decisions. By the end of this guide you will be able to request the Portugal OMIE Day-Ahead price via a single GET call, parse the response fields you actually need, and integrate the values into your finance stack.

What you will query: Portugal OMIE Day-Ahead (OMIE_PT_DA)

The Energy API exposes the Portugal OMIE Day-Ahead price under a single symbol:

Illustration: API to Get the Portugal OMIE Day-Ahead Price

Symbol name: Portugal OMIE Day-Ahead
Symbol code: OMIE_PT_DA
Unit: EUR/MWh

For finance use cases, you should treat this as a daily settlement-style reference for Portuguese day-ahead power. The endpoint you’ll call returns the latest available value and accompanying metadata fields you can use to validate currency and date alignment in your financial models.

Authentication, access, and plan notes

Authentication is passed via the api_key query parameter. Use the placeholder value YOUR_API_KEY while testing your code; replace with your real key in production. There is a starter plan ($19.99/mo) with a 7-day trial and 50 calls to let you wire up and validate your integration end-to-end without friction.

When you are ready, start by creating an account and key:

For more details about parameters and fields, keep the docs handy as you read:

Documentation

Make your first request with curl

This is the fastest way to confirm your key and verify the response structure for the Portugal OMIE day-ahead symbol. Copy-paste, run, and check return fields.

cURL:

curl -G "https://energy-api.com/api/v1/latest" --data-urlencode "symbols=OMIE_PT_DA" --data-urlencode "api_key=YOUR_API_KEY"

Understand the JSON response you will parse

The response contains a few core fields that matter for finance applications:

base: the reporting base for the response. It can be a currency code or the string MIXED. You should not force base into another currency here; instead, read the symbol’s own currency from currencies.<symbol> and convert externally if needed.
rates.OMIE_PT_DA: the numeric price for Portugal OMIE Day-Ahead, denominated in EUR/MWh.
dates.OMIE_PT_DA: the date associated with the rate. Use this to align with your valuation date.
currencies.OMIE_PT_DA: the per-symbol currency code, which for OMIE_PT_DA is EUR.

Here are complete, copy-pasteable JSON response examples you can use to test your parser and unit tests.

Example A: Real response (Portugal OMIE Day-Ahead)

{"success":true,"date":"2026-10-30","base":"EUR","rates":{"OMIE_PT_DA":249.2745},"dates":{"OMIE_PT_DA":"2026-10-30"},"currencies":{"OMIE_PT_DA":"EUR"},"base_filter_note":null,"missing_symbols":null}

Field usage notes:

Use rates.OMIE_PT_DA as the numeric price (EUR/MWh).
Use dates.OMIE_PT_DA to time-stamp your finance entries and daily positions.
Use currencies.OMIE_PT_DA to verify the currency. For OMIE_PT_DA this is EUR.
base is EUR in this example. In mixed requests (multiple unrelated symbols), base may be MIXED. Always read per-symbol currency.

Example B: The same real response, pretty-printed for readability

{
"success": true,
"date": "2026-10-30",
"base": "EUR",
"rates": {
"OMIE_PT_DA": 249.2745
},
"dates": {
"OMIE_PT_DA": "2026-10-30"
},
"currencies": {
"OMIE_PT_DA": "EUR"
},
"base_filter_note": null,
"missing_symbols": null
}

Example C: Official sample response format (different symbol for demonstration)

This official format sample shows the same structure you will parse. Note the symbol here is OMIE_ES_DA; in your Portugal integration, you will read OMIE_PT_DA the same way.

{
"success": true,
"date": "2026-10-30",
"base": "EUR",
"rates": {
"OMIE_ES_DA": 244.689
},
"dates": {
"OMIE_ES_DA": "2026-10-30"
},
"currencies": {
"OMIE_ES_DA": "EUR"
},
"base_filter_note": null,
"missing_symbols": null
}

Python example: request and parse OMIE_PT_DA for finance workflows

This short Python snippet calls the same endpoint, extracts the price, date, and currency, and prints them for downstream use in PnL or valuation code. You can swap print with logging, persistence, or a call into your analytics layer.

Python:

import requests
from decimal import Decimal

API_URL = "https://energy-api.com/api/v1/latest"
API_KEY = "YOUR_API_KEY"
SYMBOL = "OMIE_PT_DA"

params = {
"symbols": SYMBOL,
"api_key": API_KEY
}

resp = requests.get(API_URL, params=params, timeout=10)
resp.raise_for_status()
data = resp.json()

if not data.get("success", False):
raise RuntimeError("API indicated failure")

# Read fields you will actually use
base = data.get("base")
rate = Decimal(str(data["rates"][SYMBOL]))
rate_date = data["dates"][SYMBOL]
ccy = data["currencies"][SYMBOL]

# Finance-ready printout
print(f"Symbol: {SYMBOL}")
print(f"Price: {rate} {ccy}/MWh")
print(f"Valuation date: {rate_date}")
print(f"Response base: {base}")

# Guardrails you may want in production
if base == "MIXED":
# Always rely on per-symbol currencies[...] for correct currency context
pass

# Example: emit a dict you might serialize to your pricing store
record = {
"symbol": SYMBOL,
"price": float(rate), # or keep Decimal if your DB supports it
"currency": ccy,
"unit": "EUR/MWh",
"valuation_date": rate_date,
"source_base": base
}
print(record)

Finance-grade parsing: rates, dates, currencies, and base

For daily valuation and risk workflows, it is best practice to:

Read and persist rates.OMIE_PT_DA exactly as provided. Store as Decimal or high-precision numeric to avoid rounding issues in PnL and VAR calculations.
Treat dates.OMIE_PT_DA as the valuation date for this daily price. Align all datasets to this same calendar date before aggregating portfolio views.
Rely on currencies.OMIE_PT_DA to confirm the price currency (EUR). Do not infer currency from base.
Use base as a response-level context only. If base is MIXED (e.g., in cross-asset symbol queries), continue using the per-symbol currencies[...] mapping for correct conversions.

Important: Do not pass base=USD when you also need TTF_GAS or EUA_CO2. For OMIE_PT_DA on its own, you generally do not need base overrides at all. If you must compute cross-currency values (e.g., EUR to USD in your portfolio), do the FX conversion in your own pipeline using a vetted FX source that matches your firm’s accounting policies.

Scheduling, timezone, and non-trading days

OMIE day-ahead prices reflect the day-ahead power market and are published daily. In finance systems, treat these as daily reference marks. When a calendar day is missing (e.g., due to holidays), your loader should detect a stale dates.OMIE_PT_DA and decide whether to carry forward, suppress PnL moves, or flag incomplete marks according to your internal controls.

Timezone handling: normalize the incoming dates to your financial system’s canonical timezone. The response provides dates as plain dates, which is straightforward for end-of-day processing. If your system expects UTC datetimes, store a canonical midnight timestamp with the date component of dates.OMIE_PT_DA.

Caching: for stable day-ahead data, it is typical to cache the response for one processing cycle to avoid redundant requests. If you run intraday reconciliation, re-request only when you detect a date boundary or when your governance rules demand a refresh.

Error handling and production hardening

Consider these checks before you write the record:

HTTP status: ensure 200-range response and raise on others.
Body success flag: data.success should be true.
Missing symbols: verify data.missing_symbols is null to confirm symbol presence.
Nulls and types: validate that rates.OMIE_PT_DA and dates.OMIE_PT_DA exist and are the expected types. Convert strings to Decimal early to avoid float rounding artifacts.
Idempotency: store records keyed by symbol + valuation_date to prevent duplicates if your loader retries.

Validation examples you can paste into tests

Use the following complete responses to build deterministic parsers and unit tests. They mirror the exact field names you will encounter in production.

Test Fixture 1: Portugal OMIE Day-Ahead (compact)

{"success":true,"date":"2026-10-30","base":"EUR","rates":{"OMIE_PT_DA":249.2745},"dates":{"OMIE_PT_DA":"2026-10-30"},"currencies":{"OMIE_PT_DA":"EUR"},"base_filter_note":null,"missing_symbols":null}

Test Fixture 2: Portugal OMIE Day-Ahead (pretty)

{
"success": true,
"date": "2026-10-30",
"base": "EUR",
"rates": {
"OMIE_PT_DA": 249.2745
},
"dates": {
"OMIE_PT_DA": "2026-10-30"
},
"currencies": {
"OMIE_PT_DA": "EUR"
},
"base_filter_note": null,
"missing_symbols": null
}

Test Fixture 3: Official sample format (for parser resilience)

{
"success": true,
"date": "2026-10-30",
"base": "EUR",
"rates": {
"OMIE_ES_DA": 244.689
},
"dates": {
"OMIE_ES_DA": "2026-10-30"
},
"currencies": {
"OMIE_ES_DA": "EUR"
},
"base_filter_note": null,
"missing_symbols": null
}

Working with multiple symbols and base=MIXED

Although this guide focuses on OMIE_PT_DA alone, finance teams often run multi-instrument loaders. In such cases, the response base may be MIXED. The safe approach is:

Always read currencies.<symbol> to confirm currency for each instrument.
Never rely on base to imply a per-symbol currency; use it only as a high-level descriptor.
Perform currency conversion explicitly in your valuation stack if needed, using your house FX sources and calendars.

This keeps your marks auditable and avoids silent currency drift.

Operational checklist for finance integration

Endpoint: GET /api/v1/latest
Query parameters: symbols=OMIE_PT_DA, api_key=YOUR_API_KEY
Primary fields to persist: rates.OMIE_PT_DA, dates.OMIE_PT_DA, currencies.OMIE_PT_DA
Unit: EUR/MWh (do not downcast or convert unless your downstream requires it)
Calendar: treat as daily; handle holidays/missing days per policy
Caching: cache within a processing cycle; refresh on date change
Retry strategy: retry transient network errors; guard against duplicate inserts
Monitoring: alert if success=false, missing_symbols not null, or dates drift

FAQ

Q: Which fields should I use to book the daily price in my finance system?
A: Use rates.OMIE_PT_DA for the numeric price, dates.OMIE_PT_DA for the valuation date, and currencies.OMIE_PT_DA to confirm the currency (EUR). Persist these three fields along with the symbol code for traceability.

Q: How do I handle currency if I need USD PnL?
A: The symbol is quoted in EUR/MWh. Keep the raw EUR price and apply your firm’s FX conversion in your valuation layer. Do not pass base=USD when you also need TTF_GAS or EUA_CO2; rely on per-symbol currencies and convert externally.

Q: Does this endpoint paginate or return historical data?
A: The endpoint shown retrieves the latest value. For historical use, consult the Documentation and choose the appropriate method for your backfill or time-series use case.

Q: How can I confirm I am not missing the daily mark on holidays?
A: Compare dates.OMIE_PT_DA to your expected business calendar. If the date is unchanged when you expect a new mark, follow your firm’s policy: carry forward, mark stale, or block downstream PnL until a fresh value appears.

Q: What is the unit and how should I store it?
A: The Portugal OMIE Day-Ahead price is in EUR/MWh. Store both the numeric price and the unit in your instrument metadata or price table so your analytics always apply the correct assumptions.

Get your key and ship your first integration

You now have a working curl request, a concise Python example, and several complete JSON responses to drive parsing and tests. Create your account, grab your key, and wire OMIE_PT_DA into your daily finance pipeline: