Zum Inhalt springen
Szenera DeveloperHandbuch
CLI › Befehle › Befehle für Ihre Organisation
Kapitel

Befehle für Ihre Organisation

Alle Befehle von szenera, die mit einem Schlüssel oder Konto Ihrer Organisation laufen: Medien, Szenen, Playlisten, Programme, Geräte, Team, Apps, Abo.

19 Minuten LesezeitCLIStand: 25.10.2026

Auf dieser Seite

Bevor Sie loslegen

Für wen
Wer einen Vorgang seiner Organisation aus einem Skript oder vom Terminal anstoßen will und wissen muss, welcher Befehl welche Route und welches Recht braucht
Voraussetzung
ein Profil mit einem Schlüssel oder Konto der Organisation. Die Rechte der Spalte „Recht“ muss der Ausweis tragen.

Alle Befehle der Kommandozeile szenera. Sie laufen mit einem API-Schlüssel ak_… oder einem Konto Ihrer Organisation. Jede Tabelle nennt je Befehl die Route, das nötige Recht, ob ein API-Schlüssel das Recht tragen darf („Schlüssel“) und ob der Befehl etwas verändert. Die Spalte „Schlüssel“ folgt dem Rechte-Katalog der Plattform: Ein Recht, das nur Konten vorbehalten ist, bekommt kein Schlüssel — der Befehl antwortet dann mit 403 (Exit 4), und Sie brauchen ein Profil mit Kennwort-Anmeldung.

szenera <befehl> --help zeigt zu jedem Befehl Stellungen, Flaggen und Beispiele. Die Beschreibung dort ist die Quelle dieser Tabellen. Stand ist das Register von szenera mit 136 Befehlen, alle stehen hier. 21 davon dienen auch dem Plattformbetrieb und nehmen dort zum Teil eine andere Route. Diese Wege und die Befehle, die nur dem Betrieb dienen, stehen unter Befehle für den Plattformbetrieb.

Überall gültige Flaggen

Flagge Wirkung
--help Hilfe zum Befehl zeigen und nichts tun, meldet sich nie an
--profile=<name> Welches Profil gilt (Umgebung, Ausweis, Dienst-Adressen)
--json Ausgabe als JSON erzwingen
--table Ausgabe als Tabelle erzwingen
--raw Bricht eine Antwort den Vertrag, die Rohantwort ausgeben

Eine Flagge trägt ihren Wert am Gleichheitszeichen (--limit=20), --limit 20 gibt es nicht. Eine unbekannte Flagge ist ein Fehler (Exit 1), kein stiller Hinweis. Listen-Befehle blättern mit --limit=<anzahl> (1 bis 200, bei gefilterten Listen bis 100), --cursor=<marke> und --all (allen Seiten folgen). Befehle, die auf einen Vorgang warten, nehmen --timeout=<dauer> (90s, 20m, 2h oder eine Zahl in Sekunden), teils --interval=<dauer> und --no-wait. Unumkehrbare Eingriffe verlangen --yes. Ohne die Flagge bricht der Befehl mit Exit 1 ab und sagt, was geschehen würde.

Umgebung und Ausweis

Befehl Zweck Route und Recht Schlüssel Verändert
health Meldet die Umgebung sich bereit — und welche Prüfung sagt was GET /health/ready, kein Ausweis nötig, bei 503 Exit 9 — nein
health public Was die Statusseite draußen zeigt: Zustand je Baustein, Wartungsfenster, öffentliche Störungen GET /v1/public/status, kein Ausweis nötig — nein
whoami Wer der eigene Ausweis ist — Konto, Organisation, Rechte GET /v1/me, nur Anmeldung, kein eigenes Recht ja nein
hygiene get Was liegen geblieben ist: sechs Zahlen und je Zahl der Befehl, der die Zeilen dahinter zeigt GET /v1/analytics/hygiene · analytics.query.run. --offline-since (Vorgabe P7D) und --dormant-since (Vorgabe P90D) setzen die beiden Schwellen ja nein

Medien und Ordner

Befehl Zweck Route und Recht Schlüssel Verändert
asset list Die Medien der Mediathek. --usage=unused findet, was in keiner Szene, keiner Playliste und keinem Markenzeichen steckt GET /v1/assets · asset.list ja nein
asset get <ast_…> Ein Medium samt seiner Varianten. --usages nennt, wo es steckt GET /v1/assets/{id}, GET /v1/assets/{id}/usage · asset.read ja nein
asset upload --file=<pfad> Eine Datei in die Mediathek laden und warten, bis sie nutzbar ist POST /v1/assets/upload-precheck → Bytes → POST /v1/assets/upload-complete · asset.upload. Wartet bis ready, Vorgabe --timeout=10m, --no-wait ja ja
asset download <ast_…> --output=<pfad> Ein Medium oder eine seiner Varianten holen POST /v1/assets/{id}/download-url (Variante: /variant-url) → Bytes · asset.read ja nein
asset update <ast_…> Name, Schlagworte oder Ordner eines Mediums ändern PATCH /v1/assets/{id} · asset.update ja ja
asset reprocess <ast_…> Die Varianten eines Mediums neu erzeugen und warten POST /v1/assets/{id}/reprocess · asset.update. Wartet wie beim Hochladen ja ja
asset delete <ast_…> --yes Ein Medium in den Papierkorb legen DELETE /v1/assets/{id} · asset.delete ja ja
asset restore <ast_…> Ein Medium aus dem Papierkorb zurückholen POST /v1/assets/{id}/restore · asset.update ja ja
asset purge <ast_…> --yes Ein Medium endgültig löschen POST /v1/assets/{id}/purge · asset.delete ja ja
asset bulk-update --assets=<ast_…,…> Viele Medien verschieben oder verschlagworten (bis zu 100) POST /v1/assets/bulk-move bzw. POST /v1/assets/bulk-tag · asset.update ja ja
folder list Der Ordnerbaum der Mediathek GET /v1/folders · asset.folder.list ja nein
folder create --name=<name> Einen Ordner anlegen POST /v1/folders · asset.folder.create ja ja
folder update <fld_…> Einen Ordner umbenennen oder verschieben PATCH /v1/folders/{id} (--name), POST /v1/folders/{id}/move (--parent) · asset.folder.update ja ja
folder delete <fld_…> --yes Einen Ordner löschen. Die Medien rutschen eine Ebene höher DELETE /v1/folders/{id} · asset.folder.delete ja ja

Ist derselbe Inhalt schon da, entfällt beim Hochladen der Byte-Strom: Die Vorprüfung erkennt ihn an der sha256-Prüfsumme. Ab 50 MiB läuft der Strom in 8-MiB-Stücken.

Szenen, Fassungen und Layouts

Befehl Zweck Route und Recht Schlüssel Verändert
scene list Die Szenen der Organisation. --assignment=none findet die, auf die kein Programm, kein Zeitplan und keine zugewiesene Playliste zeigt (sinnvoll mit --status=published) GET /v1/scenes · scene.list ja nein
scene get <scn_…> Eine Szene samt ihrer offenen Befunde GET /v1/scenes/{id}, GET /v1/scenes/{id}/integrity-issues · scene.read ja nein
scene create --name=<name> Eine leere Szene anlegen POST /v1/scenes · scene.create ja ja
scene create-from-template --template=<sct_…> --name=<name> Eine Szene aus einer kuratierten Vorlage anlegen POST /v1/scenes/from-template · scene.create ja ja
scene update <scn_…> Den Entwurf einer Szene ändern. Ohne --version liest der Befehl die Fassung vorher PATCH /v1/scenes/{id} · scene.update ja ja
scene publish <scn_…> Den Entwurf als neue Fassung veröffentlichen. Nennt Befunde statt sie zu verschlucken POST /v1/scenes/{id}/publish · scene.publish ja ja
scene recheck <scn_…> Die Unversehrtheit neu prüfen und die Befunde nennen POST /v1/scenes/{id}/integrity-issues/recheck · scene.read ja ja
scene resolve-issue <sii_…> --scene=<scn_…> --resolution=manual-fixed|ignored Einen Befund als behoben oder ignoriert schließen POST /v1/scenes/{id}/integrity-issues/{iid}/resolve · scene.update ja ja
scene archive <scn_…> Eine Szene archivieren POST /v1/scenes/{id}/archive · scene.archive ja ja
scene restore <scn_…> Eine archivierte oder gelöschte Szene zurückholen POST /v1/scenes/{id}/restore · scene.update ja ja
scene delete <scn_…> --yes Eine Szene in den Papierkorb legen DELETE /v1/scenes/{id} · scene.delete ja ja
scene bulk-update --entries=<pfad> Bis zu 50 Szenen in einem Aufruf ändern POST /v1/scenes/bulk-update · scene.update ja ja
layout list Die Layout-Vorlagen — eingebaute und eigene GET /v1/layout-templates · layout-template.list ja nein
scene-template list Die kuratierten Szenen-Vorlagen. --orientation=landscape|portrait filtert GET /v1/scene-templates · scene.read ja nein
scene-version list --scene=<scn_…> Die veröffentlichten Fassungen einer Szene GET /v1/scenes/{id}/versions · scene.read ja nein
scene-version get <scv_…> --scene=<scn_…> Eine Fassung samt ihrer Momentaufnahme GET /v1/scenes/{id}/versions/{vid} · scene.read ja nein
scene-version diff <scv_…> --scene=<scn_…> --against=<scv_…> Zwei Fassungen gegeneinander stellen GET /v1/scenes/{id}/versions/{vid}/diff/{vid2} · scene.read ja nein
scene-version revert <scv_…> --scene=<scn_…> Den Entwurf auf eine ältere Fassung zurücksetzen. Veröffentlicht nichts POST /v1/scenes/{id}/versions/{vid}/revert · scene.publish ja ja
scene-version thumbnail <scv_…> --scene=<scn_…> Das Vorschaubild hinterlegen (--file) oder seine Adresse holen POST …/versions/{vid}/thumbnail · scene.update, POST …/thumbnail-url · scene.read ja ja

Die Fassung einer Szene steht zweimal in der Antwort: als Feld version im Rumpf und als Kopfzeile ETag. Die Kommandozeile liest sie selbst, wenn --version fehlt. Bei scene publish bedeuten zwei Absagen Verschiedenes: Scene.PublishValidationFailed (422, Exit 7) ist eine Ursache zum Beheben, Scene.PublishBlocked (409, Exit 6) sind blockierende Befunde, die --ignore-issues schließt.

Playlisten und Programme

Befehl Zweck Route und Recht Schlüssel Verändert
playlist list Die Wiedergabelisten der Organisation GET /v1/playlists · playlist.list ja nein
playlist get <pll_…> Eine Wiedergabeliste samt ihrer Punkte GET /v1/playlists/{id} · playlist.read ja nein
playlist create --name=<name> Eine Wiedergabeliste anlegen: --items (Sequenz) oder --folder/--tags (Regel) POST /v1/playlists · playlist.create ja ja
playlist update <pll_…> Eine Wiedergabeliste ändern. --items ersetzt die ganze Sequenz PATCH /v1/playlists/{id} · playlist.update ja ja
playlist delete <pll_…> --yes Eine Wiedergabeliste löschen. Zugewiesene weist die API ab DELETE /v1/playlists/{id} · playlist.delete ja ja
playlist preview-source Eine automatische Quelle probeweise auflösen POST /v1/playlists/source-preview · playlist.read und asset.read ja nein
schedule list Die Programme der Organisation GET /v1/schedules · schedule.list ja nein
schedule get <sch_…> Ein Programm samt seiner Punkte. --players nennt die Geräte, die es spielen GET /v1/schedules/{id}, GET /v1/schedules/{id}/players · schedule.read ja nein
schedule create --name=<name> Ein Programm anlegen, ohne --base mit Sendepause POST /v1/schedules · schedule.create ja ja
schedule update <sch_…> Name oder Basis eines Programms ändern PATCH /v1/schedules/{id} · schedule.update ja ja
schedule delete <sch_…> --yes Ein Programm löschen. Zugewiesene weist die API ab DELETE /v1/schedules/{id} · schedule.delete ja ja
schedule create-item --schedule=<sch_…> --content=… --recurrence=… Einen Programmpunkt anlegen (once:, daily:, weekly:, monthly:) POST /v1/schedules/{id}/items · schedule.update ja ja
schedule update-item <sci_…> --schedule=<sch_…> Einen Programmpunkt ändern, stilllegen (--disabled) oder anschalten (--enabled) PATCH /v1/schedules/{id}/items/{itemId} · schedule.update ja ja
schedule delete-item <sci_…> --schedule=<sch_…> Einen Programmpunkt löschen DELETE /v1/schedules/{id}/items/{itemId} · schedule.update ja ja
player get-program <ply_…> Was einem Display zugewiesen ist — samt Übersteuerung GET /v1/players/{id}/program · fleet.player.read ja nein
player set-program <ply_…> --content=… Einem Display etwas zuweisen. --clear entfernt die Zuweisung. Idempotent PUT /v1/players/{id}/program · schedule.update ja ja
display-group set-program <dgr_…> --content=… Einer Leinwand — und damit allen ihren Displays — etwas zuweisen. --clear entfernt die Zuweisung. Idempotent PUT /v1/display-groups/{id}/program · schedule.update ja ja
player set-override <ply_…> --content=… Auf einem Display jetzt etwas anderes zeigen (--until oder --indefinite) PUT /v1/players/{id}/override · schedule.update ja ja
player clear-override <ply_…> Die Übersteuerung eines Displays beenden DELETE /v1/players/{id}/override · schedule.update ja ja

Inhalte werden in Kurzform übergeben: schedule:sch_…, scene:scn_…, playlist:pll_…, asset:ast_… — bei der Basis eines Programms auch pause.

Wiedergabe und Widgets

Befehl Zweck Route und Recht Schlüssel Verändert
playback now Was gerade auf allen Displays läuft (play, pause, gap) GET /v1/players/now-playing · fleet.player.list ja nein
playback timeline <ply_…> Die aufgelöste Abspiel-Timeline eines Displays (Fenster ab jetzt, 4 Stunden bis 7 Tage) GET /v1/players/{id}/timeline · fleet.player.read ja nein
playback history <ply_…> --date=<datum> Der aufgezeichnete Tagesverlauf eines Displays (90 Tage aufbewahrt) GET /v1/players/{id}/playback-history · fleet.playback-history.read nein nein
playback refresh <ply_…> Die Momentaufnahme eines Displays neu berechnen POST /v1/players/{id}/snapshot/refresh · fleet.player.update ja ja
widget preview --widget=<pfad> Die Daten eines Widgets für eine Vorschau auflösen POST /v1/widget-data/preview · scene.read ja nein

Werbung

Werbepartner, Werbekampagnen, Buchungen und Motive des eigenen Werbegeschäfts. Lesen geht in jedem Paket. Anlegen und Freigeben verlangen zusätzlich die Fähigkeit advertisingDirect des Pakets, ohne sie antwortet der Server mit 403 und Billing.FeatureNotEntitled (Exit 4). Werbekampagnen des Werbenetzes stehen in campaign list, sobald sie Displays Ihrer Organisation erreichen, ohne Preis und ohne Notiz des Betreibers.

Befehl Zweck Route und Recht Schlüssel Verändert
advertiser list Die Werbepartner, filterbar nach --status, --industry und --search GET /v1/advertising/advertisers · advertising.advertiser.read ja nein
advertiser get <adv_…> Ein Werbepartner mit Marken, Ansprechpersonen und Notiz GET /v1/advertising/advertisers/{id} · advertising.advertiser.read ja nein
advertiser create --name=<name> --industry=<branche> Einen Werbepartner anlegen. --brand darf sich wiederholen POST /v1/advertising/advertisers · advertising.advertiser.manage ja ja
campaign list Die Werbekampagnen mit Phase, Zeitraum, Zahl der Buchungen und erreichten Displays. --owner=tenant oder --owner=network trennt eigenes Geschäft und Netz GET /v1/advertising/campaigns · advertising.campaign.read ja nein
campaign get <acp_…> Eine Werbekampagne mit Phase, Zeitraum, Ziel und Preis GET /v1/advertising/campaigns/{id} · advertising.campaign.read ja nein
booking list --campaign=<acp_…> Die Buchungen einer Werbekampagne mit Spotlänge, Frequenz und Zusage GET /v1/advertising/campaigns/{id}/booking-lines · advertising.campaign.read ja nein
creative list Die Motive. --approval=pending ist die Liste der Prüfung GET /v1/advertising/creatives · advertising.campaign.read, advertising.creative.manage oder advertising.creative.approve ja nein
creative approve <crv_…> Ein Motiv freigeben. Verlangt die Branche einen Pflichttext, bestätigen --text-present und --text-legible, dass er im Motiv steht und lesbar ist POST /v1/advertising/creatives/{id}/approval · advertising.creative.approve ja ja

Abgelehnt wird ein Motiv im Portal, wo die Anmerkung für den Werbepartner entsteht. Welche Displays eine Buchung erreicht und warum andere nicht, beantwortet GET /v1/advertising/booking-lines/{id}/reach über den Notausgang szenera api get.

Geräte

Befehl Zweck Route und Recht Schlüssel Verändert
player list Die Displays der Organisation. --program=none findet die ohne Inhalt, --offline-since=P7D die, die so lange nichts melden (ein nie gemeldetes zählt mit) GET /v1/players · fleet.player.list, dazu --status, --search ja nein
device list Die Geräte — was steht draußen, meldet es sich noch GET /v1/devices · identity.device.list nein nein
device get <dev_…> Ein Gerät im Einzelnen: Zertifikat und Flächen GET /v1/devices/{id} · identity.device.list nein nein
device send-command <dev_…> <kind> Einen Fernwartungs-Befehl an ein Gerät (reboot, locate, tail-log, mark-good, check-ota) oder eine Fläche (screenshot, identify, set-config, display-power, display-source, refresh-snapshot, mit --screen=<n>) absetzen. Antwort 201 heißt angenommen, --wait bleibt dran POST /v1/devices/{id}/commands, POST /v1/players/{id}/commands · fleet.player.command.issue. Flächen-Arten lösen zusätzlich über identity.device.list auf — das ist nicht schlüsselfähig, mit einem Schlüssel laufen deshalb nur die Maschinen-Arten ja ja
device list-commands <dev_…> Die letzten Fernwartungs-Befehle eines Geräts GET /v1/devices/{id}/commands · fleet.player.read ja nein
device screenshot <dev_…> Ein Bildschirmfoto anfordern, darauf warten und es holen (--file) POST /v1/players/{id}/commands → GET …/commands/{cid}/output · fleet.player.command.issue, fleet.player.read und identity.device.list. Das letzte ist nicht schlüsselfähig, deshalb bleibt dieser Befehl Sitzungen vorbehalten. Vorgabe --timeout=5m, --interval=5s nein ja

Die Suche über die Seriennummer, das Freigeben und Sperren eines Geräts und das Nachlesen eines einzelnen Befehls sind Befehle des Plattformbetriebs und nicht Teil von szenera, siehe Befehle für den Plattformbetrieb.

Ein Gerät neu koppeln, in den Werkszustand versetzen, aus der Organisation entfernen oder als verloren melden: Dafür gibt es unter einem Organisations-Profil keinen eigenen Befehl. Der Weg ist die Karte Lebenszyklus im Portal oder api post gegen POST /v1/devices/{id}/release mit {"reason":"reconnect"}, "factory" oder "removed" bzw. gegen POST /v1/devices/{id}/block mit einem Grund (identity.device.lifecycle, nicht schlüsselfähig). Meldet sich ein gekoppeltes Gerät mit neuem Schlüssel, entscheidet POST /v1/devices/{id}/reregistration mit {"decision":"keep"}, "reconnect" oder {"decision":"block","reason":"…"}. Einen Fernwartungs-Befehl für den Werkszustand gibt es nicht.

Standorte

Befehl Zweck Route und Recht Schlüssel Verändert
location list Die Standorte der Organisation. Die letzte Spalte zählt die Displays am Ort GET /v1/locations · location.list, vollständig, ohne Blättern ja nein
location get <loc_…> Ein Standort mit Anschrift, Zeitzone, Lage, Notiz und Fassung GET /v1/locations/{id} · location.read ja nein
location create --name=<name> --timezone=<IANA> Einen Standort anlegen. Die Anschrift kommt über --street, --postal-code, --city, --country, Lage über --latitude/--longitude, dazu --note POST /v1/locations · location.create, braucht die Fähigkeit Standorte ja ja
location update <loc_…> Name, Zeitzone, Anschrift, Lage oder Notiz ändern. --clear-address und --clear-coordinates entfernen die Angabe PATCH /v1/locations/{id} · location.update ja ja
location delete <loc_…> --yes Einen leeren Standort löschen. Mit Displays daran antwortet die API 409 Location.HasPlayers DELETE /v1/locations/{id} · location.delete ja ja
player assign-location <ply_…> --location=<loc_…> Ein Display an einen Ort hängen. Ein zweiter Aufruf hängt um statt zu verdoppeln PATCH /v1/players/{id} · fleet.player.update ja ja
player unassign-location <ply_…> Ein Display von seinem Ort lösen. Es behält Programm, Einstellungen und Lizenz PATCH /v1/players/{id} · fleet.player.update ja ja

Ein Standort ist ein Ordner über Displays: Er trägt keine Rechte und keinen eigenen Bestand, und er reißt beim Löschen nie ein Display mit. Die Felder und die Fehlercodes stehen unter Standorte.

Auswertung

Befehl Zweck Route und Recht Schlüssel Verändert
analytics overview Der Überblick: je Display die Verfügbarkeit in der Planzeit, darüber Lücken, rechtzeitig gemeldete Planstunden und Ausspielungen. --location (wiederholbar) schränkt auf Standorte ein GET /v1/analytics/overview · analytics.query.run ja nein
analytics explore --measure=<kennzahl> Kennzahlen frei auswerten: --measure und --by sind wiederholbar, dazu --sort, --ascending, --limit, --perspective und --granularity. --query=<pfad> nimmt die vollständige Abfrage samt Filtern als JSON POST /v1/analytics/explore · analytics.query.run ja nein
analytics delivery <acp_…> Die Lieferung einer Werbekampagne: je Buchung Zusage, Geliefertes, Erfüllung, Pacing, Prognose mit Spanne und der Befund GET /v1/analytics/campaigns/{id}/delivery · advertising.campaign.read ja nein

Ohne --from und --to gelten die letzten sieben Tage bis gestern; die Werbekampagne zeigt ohne Fenster ihre Laufzeit bis gestern. Die Tabelle nennt Stunden statt Sekunden und Prozent statt Anteil, und neben einem Wert steht seine Obergrenze, solange gemeldete Lücken noch nachkommen können. Welche Kennzahl sich mit welcher Dimension rechnen lässt, zeigt szenera api get /v1/analytics/catalog.

Nachweise

Befehl Zweck Route und Recht Schlüssel Verändert
proof list Die Nachweise der Organisation, die neuesten zuerst: Abschlüsse, Nachträge und Zwischenstände mit Nummer, Zeitraum, Werbekampagne, Buchung, gültigen Ausspielungen und Erfüllung. --campaign, --advertiser, --line, --kind, --from und --to schränken ein GET /v1/analytics/proofs · analytics.proof.read ja nein
proof show <prf_…> Ein Nachweis mit Prüfcode, Signatur und seinen Dateien samt Prüfsumme. Zahlen, Nachträge und den Stand jeder Zustellung zeigt --json GET /v1/analytics/proofs/{id} · analytics.proof.read ja nein
proof download <prf_…> --output=<pfad> Eine Datei holen: --kind=pdf (Vorgabe), csv, manifest oder capture mit --file=<pfi_…>. Stimmt die Prüfsumme nicht, wird die Datei wieder entfernt GET /v1/analytics/proofs/{id}/files/{kind} · analytics.proof.read ja nein

Mit Nummer und Prüfcode aus proof show prüft jeder einen Nachweis auf der Prüfseite, auch ohne Konto. Zwischenstände und Verweise für Werbepartner entstehen im Portal oder über die API.

Ereignis-Ziele

Befehl Zweck Route und Recht Schlüssel Verändert
webhook list Die Ereignis-Ziele der Organisation. --status=dead zeigt die, welche die Zustellung selbst aufgegeben hat (abgeschaltet und mit einer Fehlerkette über zwanzig) GET /v1/webhooks · webhook.list nein nein

Ein von Hand abgeschaltetes Ziel steht unter --status=disabled und ist etwas anderes. Angelegt und geändert werden Ziele im Portal oder über die API, siehe Einen Webhook-Endpunkt anlegen.

Team, Rollen und Erteilungen

Befehl Zweck Route und Recht Schlüssel Verändert
user list Die Mitglieder der Organisation. --last-login-before=<zeitpunkt mit Zone> findet ruhende Konten, auch nie angemeldete GET /v1/users · identity.user.list nein nein
user get <usr_…> Ein Mitglied im Einzelnen GET /v1/users/{id} · identity.user.read nein nein
user create --email=… --name=… --role=<rol_…> Ein Mitglied direkt anlegen (ohne Einladung), mit --password oder --federated POST /v1/users · identity.user.create nein ja
user update <usr_…> Profil eines Mitglieds ändern PATCH /v1/users/{id} · identity.user.update nein ja
user set-role <usr_…> --role=<rol_…> --reason=… Die Rolle eines Mitglieds setzen — sie ersetzt die bisherige PATCH /v1/users/{id}/roles · identity.user.assign-roles nein ja
user suspend <usr_…> --reason=… Ein Mitglied sperren POST /v1/users/{id}/suspend · identity.user.suspend nein ja
user reactivate <usr_…> Die Sperre eines Mitglieds aufheben POST /v1/users/{id}/reactivate · identity.user.reactivate nein ja
user delete <usr_…> --reason=<kategorie> --yes Ein Mitglied löschen. Der Grund ist eine der fünf Kategorien der API DELETE /v1/users/{id} · identity.user.delete nein ja
invitation list Die Einladungen der Organisation, mit --pending nur die offenen GET /v1/invitations · identity.invitation.list nein nein
invitation create --email=… --role=<rol_…> Jemanden in die Organisation einladen POST /v1/invitations · identity.user.invite nein ja
invitation resend <ivt_…> Eine Einladung noch einmal verschicken. Das verlängert die Frist POST /v1/invitations/{id}/resend · identity.user.invite nein ja
invitation revoke <ivt_…> Eine Einladung zurückziehen DELETE /v1/invitations/{id} · identity.invitation.revoke nein ja
role list Die Rollen der Organisation, eigene und eingebaute GET /v1/roles · access.role.list nein nein
role get <rol_…> Eine Rolle samt ihrer Rechte GET /v1/roles/{id} · access.role.read nein nein
role create --name=… --permissions=<a,b,c> Eine Rolle anlegen. Rechte sind exakte Katalog-Schlüssel, keine Platzhalter POST /v1/roles · access.role.create nein ja
role update <rol_…> Eine Rolle ändern. --permissions ersetzt die Liste, If-Match kommt aus der Fassung, ein Konflikt ist Exit 6 PATCH /v1/roles/{id} · access.role.update nein ja
role delete <rol_…> --yes Eine Rolle löschen. Mit Konten daran weist die API ab DELETE /v1/roles/{id} · access.role.delete nein ja
grant list Rechte, die an einzelnen Ressourcen hängen GET /v1/grants · access.grant.list nein nein
grant create --user=<usr_…> --resource-type=… --resource=… --permissions=… Ein Recht auf genau einer Ressource geben — oder mit --deny sperren POST /v1/grants · access.grant.create nein ja
grant revoke <grn_…> Eine Erteilung zurücknehmen DELETE /v1/grants/{id} · access.grant.revoke nein ja

Schlüssel

Befehl Zweck Route und Recht Schlüssel Verändert
api-key list Die eigenen Zugangsschlüssel, mit --organization alle Schlüssel der Organisation GET /v1/me/api-keys (nur Sitzung), mit --organization GET /v1/api-keys · identity.api-key.list nein nein
api-key issue --name=… --permissions=<a,b,c> Einen Schlüssel ausstellen — der Geheimwert erscheint genau einmal. --list-allowed zeigt die freigegebenen Rechte POST /v1/me/api-keys · identity.api-key.create nein ja
api-key rotate <akm_…> Einen Schlüssel erneuern — der alte gilt noch eine Gnadenfrist (0–72 Stunden) POST /v1/me/api-keys/{id}/rotate · identity.api-key.create nein ja
api-key revoke <akm_…> --yes Einen Schlüssel zurückziehen — sofort und endgültig. --compromised nennt im Protokoll den Verdacht, dass der Geheimwert in fremde Hände kam DELETE /v1/me/api-keys/{id} · identity.api-key.revoke nein ja

Ein Schlüssel kann nie mehr als sein Aussteller und nie ein Recht tragen, das für Schlüssel nicht freigegeben ist. Das Zweite prüft die CLI schon vor dem Aufruf.

Abonnement, Rechnungen und Apps

Befehl Zweck Route und Recht Schlüssel Verändert
subscription get Das Abonnement und die Lizenzlage der eigenen Organisation GET /v1/me/subscription · billing.subscription.read, GET /v1/me/licensing · billing.usage.read nein nein
subscription set-licenses --count=<n> Die Zahl gebuchter Lizenzen ändern, nicht unter die belegten PUT /v1/me/licensing/licenses · billing.subscription.update nein ja
subscription cancel --yes Das Abonnement kündigen — zum Periodenende, mit --immediately jetzt POST /v1/me/subscription/cancel · billing.subscription.update nein ja
subscription reactivate Eine vorgemerkte Kündigung zurücknehmen POST /v1/me/subscription/reactivate · billing.subscription.update nein ja
app subscribe <app> Eine bepreiste App zur Abrechnung buchen POST /v1/me/licensing/apps/{appId} · billing.subscription.update nein ja
app unsubscribe <app> --yes Eine gebuchte App kündigen, wirkt zum Periodenende DELETE /v1/me/licensing/apps/{appId} · billing.subscription.update nein ja
invoice list Die eigenen Rechnungen GET /v1/me/invoices · billing.invoice.read nein nein
invoice get <inv_…> Eine Rechnung samt Positionen. --pdf holt die Adresse des PDF GET /v1/me/invoices/{id} · billing.invoice.download nein nein
app list Die Apps im Store, mit --installed nur die installierten GET /v1/me/apps/store, kein eigenes Recht ja nein
app get <app> Eine App im Einzelnen: Rechte, Datenzugriff, Widgets GET /v1/me/apps/store/{appId}, kein eigenes Recht, nur Sitzung nein nein
app install <app> Eine App installieren. Der Manifest-Hash reist als Beweis mit GET /v1/me/apps/store/{appId} → POST /v1/marketplace/apps/{appId}/install · marketplace.app.install nein ja
app upgrade <app> --version=<semver> Eine installierte App auf eine andere Fassung wechseln POST /v1/marketplace/apps/{appId}/upgrade · marketplace.app.upgrade nein ja
app uninstall <app> Erst die Vorschau der Folgen, mit --yes die Deinstallation POST …/uninstall/preview → POST /v1/marketplace/apps/{appId}/uninstall · marketplace.app.uninstall nein ja
app accept <app> Das Update einer App annehmen. Der Befehl zeigt, wohin es führt und was dazukommt, angenommen wird mit --yes GET /v1/me/apps/{appId}/update → POST /v1/me/apps/{appId}/update/accept · marketplace.app.accept nein ja
app reject <app> --yes Das Update einer App ablehnen. Bis eine höhere Fassung erscheint, fragt die Plattform nicht wieder, mit Frist geht es nur bis zu ihr GET /v1/me/apps/{appId}/update → POST /v1/me/apps/{appId}/update/reject · marketplace.app.accept nein ja

Protokoll, Rechte-Katalog und Notausgang

Befehl Zweck Route und Recht Schlüssel Verändert
audit list Das Prüfprotokoll lesen — anhängend, Nutzlasten geschwärzt GET /v1/audit · audit.read oder audit.read.self (dann nur eigene Vorgänge) nein nein
audit get <aud_…> Einen Protokoll-Eintrag samt Nutzlast GET /v1/audit/{id} · audit.read oder audit.read.self nein nein
permission catalog Der Rechte-Katalog, wie ihn die laufende Umgebung kennt, mit --key-eligible die Freigabeliste GET /v1/permission-catalog, nur Anmeldung nicht belegt nein
api get <path> Ein GET auf einen beliebigen Pfad der API die Route des Pfads und ihr Recht je Route nein
api post <path> <body> Ein POST auf einen beliebigen Pfad, dazu --idempotency-key=<schluessel> die Route des Pfads und ihr Recht je Route ja
api put <path> <body> Ein PUT auf einen beliebigen Pfad, dazu --idempotency-key=<schluessel> die Route des Pfads und ihr Recht je Route ja
api patch <path> <body> Ein PATCH auf einen beliebigen Pfad, dazu --idempotency-key=<schluessel> die Route des Pfads und ihr Recht je Route ja
api delete <path> [body] Ein DELETE auf einen beliebigen Pfad, dazu --idempotency-key=<schluessel> die Route des Pfads und ihr Recht je Route ja

api … ist der Notausgang zu jeder Route, für die es keinen eigenen Befehl gibt. Der Pfad beginnt mit einem Schrägstrich und darf eine Abfrage tragen. Der Rumpf ist JSON direkt oder @datei.json. Auch dieser Weg geht durch den erzeugten Client — Kopfzeilen, Trace-Kennung und die Fehlerarten gelten wie überall —, prüft die Antwort aber nicht gegen einen Vertrag: Welches Schema zu einem frei getippten Pfad gehört, weiß niemand.

szenera api get "/v1/devices?limit=5" --json | jq -r '.items[].id'
szenera api post /v1/playlists @playlist.json --idempotency-key=import-2026-09-08-01

Weiterführendes