Skip to main content

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.