> ## Documentation Index > Fetch the complete documentation index at: https://docs.energy.nlead.ch/llms.txt > Use this file to discover all available pages before exploring further. # Zentrale > Market data that are the same for every Mandant, read once and copied by every stack Each stack serves one Mandant: one BKV, its Lieferant, its mailbox, its audit share ([A stack per market party](https://docs.energy.nlead.ch/setup/azure-deployment.md#a-stack-per-market-party)). Some of what a stack reads is the same for every Mandant, so it is read once, by one instance, the **Zentrale**. The other stacks, the **Mandanten**, copy it from there: | Topic | Read by the Zentrale from | A Mandant copies | | - | - | - | | **reBAP** and its inputs: AEP modules, VoAA, NRV-Saldo, ID AEP, AEP-Schätzer, spot price | netztransparenz.de | the whole history, day by day: quality-assured days every 6 hours, operational ones hourly | | **reBAP module 1** prices: PICASSO/MARI, day-ahead | ENTSO-E | (part of the history) | | **PARTIN directory**: the partners' newest datasheets, per role | the shared mako365 account, for every Mandant's MP-ID | every 6 hours | A Mandant needs no netztransparenz client and no ENTSO-E token. What it copies is stored on its own audit share, so its views (reBAP forecast, Fahrplan/Ist costs, calculation, partner contacts) read locally as before. If the Zentrale is down, the next copy is just late (`rebap_abruf_fehler`, `zentrale_partin_fehler`). Market communication stays with each Mandant: answering a partner's PARTIN, its APERAK, the partner status in the Marktpartner list, and the evidence of what a partner sent *us* (`GET /v1/process/market-partners/{key}`, `received`). The Zentrale's datasheets only fill in **contact data**: a partner that sent its datasheet only to another Mandant still has its desks and addresses known here, for the PARTIN popup, the Korrektur and Nachfass mails and the LRV recipient. ## Which instance is the Zentrale Any instance can be the Zentrale: the one that holds the netztransparenz client, the ENTSO-E token and a MakoFlow login. This can be one of the Mandanten' stacks or a stack of its own (the same template, with market routines off). There is no extra service: the Zentrale is the bridge. | Setting (console group *Zentrale*) | On the Zentrale | On a Mandant | | - | - | - | | `ZENTRALE_URL` | empty | the Zentrale's base URL, e.g. `https://` | | `ZENTRALE_API_KEY` | empty | a **report key** of the Zentrale (write-only, never shown) | | `ZENTRALE_MANDANTEN` | the Mandanten's MP-IDs and role, JSON: `{"9984303000001": "bkv", "9984302000002": "lieferant"}` | empty | | `NETZTRANSPARENZ_*`, `ENTSOE_*` | set | can be cleared | The Zentrale always collects for its own BKV and Lieferant MP-IDs too. Give each Mandant its own report key on the Zentrale (`REPORT_API_KEYS` takes `name:secret` pairs), so the event log names which Mandant read. ## The PARTIN directory A Netzbetreiber sends its datasheet to every party it works with. The company and contact data are its own and the same for every recipient. Only the contact blocks depend on the receiver's role: a BKV gets no Rahmenverträge desk (PARTIN AHB 1.1). So the Zentrale keeps, **per role (`bkv`, `lieferant`) and partner**, the newest datasheet any Mandant received in the last 180 days, by AS4 or as a mailed attachment. A Mandant reads the datasheets of its own role. It reads the mako365 account once per MP-ID in `ZENTRALE_MANDANTEN`, past the MakoFlow cache, which keeps only the instance's own traffic. It stores partners and roles, never **who** received a datasheet: no Mandant's MP-ID and no other party's traffic. Datasheets addressed to an MP-ID that is not listed are not read. In a Mandant's directory its own inbox comes first: a datasheet it holds appears once (`via: as4` or `email`), and the Zentrale's appears where there is none, or where it is newer (`via: zentrale`). For the contact address, the Mandant's own datasheet wins. ## Endpoints | Call | Key | Purpose | | - | - | - | | `GET /v1/process/zentrale` | report | How this instance stands: `rolle` (`zentrale`, `mandant`, `eigenstaendig`), when the reBAP and the directory were last read, partners per role | | `GET /v1/process/zentrale/rebap?seit=` | report | The stored reBAP history from `seit` on (default 70 days back) - what a Mandant copies | | `GET /v1/process/zentrale/partin` | report | The PARTIN directory per role and partner - what a Mandant copies; 409 before the first collection | | `POST /v1/process/zentrale/aktualisieren` | process | Now, outside the routines' rhythm: on a Mandant both copies, on the Zentrale the PARTIN collection | `POST /v1/process/rebap/aktualisieren` on a Mandant also copies from the Zentrale. `GET /v1/process/marktdaten/roh` (raw reads of the data services) answers 409 on a Mandant: raw reads happen on the Zentrale, which has the credentials. ## Routines | Agent | What | Gate | | - | - | - | | `zentrale-partin` | collect (Zentrale) or copy (Mandant) the PARTIN directory, every 6 hours | `ZENTRALE_URL` set, or `ZENTRALE_MANDANTEN` and a MakoFlow login | | `rebap-quality` | the quality-assured reBAP days, from netztransparenz.de or from the Zentrale, every 6 hours | netztransparenz client or `ZENTRALE_URL` set | | `rebap-operational` | the operational reBAP points, likewise, hourly | likewise | ## Setting it up **1. On the Zentrale** Keep (or set) the netztransparenz client and the ENTSO-E token. In the console, group *Zentrale*, set `zentrale_mandanten` to every Mandant's BKV and Lieferant MP-ID. Create a report key per Mandant (`REPORT_API_KEYS`). Then run `POST /v1/process/zentrale/aktualisieren` once, or wait for the routine. **2. On each Mandant** In the console, group *Zentrale*, set `zentrale_url` and `zentrale_api_key`. Run `POST /v1/process/zentrale/aktualisieren` and check `GET /v1/process/zentrale`: `rolle` is `mandant`, and the reBAP days and partners are there. Once they are, the netztransparenz client and ENTSO-E token can be cleared on the Mandant. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.