ERE positions

GET /partner/ere-positions • per-EAN ERE position for your attributed customers, in bulk

GET /partner/ere-positions returns the ERE position per connection (EAN) for every customer attributed to you, for a compliance year: registered and sellable ERE, the expected net payout, and a per-quarter breakdown. Use it to reconcile positions per connection in bulk.

The connection (EAN) is the key. Positions only appear once a customer has completed onboarding and produced eligible sessions • before that a customer shows up under GET /partner/drafts, not here.

Request

curl "https://api.joulo.nl/functions/v1/api/partner/ere-positions?year=2026&limit=200&offset=0" \
  -H "Authorization: Bearer jpk_live_..."

Query param	Required	Notes
`year`	no	Compliance year. Default `2026`.
`limit`	no	Page size, `1`–`500`. Default `200`.
`offset`	no	Page offset. Default `0`.

Response

{
  "positions": [
    {
      "ean": "871685920000123456",
      "external_ref": "KLANT-8842",
      "registration_status": "goedgekeurd",
      "ean_validation_status": "matched",
      "ere_eligible": true,
      "compliance_year": 2026,
      "registered_ere": 234.354,
      "allocatable_ere": 227.6865,
      "pending_ere": 6.6675,
      "expected_net_eur": 319.15,
      "quarters": [
        { "quarter": "2026 Q2", "registered_ere": 177.4433 },
        { "quarter": "2026 Q3", "registered_ere": 50.2431 }
      ],
      "computed_at": "2026-07-21T10:00:00Z"
    }
  ],
  "limit": 200,
  "offset": 0,
  "count": 250,
  "compliance_year": 2026
}

Field	Meaning
`ean`	The connection this position belongs to.
`external_ref`	Your own customer reference, as supplied on upload. `null` if you did not supply one. See Upload customers.
`registration_status`	Registration lifecycle: `concept` → `ingediend` → `in_review` → `goedgekeurd` (or `afgekeurd`).
`ean_validation_status`	EAN validation: `matched`, `mismatched` or `unavailable`.
`ere_eligible`	`true` when eligible ERE has been produced (sellable + in the settle buffer).
`registered_ere`	All eligible ERE this year: sellable plus what is still inside the 3-day settle buffer.
`allocatable_ere`	ERE that has cleared the settle buffer and is available to sell.
`pending_ere`	ERE inside the 3-day settle buffer • rolls into `allocatable_ere` over the next days.
`expected_net_eur`	Expected net payout to the customer for the full year (market-based, indicative).
`quarters[]`	Registered ERE per quarter.
`computed_at`	When this position was last recomputed (see freshness below).
`count`	Total attributed connections, for pagination.

Amounts are the customer's net payout (market-based, indicative) • never a guarantee. Only connections attributed to you are returned.

Per connection, not per person

A position belongs to a connection, because the authorization to register with the NEa is bound to one party per EAN. Two people living at the same address therefore never build separate positions on the same EAN at the same time • there is exactly one authorization holder per period.

Successive occupants do happen. What was registered under the previous occupant's authorization stays on their account and is paid out to them; the new occupant builds up from their own authorization date. In that case the same ean appears on two rows with a different external_ref — one per customer, each with its own build-up.

What a switch of energy supplier changes: nothing

The ERE position hangs on the connection and on the authorization the customer gave Joulo, not on who supplies the electricity. A customer who switches supplier keeps the same position, and this endpoint keeps returning the full Joulo position for the compliance year — including kWh from before the switch, since Joulo registers retroactively from 1 January 2026 as far back as the charger connection can deliver historical sessions.

One limit: if another registration service provider held the authorization on that EAN earlier and already registered kWh, those periods cannot be registered again. Those ERE stay with that party and never appear here.

Freshness and polling

Positions are recomputed roughly every 15 minutes; computed_at tells you how fresh each row is. They move slowly (a 3-day settle buffer plus the daily sync), so polling a few times per day is plenty. There is no push webhook.

Access

This endpoint is on the API-key allowlist, so your jpk_live_ key can read it directly. It only ever returns connections attributed to your own account.