Before you start
You need your API key, provided by n:lead. It goes into the
X-API-Key header of every request.
Developing? Ask n:lead for a sandbox key: same endpoints, same
payloads, same error messages — but the service stores nothing and
nothing can reach the market, no matter what you send. Swap in the
production key when you go live.
Keep the base URL in configuration rather than in code: it is a
platform-generated hostname today and will be replaced by a custom domain.
Step 1 — build a valid payload
One value per quarter-hour, from local midnight to local midnight
(Europe/Berlin): 96 values on a normal day, 92 on the
spring-forward day, 100 on the fall-back day. Production and
consumption are separate series, tagged per control area
(50Hertz, Amprion, TenneT, TransnetBW — case-sensitive).
The snippets below are complete and runnable — they build a correctly
sized payload including the DST edge cases:
Step 2 — validate without submitting
Add "validate_only": true and the service runs every check — interval
count, control areas, MaLo mapping, units — computes the totals, and
stores nothing. Nothing reaches the market. This is the safe way to
test your integration against the live service:
"status": "validated" means the same payload without the flag will be
accepted — the input_hash is even identical. A 422 instead? The
detail message names the series and the rule; every message is listed
with its fix on the troubleshooting page.
Step 3 — submit for real
Drop the flag (or set it false) and send:
The acknowledgment now reads "status": "received". The daily totals are
your plausibility check — if they look wrong, the submitted series are
wrong. The input_hash identifies exactly this submission; quote it if
you need to ask about a delivery day.
To see what the service holds, read it back at any time:
The read-back returns exactly the series your last accepted submission
carried (what a re-POST would replace), the same input_hash as the
acknowledgment, and processed: true once the day went through to the
market.
A real submission is live: the pipeline aggregates the day, writes the
trader CSV and submits the balancing-group schedules automatically.
Use validate_only for anything that is not a real forecast.
When to send
Send the forecast for delivery day D day-ahead, in time for the EPEX
day-ahead auction (gate closure 12:00 CET on D-1; agree your cut-off with
n:lead). Re-send whenever your forecast improves — the latest submission
for a delivery day wins and everything downstream re-runs automatically.
No forecast to send?
If you only have master data and metered data per customer, the bridge can
build the consumption forecast for you — see
Data delivery.
Sending an identical payload twice changes nothing (same input_hash),
so retries are safe.