Skip to main content
Every rejection carries a detail message that names the offending part of the request. This page lists them verbatim, with the fix. Test fixes safely with validate_only — full validation, nothing stored.

HTTP status codes

422 on POST /v1/forecasts

The series does not cover the delivery day. A normal day has 96 quarter-hours, the spring-forward day (last Sunday of March) has 92, the fall-back day (last Sunday of October) has 100. Build the count from the local Europe/Berlin day — the quickstart snippets do this correctly.
control_area must be one of 50Hertz, Amprion, TenneT, TransnetBWcase-sensitive, the German TSO names, not EIC codes — and the area must be active for your portfolio.
A series tagged with malo needs a matching entry in the request’s malo_mapping object: {"malo_mapping": {"<11 digits>": "<control area>"}}.
Each series carries exactly one tag: either control_area or malo — never both, never neither.
A market location ID (MaLo) is exactly 11 digits, sent as a JSON string (leading zeros matter).
kind takes only those two values (both series always positive — the bridge nets them); unit is MW (average power per quarter-hour, the default) or MWH (energy per quarter-hour).
delivery_day is YYYY-MM-DD (a Europe/Berlin calendar day), e.g. "2026-09-01" — no time component, no timezone suffix.

422 on master, metered and profile data

Metered days follow the same quarter-hour rule as forecasts: 96 / 92 / 100 values covering the whole local day.
Rolled-out profile days too: one values_kwh entry per quarter-hour of the local day.
A master-data slice with active: true (the default) must say where and how the location is metered. Only a de-registration slice (active: false) may omit them.
Slice windows are valid_from (inclusive) to valid_to (exclusive); an empty or negative window is rejected.
A location needs its history: either a slices array, or the flat shorthand with delivery_start (+ attributes) for one uninterrupted period.

Getting 401 although the key is right?

The two attempts we see most:
  1. The key sent as Authorization: <key> — plain keys go in the X-API-Key header; Authorization: Bearer … is only for OAuth tokens from a registered issuer.
  2. A trailing newline or quote copied along with the key. The key is used byte-for-byte.

Still stuck?

Send n:lead the timestamp of your call and, if you got one, the input_hash from the acknowledgment — both identify your request in the service’s audit trail without you having to share the payload.