# Die Bereiche der Referenz

Die ausgelieferte Spezifikation gliedert ihre 443 Operationen in 19 Bereiche (Tags) und 7 Gruppen — in genau dieser Reihenfolge zeigt sie die Referenz. Lesen Sie die Tabellen als Landkarte: Was ein Bereich enthält, ob ein API-Schlüssel dort etwas darf und welche Befehlsgruppe der Kommandozeile ihm entspricht.

> **Typ:** nachschlagen
> **Für wen:** Wer in der Referenz einen Bereich sucht oder wissen will, wo eine Ressource zu Hause ist.
> **Voraussetzung:** keine

Die Spalte **Mit Schlüssel** leitet sich aus dem Rechte-Katalog ab: „ja“ heißt, die Rechte des Bereichs sind schlüsselfähig. „teilweise“ heißt, einzelne Routen brauchen nur eine Anmeldung oder ein schlüsselfähiges Recht, der Rest eine Sitzung. „Sitzung“ heißt, kein Recht des Bereichs ist für Schlüssel vorgesehen. „anmeldefrei“ heißt, die Route braucht keinen Ausweis. Was ein Schlüssel tragen kann, steht unter [Anmeldung](/de/api/authentication).

## Identität & Zugang

| Tag | Was Sie dort finden | Mit Schlüssel | Kommandozeile |
|---|---|---|---|
| `identity` | Benutzerkonten, das eigene Profil und die Zugangsmittel einer Organisation: Konten anlegen, sperren und reaktivieren, zweiter Faktor mit Wiederherstellungscodes, API-Schlüssel, verknüpfte Anbieter-Konten, dazu der [delegierte Zugang](/de/api/oauth-delegated-access) mit seinen Endpunkten außerhalb von `/v1` und die [SCIM-Fläche](/de/api/scim-provisioning) unter `/scim/v2`. | teilweise (`GET /v1/me`) | `user`, `api-key`, `invitation`, `operator` |
| `sessions` | Alle Wege in eine Sitzung: Passwort, Anmelde-Link, plattformweite Anbieter, Unternehmens-Anmeldung, zweiter Faktor, Organisationswahl. Dazu Erneuern und Beenden, Passwort zurücksetzen, Sitzungsübernahme durch den Betreiber. | Sitzung (öffentliche Anmelderouten) | `whoami` |
| `access` | Rollen und einzelne Erteilungen, der Katalog aller vergebbaren Rechte und die wirksamen Rechte des angemeldeten Kontos. | teilweise (`GET /v1/permission-catalog`, `GET /v1/me/permissions`) | `role`, `grant`, `permission` |
| `onboarding` | Selbst-Registrierung mit E-Mail-Bestätigung, Einladungen samt öffentlicher Annahmeseite, Beitrittsanfragen und der Einrichtungsassistent. | Sitzung | `invitation`, `self-registration` |

## Organisation & Abrechnung

| Tag | Was Sie dort finden | Mit Schlüssel | Kommandozeile |
|---|---|---|---|
| `tenancy` | Die Organisation selbst: Stammdaten, Geschäftsprofil, Marke, eigene Domain und die Unternehmens-Anmeldung mit ihren nachgewiesenen Domänen. Betreiber führen die Liste der Organisationen und sperren oder geben frei. | teilweise (`GET /v1/me/capabilities`) | — (Stammdaten pflegen Sie im Portal) |
| `billing` | Paket buchen, wechseln, kündigen, reaktivieren. Zahlungsmittel und Rechnungen einsehen, Kontingente prüfen. Betreiber pflegen den Artikelkatalog und bearbeiten Rechnungen und Erstattungen. | teilweise (`GET /v1/me/licensing`) | `subscription`, `invoice`, `catalog` |

## Inhalte & Planung

| Tag | Was Sie dort finden | Mit Schlüssel | Kommandozeile |
|---|---|---|---|
| `cloud-connections` | Die Vollmachten auf fremde Speicher-Konten, aus denen die Mediathek ihre Orte speist: Rundlauf zur Zustimmung, Zustand aller Verbindungen, Trennen. Zugriffs- und Auffrischungs-Token verlassen den Server nie. | Sitzung | — |
| `media-library` | Der Medienbestand: Hochladen einschließlich mehrteiliger Uploads, Ordner und dynamische Sammlungen, Umbenennen und Verschieben in Mengen. Je Medium Download-Verweise, Varianten, Verwendungsnachweise, Papierkorb und endgültiges Löschen. | ja | `asset`, `folder` |
| `composition` | Szenen anlegen, aus Vorlagen erzeugen, veröffentlichen, archivieren und wiederherstellen. Jede Änderung versioniert, Fassungen vergleichen und zurückrollen, Integritätsbefunde prüfen und ausräumen. | ja | `scene`, `scene-version`, `scene-template`, `layout`, `widget` |
| `scheduling` | Was wann läuft: Playlisten zusammenstellen, Programme anlegen, anhalten und fortsetzen, Standardszene bestimmen. Dazu Kalenderansicht und Konfliktvorschau. | ja | `playlist`, `schedule`, `display-group`, `player` (Programm und Übersteuerung) |
| `advertising` | Die Werbung der Organisation, in der Stabilität `beta`: Werbepartner, Werbekampagnen samt Buchungen, die Reichweite einer Buchung (`GET /v1/advertising/booking-lines/{id}/reach`) und die Vorschau, was eine Buchung liefern würde (`POST /v1/advertising/booking-lines/preview`). Dazu Motive aus der eigenen Mediathek mit ihrer Freigabe, die Werbefläche je Display, das Publikum je Standort und die Teilnahme am Werbenetz samt seinen Stellgrößen, dazu die monatlichen Erlösaufstellungen aus dem Werbenetz mit Verteilung je Werbekampagne und Gutschrift (`GET /v1/advertising/revenue`). Anlegen und Ändern verlangen die Fähigkeit `advertisingDirect` des Pakets. | ja | `advertiser`, `campaign`, `booking`, `creative` |

## Apps & Marketplace

| Tag | Was Sie dort finden | Mit Schlüssel | Kommandozeile |
|---|---|---|---|
| `app-catalog` | Die Herkunftsseite der Apps: Betreiber holen Releases aus der Registry, prüfen sie, geben sie frei (nach stable mit einer zweiten Person), stufen zurück, nehmen zurück, steuern Auslauffristen und setzen Ausnahmen je Organisation. Öffentlich ausgeliefert werden Manifest, Bündel und Autorenmodul einer App-Version sowie die Kataloge der Widgets (`GET /v1/widget-catalog`, mit der Motiv-Bibliothek des Grafik-Widgets unter `GET /v1/widget-catalog/graphics`) und der Ressourcentypen (`GET /v1/resource-type-catalog`) über alle Apps, dazu die Fassungen einer App mit Datum und dem, was in ihnen neu ist (`GET /v1/apps/{appId}/history`). | teilweise (öffentliche Auslieferung, beide Kataloge) | `app-release`, `app-status` |
| `marketplace` | Die Sicht der Organisation auf das App-Angebot: entdecken, installieren, aktualisieren, deinstallieren mit Vorschau der Folgen. Über ein Update entscheiden: die offenen Entscheidungen (`GET /v1/me/apps/updates`), die einer App (`GET /v1/me/apps/{appId}/update`), annehmen und ablehnen (`POST …/update/accept`, `POST …/update/reject`). Für Fassungen aus beta eintragen, für alle Apps (`GET\|PUT /v1/me/apps/beta-enrollment`) oder je App (`POST\|DELETE /v1/me/apps/{appId}/beta-enrollment`). Dazu der eigene Bestand — die installierten Apps (`GET /v1/me/apps`). Der Store liefert seine Lage fertig entschieden: die Übersicht als Karten (`GET /v1/me/apps/store`), den Eintrag einer App (`GET /v1/me/apps/store/{appId}`), die Sammlungen (`GET /v1/me/apps/collections`) und die Seite einer installierten App mit ihren Szenen und dem Verlauf ihrer Zustimmungen (`GET /v1/me/apps/{appId}/installed`). Wer nicht selbst entscheiden darf, bittet die Inhaber um eine Installation (`POST /v1/me/apps/{appId}/install-request`) oder um die Entscheidung über ein Update (`POST /v1/me/apps/{appId}/update/decision-request`). Die Daten einer deinstallierten App lesen Sie mit `GET /v1/me/apps/{appId}/data`, ihre Löschung nach 30 Tagen merken Sie mit `POST /v1/me/apps/{appId}/data/deletion` vor und brechen sie mit `DELETE /v1/me/apps/{appId}/data/deletion` ab. | teilweise (`GET /v1/me/apps/store`) | `app` |

## Flotte & Wiedergabe

| Tag | Was Sie dort finden | Mit Schlüssel | Kommandozeile |
|---|---|---|---|
| `fleet` | Die Abspielgeräte: Inbetriebnahme über Kopplungscode, Etiketten, Fernbefehle mit Rückmeldung, Displays entfernen. Geräte melden Lebenszeichen, Fähigkeiten und den Verlauf ihrer Aktualisierungen. Die Handlungen am Gerät selbst (neu koppeln, Werkszustand, entfernen, sperren) stehen unter `identity`. Hier liegen auch die [Standorte](/de/api/locations) als Ordner über den Displays, die [Web-Displays](/de/api/web-displays), die ohne Gerät im Browser laufen, und die Bildschirmaufnahmen eines Displays als Zeitreihe (`GET /v1/players/{playerId}/screenshots`). | teilweise (`location.*`, `fleet.player.list`, `…read`, `…update`, `…command.issue`, `fleet.web-display.manage`) | `device`, `player`, `location`, `playback` |
| `playback` | Die Schnittstelle zum Abspieler: Wiedergabepaket laden, Start zurückmelden, Diagnoseprotokolle liefern. Dazu Vorschau von Widget-Daten und Auslieferung des Abspieler-Bündels. | Sitzung (Gerät oder Betreiber) | `playback` |

## Überwachung & Meldungen

| Tag | Was Sie dort finden | Mit Schlüssel | Kommandozeile |
|---|---|---|---|
| `audit` | Das revisionssichere Prüfprotokoll: Einträge durchsuchen, Vorgänge über ihre Korrelation bündeln, Auszüge exportieren. Betreiber pseudonymisieren personenbezogene Einträge und lösen Pseudonyme auf. | Sitzung | `audit` |
| `notifications` | Postfach im Portal, persönliche Zustellwege und Webhooks samt Zustellprotokoll, erneuter Zustellung und Wechsel des Geheimnisses, dazu der [Ereigniskatalog](/de/webhooks/fetch-event-catalog), aus dem eine Abo-Liste entsteht. | Sitzung | `webhook` |
| `analytics` | Frei auswerten nach dem Kennzahlen-Katalog und das Ergebnis als CSV oder PDF ausgeben, dazu Überblick, Tag und Protokoll eines Displays, die eigenen Inhalte und die Lieferung einer Werbekampagne. Ansichten speichern, planmäßig zustellen und herunterladen, Kennzahlen abfragen, dazu der Aufräum-Überblick, der zählt, was liegen geblieben ist. Der Standort ist eine Achse der freien Auswertung. Dazu die Nachweise der Buchungen samt Zwischenstand, die Verweise für Werbepartner und — ohne Anmeldung — die Prüfung eines Nachweises und der Kampagnenbericht hinter einem Verweis. | teilweise (`analytics.query.run`, `analytics.proof.read`, `analytics.proof.manage`) | `analytics`, `hygiene`, `proof` |

## Plattform-Betrieb

Ein Bereich mit zwei anmeldefreien Routen — der Rest der Betreiber-Fläche steht **nicht** in dieser Spezifikation (siehe unten).

| Tag | Was Sie dort finden | Mit Schlüssel | Kommandozeile |
|---|---|---|---|
| `status` | Die beiden Routen des Betriebs, die jeder abrufen darf: der Status der Plattform, wie ihn die Statusseite zeigt (`GET /v1/public/status`), und das laufende Wartungsfenster (`GET /v1/public/maintenance-status`). | anmeldefrei | `health public` |

### Was hier nicht steht: die Betreiber-Fläche

Die Schnittstelle trägt daneben rund 280 Operationen unter `/v1/platform/…` — Warteschlangen, Zwischenspeicher, Signaturschlüssel, Rechte-Katalog, Ereignis-Verteiler, Prüfprotokoll-Betrieb. Sie sind die **Innenansicht des Hauses**: Sie gelten dem Betreiber der Plattform, nicht Ihrer Organisation, und ein Schlüssel oder eine Sitzung einer Organisation bekommt dort `403 Permission.OperatorOnly`.

Diese Routen sind deshalb **kein Teil dieser Referenz**, und die Spezifikation unter `/api/openapi.json` enthält sie nicht: Ein erzeugter Client bekommt aus ihr nur, was Sie auch aufrufen dürfen. Wer die Plattform selbst betreibt, findet die Betreiberfassung an seiner eigenen Umgebung hinter einer Anmeldung.

## Was die Referenz sonst nicht zeigt

| Fläche | Warum nicht |
|---|---|
| Die Betriebsrouten `GET /health/live`, `GET /health/ready`, `GET /health/version` und `GET /metrics` | Sie sind als `internal` geführt: Sie beschreiben den Zustand einer Umgebung, nicht Ihren Bestand. Sie antworten weiter ohne Anmeldung, und `szenera health` fragt sie ab. |
| Der Betrieb installierter Apps und die Auskunft über offene Echtzeit-Verbindungen | ebenfalls `internal` — die Innenansicht der Laufzeit. |
| Routen, die eine App mitbringt (`/v1/apps/<app-id>/…`) | Welche es gibt, hängt vom App-Bestand Ihrer Umgebung ab. Ein Release-Stand kann sie nicht kennen. |

Was `internal` bedeutet und was die öffentliche Fassung stattdessen zusagt, steht unter [Stabilitätsklassen und Auslauf](/de/changes/stability-and-sunset).

## Weiterführendes

- [Die Referenz lesen](/de/api/read-reference)
- [Stabilitätsklassen und Auslauf](/de/changes/stability-and-sunset)
- [Befehle für Ihre Organisation](/de/cli/commands-organization)