Dashboard-API

Eine Einladung prüfen, ohne sie zu verbrauchen. Meldet niemals Anmelde- oder Verifizierungsstatus, außer dass ein Anmelde-Reset replaces_unverified_account meldet. Eine organization_admin- oder organization_member-Einladung meldet den Namen der Organisation und kein Projekt.

Startet eine fünfminütige Registrierung, die an den Einladungshash und den Modus gebunden ist. Link create_login erfordert ein verifiziertes __Host-screenrig-signup-Cookie und verwendet dessen Namen.

Email create_login bindet den angegebenen Anzeigenamen; reset bindet die Zielperson, außer dass ein Reset einer nicht verifizierten Adresse den Passkey für die neue Person registriert, die er erstellt, benannt nach dem angegebenen Anzeigenamen oder, wenn dieser fehlt, nach der Adresse.

Dieses Zurücksetzen erfordert replace_unverified_account true (die Inspektion meldet replaces_unverified_account) und antwortet andernfalls mit 409 unverified_account_replacement.

Startet eine browsergebundene Link-Anmeldung und widerruft frühere Anmeldungen für diese Einladung. Die Verifizierungsherausforderung ist an diese Anmeldung gebunden. Entwicklungs-Authentifizierung verifiziert die Anmeldung sofort ohne Mail.

Gibt die Live-Anmeldung zurück, die zu diesem Browser gehört. Ein fehlendes, widerrufenes, verbrauchtes oder abgelaufenes Anmeldecookie gibt invitation_invalid zurück.

Akzeptiert eine Einladung transaktional und erstellt eine neue Personensitzung, wobei die alte Sitzung bei Vorhandensein gelöscht wird.

Link create_login benötigt das verifizierte __Host-screenrig-signup-Cookie für diese Einladung. signed_in benötigt eine Dashboard-Sitzung und eine kürzliche Anmeldung oder einen frischen Nachweis; die Zustellung per E-Mail benötigt eine passende verifizierte E-Mail oder die nicht verifizierte Adresse der angemeldeten Person, die durch das Annehmen verifiziert wird.

Eine Adresse, die bereits eine aktive Person besitzt, ob verifiziert oder nicht, ergibt für create_login resource_conflict. Ein Reset meldet die Person an, die eine verifizierte Adresse besitzt.

Ein Reset einer nicht verifizierten Adresse erfordert replace_unverified_account true (die Inspektion meldet replaces_unverified_account) und antwortet andernfalls mit 409 unverified_account_replacement und verbraucht nichts; damit erstellt der Reset eine neue verifizierte Person mit den Zugangsdaten, die er registriert, benannt nach display_name oder, wenn dieser fehlt, nach der Adresse, mit einer neuen Organisation und einem neuen Projekt, und meldet diese Person an; die nicht verifizierte Person wird gelöscht (ihre Sitzungen, Passkeys und Agenten enden), und die von ihr erstellten Projekte und Organisationen bleiben bestehen, ohne sie und ohne dass die Adresse noch ihr Kontakt ist, sodass kein späterer Reset ihnen erneut eine Einschreibe-Einladung sendet.

Die Antwort nennt das neue Projekt. Eine Sitzung, die eine E-Mail-Verifizierung verlangt (email_verification_required bei GET /api/session), akzeptiert nur eine per E-Mail gesendete Einladung, die ihre eigene Adresse nennt, und erhält für jede andere 403 email_verification_required.

Eine organization_admin-Einladung fügt die Person den Administratoren der Organisation hinzu und öffnet kein Projekt; sie ergibt organization_admin_limit, wenn die Organisation bereits 20 Administratoren hat (die Einladung bleibt dann ausstehend), und resource_conflict, wenn die Organisation gelöscht wurde.

Eine organization_member-Einladung setzt die Heimatorganisation der Person auf die einladende Organisation, unabhängig von einer früheren Heimatorganisation, und gewährt keine Projektmitgliedschaft; sie gibt managed_elsewhere (409) zurück, wenn eine andere Organisation die Person verwaltet, und resource_conflict, wenn die Organisation gelöscht wurde.

Eine organization_admin-Einladung setzt die Heimatorganisation nur bei einer Person ohne Heimatorganisation. Eine project_member-Einladung prüft die Gastrichtlinie der Organisation erneut und gibt guest_not_allowed (403) zurück, wenn die Person ein externer Gast wäre, den die Richtlinie ablehnt; eine Projekteinladung ändert nie die Heimatorganisation einer Person. Eine abgelehnte Einladung bleibt ausstehend.

Startet eine fünfminütige Registrierungszeremonie für eine Selbstregistrierung, gebunden an die normalisierte E-Mail-Adresse und den Anzeigenamen. Es wird nichts erstellt und keine E-Mail gesendet.

Eine Adresse, die eine aktive Person besitzt, ob verifiziert oder nicht, ergibt 409 account_exists; eine Adresse an einer Domain, deren Organisation sich über einen Identitätsanbieter anmeldet, ergibt 403 sso_required; eine ungültige Adresse oder ein ungültiger Name ergibt 400 invalid_request mit Feldfehlern. Ein Server mit Dashboard-Entwicklungs-Authentifizierung gibt passkeys_disabled zurück.

Pro Client-Adresse begrenzt.

Erstellt per Selbstregistrierung ein Konto und meldet diesen Browser an.

Eine Transaktion erstellt die Person mit einer nicht verifizierten E-Mail-Adresse und einer Verifizierungsfrist von 72 Stunden, registriert den Passkey aus der Zeremonie, die POST /api/signups/passkey-options gestartet hat, erstellt die Organisation und das Projekt der Person so, wie die Agent-Registrierung sie erstellt, macht die Person zum Projekteigentümer, speichert die Wahl zu Marketing-E-Mails und stellt die Verifizierungs-E-Mail in die Warteschlange (Zweck account_email).

Der Website-Besucher, der die Seite geöffnet hat, wird mit dem Konto verknüpft, und die Registrierung wird als signed_up gezählt. Die Antwort setzt das Dashboard-Sitzungscookie. Die Ablehnungen sind die von POST /api/signups/passkey-options; eine verwendete, abgelaufene oder nicht passende Zeremonie ergibt 400 invalid_request. Pro Client-Adresse und pro E-Mail-Adresse begrenzt.

Wechselt zu einem der Projekte der Person und aktualisiert die zuletzt verwendete Zeit. Ein Mitarbeiter kann auch zu einem Projekt wechseln, das er überwacht; diese Sitzung meldet shadow true, ist schreibgeschützt und aktualisiert keine zuletzt verwendete Zeit. Jedes andere Projekt gibt not_found zurück.

Mitglieder des aktuellen Projekts ohne deren private E-Mail-Adressen auflisten.

Jedes Mitglied hat gleiche Rechte außer der Mitgliederverwaltung (Entfernen, Genehmigungsrecht, Bereiche, Inhaberschaft), die dem Inhaber und einem Admin der Organisation des Projekts, der Mitglied ist, vorbehalten ist. owner markiert den Projektinhaber, external markiert einen Gast (die Heimatorganisation des Mitglieds ist nicht die Organisation des Projekts), und viewer_user_id und viewer_is_owner beschreiben die angemeldete Person.

Entfernt ein Mitglied aus dem aktuellen Projekt. Der Projektinhaber entfernt jedes andere Mitglied, ebenso ein Admin der Organisation des Projekts, der Mitglied ist; jedes Mitglied entfernt sich selbst, um zu gehen. Der Inhaber wird nie entfernt und verlässt nie (owner_cannot_leave; Inhaberschaft zuerst übertragen). Ein Mitglied, das jemand anderen entfernt, wird mit owner_required abgelehnt.

Eine Person, die kein Mitglied ist, auch eine bereits entfernte, ist not_found. In einer Transaktion endet die Mitgliedschaft, die ausstehenden E-Mail-Einladungen dieser Person zum Projekt werden widerrufen, und das Projektevent member.removed wird angehängt (Details user_id, removed_by_user_id, left).

Die Sitzungen der Person lösen das Projekt bei der nächsten Anfrage nicht mehr auf und fallen wie nach einer Projektlöschung zurück. Agentenmitgliedschaften sind getrennt und bleiben bestehen. Nur Personen; keine Bearer-Route.

Die Aktivität einer Person im aktuellen Projekt, neueste zuerst: ihre Anmeldungen (und abgelehnte Anmeldungen mit Adresse oder Passkey), Abmeldungen, Wechsel ins Projekt, Anmeldeänderungen, Reauthentifizierungsnachweise und jede Änderung, die sie über das Dashboard vorgenommen hat, inklusive abgelehnter und fehlgeschlagener. Lesevorgänge werden nie aufgezeichnet.

Agent- und CLI-Anfragen erfolgen über ihre Agenten (listDashboardAgentEvents). Der Schatten eines Mitarbeiters des Projekts zeichnet nichts auf; eine Änderung, die unter einer genehmigten Mitarbeiter-Schreibberechtigung vorgenommen wird, ist eine Zeile dieses Mitarbeiters mit Quellmitarbeiter.

Die Person selbst, der Eigentümer des Projekts, ein Admin der Organisations des Projekts und ein Mitarbeiter, der das Projekt überwacht, dürfen es lesen. Alle anderen erhalten not_found, ebenso eine Person, die weder Mitglied ist noch hier Zeilen hat, sodass die Antwort nie verrät, wer dazugehört; die Zeilen eines ehemaligen Mitglieds bleiben lesbar.

Das Projekt gehört zur Sitzung, niemals zur Anfrage, und es werden nur die Zeilen dieses Projekts zurückgegeben.

Jeder Wert ist serverseitig abgeleitet: die Aktion aus der Route, die der Server zugeordnet hat (oder eine benannte Kontoaktion wie session.sign_in oder passkey.add), die Ressource aus dem ersten Pfadwert der Route, wenn es sich um eine servergenerierte Kennung handelt, Status, problem_code und Fehler aus dem Problemregister, der Client aus dem User-Agent und Plattform-Hinweis (der rohe User-Agent wird nicht gespeichert).

Kein Anforderungstext, Passwort, Token oder Cookie wird gespeichert. client_ip und E-Mail werden wie aufgezeichnet angezeigt.

Paging sortiert nach (at, id) absteigend. Geben Sie next_cursor als after weiter, um fortzufahren; es ist am Ende null. Eine zwischenzeitlich geschriebene Zeile landet nur vor der ersten Seite und die Aufbewahrung entfernt die ältesten Zeilen, sodass ein Cursor niemals eine überlebende Zeile wiederholt oder überspringt. Ein fehlerhafter Cursor oder Filter wird mit invalid_request abgelehnt; ein Limit außerhalb von 1-100 ist Standard.

Zeilen verfallen nach dem Ereignisaufbewahrungszeitraum des Projekts zum Zeitpunkt ihrer Erstellung. recorded_since ist die Zeit der ältesten noch vorhandenen Zeile des Projekts oder, falls keine vorhanden, der Beginn der Aufzeichnung auf diesem Server; alles davor wird nicht rekonstruiert.

Gibt das Profil und die Anmeldeinformationen der angemeldeten Person zurück.

Archiviert die angemeldete Person. Nachweisgeschützt: Der Körper enthält einen frischen Anmeldebeweis, der gegen eine Reauthentifizierung geprüft wird, die an diese Sitzung gebunden ist mit Art account_delete und subject_id gleich der Benutzer-ID der angemeldeten Person (starten Sie sie mit POST /api/me/reauthentications). Ohne aktuelle Reauthentifizierung ist die Antwort reauthentication_required.

Bei Erfolg ist die Antwort 204, das Dashboard-Sitzungscookie wird gelöscht und der HTTP-Cache des Browsers für die Dashboard-Quelle wird wie beim Abmelden gelöscht.

Startet passkey Step-up, gebunden an Sitzung, Art und Subjekt. Eine Person ohne Passkey erhält resource_conflict und verwendet einen Passwortnachweis.

Setzt oder ersetzt das Passwort der Person nach frischem Nachweis. Das erste Passwort erfordert Passkey-Nachweis; der Ersatz akzeptiert das aktuelle Passwort oder einen Passkey. Widerruft andere Sitzungen und stellt eine Benachrichtigung über geänderte Anmeldung in die Warteschlange.

Eine Person, deren E-Mail-Adresse nicht verifiziert ist, etwa nach einer Selbstregistrierung vor der Verifizierung, kann kein Passwort festlegen und erhält 403 email_verification_required.

Listet die Passkeys der Person auf, mit allem, was ein Client braucht, um den Passwortmanager des Browsers mit ihnen synchron zu halten (die WebAuthn-Signal-API). Die Liste enthält die ID der vertrauenden Partei und das Benutzer-Handle, unter denen die Passkeys registriert sind, und jeder Passkey enthält seine Credential-ID und den Anbieter, den sein Authentifikator gemeldet hat.

Überprüft frischen Nachweis und startet eine Registrierung, die an die Sitzung und Person gebunden ist. Passkeys sind bei Entwicklungs-Authentifizierung deaktiviert.

Speichert den neuen Passkey, widerruft die anderen Sitzungen der Person und fügt eine Benachrichtigung über geänderte Anmeldung in die Warteschlange ein. Ein ohne Namen gesendeter Passkey wird nach seinem Anbieter benannt oder heißt Passkey, wenn sein Authentifikator keinen gemeldet hat, den die Liste kennt.

Benennt einen Passkey um, der der angemeldeten Person gehört.

Löscht einen Passkey nach frischem Nachweis und sendet eine Benachrichtigung über die Änderung der Anmeldung. Das Entfernen der letzten Anmeldemethode gibt last_credential zurück. Eine Person, deren Konto einen Passkey erfordert (jeder Mitarbeiter), kann ihren letzten Passkey nicht entfernen; dies führt zu 409 resource_conflict.

Gibt den verifizierten und ausstehenden E-Mail-Status der Person zurück. Eine Person, die sich selbst registriert hat, besitzt eine nicht verifizierte Adresse, bis sie den an diese gesendeten Link öffnet; email_verified ist false und verify_by ist die Frist, nach der die Sitzung nur noch die Routen verwenden darf, die die Adresse verifizieren oder ändern (email_verification_required bei GET /api/session).

Fordert eine E-Mail-Änderung nach frischem Nachweis an. Die verifizierte Adresse bleibt wirksam, solange die Verifizierung aussteht. Eine Adresse, die eine andere aktive Person besitzt, ob verifiziert oder nicht, ergibt user_email_conflict. Die alte Adresse erhält eine Warnung, keinen Rückgängig-Link.

Eine Person, deren Adresse nicht verifiziert ist, ändert sie auf dieselbe Weise; die Verifizierung der neuen Adresse macht sie zur verifizierten Adresse der Person und löscht verify_by.

Stellt einen neuen Verifizierungslink in die Warteschlange. Solange eine E-Mail-Änderung auf Verifizierung wartet (pending_email bei GET /api/me/email), ist es der Link dieser Änderung, gesendet an die ausstehende Adresse; andernfalls ist es ein account_email-Link für die aktuelle, nicht verifizierte Adresse der Person. Innerhalb von zehn Minuten nach dem letzten Link dieser Art wird nichts in die Warteschlange gestellt, und die Antwort bleibt 202.

Eine Person, deren Adresse verifiziert ist und die keine ausstehende Änderung hat, erhält 409 resource_conflict.

Ersetzt die Antworten, die die Person nach der Registrierung gegeben hat, durch den Body, der alle bisherigen Antworten enthält; ein ausgelassenes Mitglied oder null gilt als unbeantwortet. Jedes Mitglied hat einen geschlossenen Wertebereich, und ein Wert außerhalb davon ergibt 400 invalid_request mit einem Feldfehler.

Das Profil wird bei der Person gespeichert und Mitarbeitenden von screenRIG zusammen mit der Organisation angezeigt, in die sich die Person registriert hat.

Wo eine Anwendung (Web-App) im Projekt der Sitzung platziert ist, berechnet in einem Durchlauf über die Playlists des Projekts und mit einem Lesevorgang der Bildschirme, die sie verwenden. placements sind die Anwendungsprimitive, deren gespeicherter Anwendungseigentümer diese Anwendung ist, in der Reihenfolge von Playlist (Reihenfolge der Playlist-Liste), Seite und Primitiv; eine Playlist, die sie zweimal platziert, hat zwei. release gibt an, wie sich jedes angeheftete Release zu latest_ready_release der Anwendung verhält: latest, older oder unknown, solange sie keines hat. screens sind die Bildschirme mit dem Status pairing_pending oder active, die eine Playlist einer Platzierung als Standard haben, im Zeitplan führen, per Übernahme verwenden oder gerade anzeigen, neueste zuerst; archivierte Bildschirme zählen nie, und ein Bildschirm, dessen Player keine Web-Apps anzeigen kann, trägt applications_unsupported.

Ein auf Bildschirme beschränktes Mitglied oder ein ebenso beschränkter Agent (screen_scope) sieht nur die eigenen Bildschirme, und screen_count zählt nur diese. Das ist nicht die Löschsperre; die Löschsperre sind die Laufzeitberechtigungen (das Manifest eines Bildschirms, das ein Release enthält). Eine ID, die das Projekt nicht hat, ist not_found, wie bei getApplication. Die Antwort ist privat und no-store.

Wo ein fertiges Medium im Projekt der Sitzung verwendet wird, berechnet in einem Durchlauf über die Playlists des Projekts und mit einem Lesevorgang der Bildschirme, die sie verwenden. playlists sind jene, die die Datei nennen (die statischen IDs eines Bild- oder Video-Primitivs und ein Selektor nach id oder ids, der Fallback eines Streams, eine Zeichenkette media:<id> in den params einer Karte, das Logo eines Stingers, ein Track des Soundtracks), danach jene, deren Tag-, Ordner- oder all-Selektoren sie erreichen, jede Gruppe in der Reihenfolge der Playlist-Liste; eine Playlist ist ein Eintrag, dessen uses jede Art auflisten, die exakten Arten zuerst.

Selektoren werden so beurteilt, wie sie zur Laufzeit aufgelöst werden: Ein Tag-Filter passt auf tag und tags der Datei, ein Ordner-Selektor auf die Dateien direkt im Ordner, ein all-Selektor auf jede Datei dieser Art, und eine ausstehende Datei über ihre zuletzt genehmigten Tags und ihren Ordner (eine nie genehmigte Datei wird von keinem erreicht).

Rotation (batch_size, one_at_a_time), Verfügbarkeitsfenster, Seitenverhältnis-Anpassung und die Sichtbarkeit einer Seite werden nicht beurteilt. screens sind die Bildschirme mit dem Status pairing_pending oder active, die eine dieser Playlists als Standard haben, im Zeitplan führen, per Übernahme verwenden oder gerade anzeigen, neueste zuerst; archivierte Bildschirme zählen nie.

Ein auf Bildschirme beschränktes Mitglied oder ein ebenso beschränkter Agent (screen_scope) sieht nur die eigenen Bildschirme, und screen_count zählt nur diese. Eine ID, die das Projekt nicht hat, oder ein Medium, das nicht fertig ist, ist not_found, wie bei getMedia. Die Antwort ist privat und no-store.

Gibt ein kleines verlustbehaftetes WebP eines bereiten Bildes zurück, das dem Projekt der Sitzung gehört, damit die Raster im Dashboard nie Originale dekodieren. Es gibt eine Größe: Sie passt in 512 x 512 bei Erhalt des Seitenverhältnisses und wird nie hochskaliert; ein animiertes Bild zeigt seinen ersten Frame.

Die erste Anfrage erzeugt sie und speichert sie neben dem Original; spätere Anfragen streamen die gespeicherte Kopie, und das Löschen der Medien entfernt sie mit dem Original. Eine andere Projektkennung, Video, Audio und Medien, die nicht bereit sind, liefern not_found. Range wird nicht akzeptiert.

Der ETag ist stark und benennt den Original- und den Thumbnail-Generator, sodass er bei jeder Anfrage und jedem Host gleich ist. Die Antwort ist privat, no-cache, und ein If-None-Match, der übereinstimmt, geprüft nachdem das Medium im Projektsitzungskontext aufgelöst wurde, liefert 304 ohne das Thumbnail zu lesen. Abgeschlossene Bytes werden als dashboard_media-Ausgang erfasst.

Wendet dieselben Besitz-, Bedingungs- und Generierungsregeln wie getDashboardMediaThumbnail an und gibt dessen Header ohne Body zurück. Kein Datenabfluss wird protokolliert.

Scanner-sichere Verifizierungsansicht. Sie verifiziert niemals eine Adresse, verändert keinen Benutzer und meldet den Besucher nicht an. Sie gibt den Zweck und den Zustand des Links zurück; ein ausstehender account_email-Link verifiziert nur bei einer Anfrage mit der Dashboard-Sitzung der Person, daher verlangt eine Seite zuerst die Anmeldung und bittet erst danach um die Bestätigung.

Explizite menschliche Bestätigung verbraucht eine zweckgebundene Verifizierungsherausforderung. Link-Anmeldeherausforderungen erfordern das passende __Host-screenrig-signup-Cookie; E-Mail-Änderungsherausforderungen sind tokengebunden, sodass der Link in jedem Browser funktioniert.

Eine account_email-Herausforderung (per E-Mail bei der Selbstregistrierung und durch POST /api/me/email/verification gesendet, 30 Tage gültig) öffnet sich in jedem Browser, verifiziert aber nur für eine Anfrage mit einer aktiven Dashboard-Sitzung der Person, für die der Link bestimmt ist, auch mit einer Sitzung, die email_verification_required auf diese Route beschränkt.

Ohne Sitzung oder mit der Sitzung einer anderen Person antwortet sie mit 200 sign_in_required, verifiziert nichts und lässt den Link verwendbar. Ein verifizierter account_email-Link markiert die Adresse der Person als verifiziert und beendet die Verifizierungsfrist; sie antwortet mit superseded, wenn zuvor eine andere Person dieselbe Adresse verifiziert hat. Die Verifizierung meldet den Besucher niemals an.

Startet eine benutzerlose WebAuthn-Bestätigungszeremonie und gibt die Anforderungsoptionen unverändert für navigator.credentials.get zurück. Es wird kein Cookie benötigt, und keine allowCredentials-Liste wird veröffentlicht, sodass die Route nichts über existierende Benutzer oder Anmeldeinformationen verrät. Die Zeremonie läuft mit DashboardCeremonyTTL von fünf Minuten ab.

Wenn der Server die Dashboard-Entwicklungs-Authentifizierung ausführt, gibt diese Route passkeys_disabled zurück.

Überprüft eine benutzerlose Assertion und erstellt das Dashboard-Session-Cookie für den Benutzer, den die auffindbare Anmeldeinformation identifiziert. Kein Cookie authentifiziert die Anfrage. Eine unbekannte, abgelaufene oder bereits verwendete Zeremonie gibt passkey_invalid zurück, ebenso eine Assertion, die die vertrauende Partei nicht verifizieren kann, oder ein Anmeldezähler, der rückwärts läuft.

Eine gültige Zeremonie, deren Credential-Kennung bei niemandem registriert ist (keine gespeicherte Anmeldeinformation irgendeiner Person hat sie), gibt stattdessen 401 passkey_unknown zurück; diese Antwort gilt nur für diesen einen Fall, sodass ein Client den Browser bei ihr und bei nichts sonst anweisen darf, die Anmeldeinformation zu vergessen (PublicKeyCredential.signalUnknownCredential).

Die Credential-Kennung ist für sich allein keine Autorisierung: die signierte Assertion ist es. Eine Person, deren verifizierte Adresse an einer Domain liegt, deren Organisation Single Sign-on verlangt, wird mit 403 sso_required abgelehnt, es sei denn, sie ist Break-Glass-Administrator dieser Organisation; eine solche Anmeldung wird protokolliert.

Wenn der Server die Dashboard-Entwicklungs-Authentifizierung ausführt, gibt diese Route passkeys_disabled zurück.

Meldet die Person an, die durch verifizierte E-Mail und Passwort identifiziert wurde. Unbekannte E-Mail, kein Passwort und falsches Passwort geben dieselbe nicht autorisierte Antwort zurück. Öffnet das zuletzt verwendete Projekt, wenn noch eine Mitgliedschaft besteht, sonst die jüngste Mitgliedschaft oder kein Projekt.

Eine Adresse an einer Domain, deren Organisation Single Sign-on verlangt, wird mit 403 sso_required abgelehnt, bevor ein Konto gesucht wird, sodass die Antwort nicht davon abhängt, ob eine Person die Adresse besitzt; POST /api/sso/starts meldet diese Person über ihren Identitätsanbieter an.

Die Anmeldung per Passwort benötigt eine verifizierte E-Mail, daher meldet sich eine Person, die sich selbst registriert hat (POST /api/signups), mit ihrem Passkey an, und wer ein Passwort für eine nicht verifizierte Adresse festgelegt hat, erhält weiterhin die Antwort unauthorized. Die Entwicklungs-Authentifizierung verwendet denselben Passwortablauf.

Gibt die aktuelle Dashboard-Sitzung zurück. Das Sitzungscookie und die serverseitige Sitzung stellen die Autorität her; user_id ist beschreibend. Eine 401-Antwort bedeutet, dass eine Anmeldung erforderlich ist.

Das Feld dev_auth ist für die lokale Entwicklung reserviert und auf dem gehosteten Dienst falsch. organization ist die Heimatorganisation der Person und fehlt, solange sie keine hat; project.organization_admin gibt an, dass die Person Admin der Organisation des aktuellen Projekts ist.

Löscht die serverseitige Sitzungszeile und setzt das Sitzungscookie außer Kraft. Der Benutzer wird nicht gelöscht und es werden keine Anmeldeinformationen entfernt. Es ist von Natur aus idempotent und benötigt keinen Idempotency-Key.

Ein erfolgreicher Abmeldevorgang löscht auch den HTTP-Cache des Browsers für die Dashboard-Origin und entfernt die privaten, nicht zwischengespeicherten Medien-, Screenshot- und Anzeigenüberprüfungs-Bytes, die die Sitzung angesehen hat; eine Sitzung, die nur abläuft, lässt sie, bis der Browser sie entfernt.

Meldet einen Schritt des Durchlaufs eines Browsers durch die Einstiegsabläufe des Dashboards (Registrierung, Anmeldung, Zurücksetzen, Einladung und Hinzufügen eines Passkeys) für die Onboarding-Auswertung der Mitarbeiter. Öffentlich: funktioniert mit und ohne Dashboard-Sitzung.

Die Journey ist die eigene zufällige ID des Browsers; der Server speichert außerdem das Edge-Besucher-Cookie, wenn die Anfrage eines mitbringt, sowie die Person und die Organisation, wenn eine Sitzung sie mitbringt. Eine Journey ist nur für Mitarbeiter einsehbar und speichert die echten Werte, die Personen eingegeben haben (Adressen, Namen, Antworten); sie erhält nie ein Passwort, einen Code oder ein Token.

Der erste Wert von mode, source, utm_source, utm_medium, utm_campaign, click_kind, site_trail und site_cta bleibt erhalten; jeder Schritt behält seinen ersten Zeitpunkt, während value und detail eines Schritts sowie die E-Mail der Journey (aus email_submitted) jeweils die neuesten sind. source wird nur mit entry_viewed akzeptiert. question ist bei den Schritten question_* erforderlich und bei allen anderen abgelehnt. detail ist ein Problemcode für einen Schritt *_failed, die Anmeldemethode für signed_in oder connected bzw. skipped für signup_finished. email_verified, email_gate_reached, site_visited, site_cta_clicked und die Konto-Meilensteine werden vom Server geschrieben oder abgeleitet und hier abgelehnt.

Nur Längen sind begrenzt. Pro Client-Adresse begrenzt.

Alle ausstehenden, aktiven, widerrufenen, stornierten und abgelaufenen Agenten des Sitzungsprojekts mit sicheren Installationsmetadaten, letzter Nutzung, authentifizierter Anforderungsanzahl und direkt zurechenbaren gemessenen Credits auflisten. Keine Träger-, Empfängerschlüssel-Bytes, Umschläge oder Projektkennungen werden zurückgegeben.

Die Historie dieses Agenten, neueste zuerst, als EIN Datensatz pro Auslöser. Sie enthält sowohl die Anfrage des Agenten als auch die daraus resultierenden Änderungen. Eine Anfrage, die etwas geändert hat, ist ihr Domain-Ereignis, versehen mit dem Befehl, der es verursacht hat. Eine Anfrage, die nichts geändert hat – abgelehnt, fehlgeschlagen oder ein ereignisloser Erfolg – ist ein agent.command-Ereignis.

Es gibt keinen separaten Befehlsendpunkt; das Anzeigen desselben Triggers auf zwei Panels war der Fehler, den dies ersetzt hat. Lebenszyklusereignisse für diesen Agenten sind enthalten. Worker-, Player- und Dashboard-Aktivitäten werden nie als Agentenaktivität interpretiert. Zwei Anfragen sind zwei Trigger. Ein erneuter Versuch nach einer Ablehnung ist ein zweiter Datensatz, niemals eine Umschreibung des ersten.

Lesevorgänge werden nicht aufgezeichnet, da sie nichts ändern und ein Polling-Agent jede echte Aktion begraben würde. Anonyme Einschreibungen sind ausgeschlossen. Jeder Teil des Befehlsstempels stammt von der Route, die dieser Server zugeordnet hat, oder aus dem Problemregister.

Es gibt keinen Argumentvektor, keinen Anfrage-Body, keinen Header und keinen Freitext in einem Datensatz, daher muss nichts geschwärzt werden und kein Aufrufer kann gewählten Text in eine für Operatoren sichtbare Oberfläche schreiben. Ressourcen-IDs erscheinen, weil eine ID niemals eine Autorisierung ist und bereits in Ereignissen veröffentlicht wurde. Paging-Schlüssel nach Sequenz, absteigend.

Geben Sie den zurückgegebenen next_cursor als after weiter, um fortzufahren. next_cursor ist leer, wenn die Seite kurz ist, was das Ende der Historie bedeutet: Ein gleichzeitiges Anhängen nimmt nur eine höhere Sequenz ein, und die Aufbewahrung entfernt zuerst die niedrigsten Sequenzen, sodass ein Cursor niemals einen vorhandenen Datensatz dupliziert oder überspringt. Offset-Paging wird nicht unterstützt.

Jeder Suchparameter ist ein exaktes Übereinstimmungs- oder Bereichsprädikat für einen servergeschriebenen Token. Ein fehlerhafter Cursor- oder Filterwert wird mit invalid_request abgelehnt. Ein Limit außerhalb von 1-200 wird auf den Standardwert begrenzt, anstatt abgelehnt zu werden. Datensätze verfallen im eigenen Ereignis-Aufbewahrungszeitraum des Projekts.

Trennt den Agenten nach frischem Nachweis vom ausgewählten Projekt. Das Projekt muss eine der Mitgliedschaften der Person sein. Ausstehende Verbindungen und Ausstellungen von Zugangsdaten werden abgebrochen; es wird kein Ersatz-Token ausgestellt. Ein auf Bildschirme beschränktes Mitglied verbindet keine Agenten, stellt keine Zugangsdaten aus und verwaltet nicht die Personen des Projekts: outside_screen_scope (den Projektinhaber fragen).

Die Notizen, die dieser Agent im Projektsitzung geschrieben hat, neueste zuerst, offen und erledigt. state ist all (Standard), open oder resolved. Geben Sie next_cursor als after zurück; er ist auf der letzten Seite leer. Notiztexte sind reiner Text, geschrieben von einem Agenten; rendern Sie sie als Text, niemals als HTML oder Markdown.

Löst eine der offenen Notizen des Agenten als angemeldete Person mit einem erforderlichen Grund auf; resolution.by benennt die Person. Fügt note.resolved mit der Person als Akteur hinzu. Eine aufgelöste Notiz ist note_not_open.

Löscht eine der Agenten-Notizen, offen oder gelöst, als angemeldete Person. Hängt note.deleted mit der Person als Akteur an.

Die ausstehenden Verbindungsanfragen, die an das Sitzungsprojekt gerichtet sind und die ein Mitglied überprüfen und genehmigen kann: Anfragen, die das Projekt benennen, und Geräteanmeldungen oder Verbindungen durch eine Agentenidentität, die bereits Mitglied ist.

Das Anmelden einer neuen Installation wird nicht aufgelistet (dessen Projekthinweis wird vom Client geliefert); eine Person erreicht es über den Benutzer-Code (POST /api/agent-connections/lookup).

Löst den Benutzer-Code einer ausstehenden Geräteanmeldung (`screenrig login`), wie auf der Verbindungsseite eingegeben oder vorausgefüllt, in dessen Verbindung auf, deren Genehmigungsansicht ihn dann anzeigt. Genehmigt nichts. Trennzeichen, Leerzeichen und Groß-/Kleinschreibung werden ignoriert. Ein unbekannter, bereits verwendeter oder ungültiger Code ist agent_connection_invalid; ein abgelaufener agent_connection_expired.

Begrenzt auf 5 Abfragen pro Dashboard-Sitzung je 10 Minuten, 20 pro Client-Adresse und Stunde und 1200 pro Stunde flottenweit (rate_limited). Ein auf Bildschirme beschränktes Mitglied verbindet keine Agenten, stellt keine Zugangsdaten aus und verwaltet nicht die Personen des Projekts: outside_screen_scope (den Projektinhaber fragen).

Gibt sichere Verbindungsüberprüfungs-Metadaten zurück. Die Überprüfung wählt kein Projekt aus; die Genehmigung wählt eine der Mitgliedschaften der Person aus.

Genehmigt die Verbindung für das ausgewählte Projekt nach frischem Nachweis und erstellt einen ausstehenden Agenten. Das Projekt muss eine der Mitgliedschaften der Person sein. Gibt sichere Metadaten zurück, nie den Bearer. Ein auf Bildschirme beschränktes Mitglied verbindet keine Agenten, stellt keine Zugangsdaten aus und verwaltet nicht die Personen des Projekts: outside_screen_scope (den Projektinhaber fragen).

Lehnt die Verbindung für das ausgewählte Projekt nach frischem Nachweis ab, ohne einen Agenten zu erstellen. Das Projekt muss eine der Mitgliedschaften der Person sein. Ein auf Bildschirme beschränktes Mitglied verbindet keine Agenten, stellt keine Zugangsdaten aus und verwaltet nicht die Personen des Projekts: outside_screen_scope (den Projektinhaber fragen).

Eine Anfrage für die Dashboard-Shell.

Jedes Mitglied ist der Body, mit dem die genannte Route für genau diese Sitzung antwortet (GET /api/me/email, /api/support/status, /api/projects, /api/organizations, /api/project, /api/project/capabilities, /api/advertising/network, /api/alerts?state=open&limit=1 und /api/reviews?state=all&limit=1), erzeugt vom eigenen Handler dieser Route unter ihren eigenen Autorisierungs-, Plan- und Bereichsprüfungen.

Ein Mitglied fehlt, wenn seine Route für diese Sitzung nicht mit 2xx antworten würde (eine Ablehnung, eine Rolle oder ein Plan ohne Lesezugriff darauf, kein aktuelles Projekt, ein Fehler), und das Dashboard liest diese Route dann selbst. advertising_network ist null, wenn seine Route mit 404 not_found antworten würde, weil das Projekt kein Netzwerk hat.

Eine Sitzung ohne aktuelles Projekt erhält die Mitglieder, die keines benötigen.

Projekt-Netzwerkstatuszähler für das Projektsitzung. Online-Bildschirmzähler werden aus Live-gekoppelten Laufzeit-Ereignisströmen abgeleitet, dieselbe Ableitung, die Screen.online veröffentlicht; sie sind kein gespeicherter boolescher Wert und kein Player-Heartbeat. Medienbytes sind nur die dauerhaften Bytes von bereiten Medien.

Wahrer Auszahlungsfähigkeitsstatus. rails_available ist falsch und unavailable_reason ist financial_rails_unavailable, während Karten-, Steuer- und Barauszahlungswege nicht verfügbar sind. Es werden keine rohen Bankdaten zurückgegeben.

Ein finalisiertes Beleg-/Steuerdokument, das dem Anrufer gehört. Es existiert kein Beleg, solange die Geldsammlung nicht versandt ist, daher ist dies not_found statt eines erfundenen Dokuments.

Gibt das öffentliche Guthaben des Sitzungsprojekts in ganzen Credits zurück. Diese cookie-authentifizierte Abfrage belastet nie, daher bleibt sie bei null verfügbar. Das nur mit Cookie arbeitende Dashboard präsentiert nie einen Projekt-Bearer für GET /api/project.

Erstellt ein einmaliges, dreißig Sekunden gültiges Startticket für die neueste verfügbare Version einer Anwendung, die zum Projekt der Sitzung gehört, auf dem genauen Vorschauhost dieser Version, niemals auf dem Release-Host, den Player einrahmen, sodass Player und Dashboard im selben Browser nie die zwischengespeicherten Dokumente dieses Hosts teilen oder Cookies gewähren.

Das Ticket wird nur auf diesem Host in das Release-Grant-Cookie umgewandelt, daher ist die Vorschau per Konstruktion Cross-Origin und Webanwendungscode kann niemals ein Dashboard-Cookie lesen. Die Antwort release_id benennt genau das Release, das für diesen Start ausgewählt wurde, auch wenn später eine weitere Veröffentlichung abgeschlossen wird. Weisen Sie launch_url iframe.src zu und sonst nichts.

Die Autorität hier ist die Eigentümer-Autorität: Das Projekt der Sitzung besitzt die Anwendung. Dies ist eine absichtlich zweite Autoritätsquelle neben der exakten aktuellen Manifest-Autorität für screenrig.webapp-package/v1 und ist auf diese Operation beschränkt. Verallgemeinern Sie sie nicht auf Medien oder geschützte Laufzeitinhalte.

Es gibt keinen übergeordneten Player, daher schlagen das Browser-SDK und die Key-Value-Bridge geschlossen fehl, und die Vorschau ist nur eine Präsentation. Eine Anwendung ohne bereites Release ist resource_conflict.

Eine Organisation so, wie ein Eintrag von GET /api/organizations sie dem Aufrufer zeigt, mit admin, home und reseller. Eine angemeldete Person liest sie, wenn sie sie verwaltet, den Reseller verwaltet, an den sie delegiert ist, zu den Mitarbeitern gehört oder sie in dieser Liste sehen würde (Mitglied eines ihrer aktiven Projekte, oder es ist ihre Heimatorganisation).

Alle anderen und eine Organisation, die nicht existiert, erhalten 404 not_found. Gewährt keine Projektmitgliedschaft. Nur Cookie-Sitzungen; eine Agenten-Anmeldeinformation wird abgelehnt.

Organisations-Admins lesen nur Projektnamen, Inhaber, Status und Bildschirmanzahl; dies gewährt keinen Projektzugang. Ein Admin liest die Inhalte eines Projekts erst nach dem Beitritt (POST .../projects/{project_id}/access) und verwaltet dessen Personen mit den Routen für Inhaber und Mitglieder unten.

Die aktiven Reseller, deren Organisation die angemeldete Person verwaltet (admin_user_ids), sortiert nach Name; für alle anderen leer. Nur Cookie-Sitzungen. Ein Reseller ist eine Organisation, die Mitarbeiter zum Reseller gemacht haben oder die einer ihrer Admins registriert hat (POST /api/resellers); seine Admins betreiben die Organisationen seiner Kunden (docs/resellers.md).

Ein Admin einer Organisation macht sie sofort zum Reseller. Der Aufrufer muss eine angemeldete Person mit verifizierter E-Mail-Adresse sein (nur Cookie-Sitzungen; Agenten und Dienstclients haben nie Reseller-Berechtigung) und Admin der durch organization_id benannten Organisation; alle anderen erhalten 404 not_found.

Der Reseller startet mit 2000 Basispunkten des Listenpreises (20%), ab sofort gültig, und wartet auf die Prüfung; er kann bis zu 10 aktuelle Kunden anlegen (customer_limit), bis screenRIG ihn prüft. Die Organisation muss aktiv sein, darf nicht bereits ein Reseller und nicht Kunde eines Resellers sein und nicht im Mitarbeiter- oder Promo-Plan liegen (409 reseller_conflict, das Detail nennt den Grund).

Hängt reseller.enrolled an das Organisations-Audit an.

Ein Reseller, den der Aufrufer verwaltet, mit seiner Marge. Alle anderen erhalten 404 not_found.

Die aktuellen Kunden des Resellers (an ihn delegierte Organisationen), sortiert nach Name, mit Plan, Anzahlen und gespeicherten Bytes. Nur Reseller-Admins; alle anderen erhalten 404 not_found.

Erstellt eine Kundenorganisation, die von Anfang an an den Reseller delegiert ist, im Plan Standard, mit dem aufrufenden Reseller-Admin als ihrem einzigen Admin. Die Heimatorganisation des Aufrufers ändert sich nicht. Die eigenen Admins der Organisation können die Delegation später beenden (DELETE /api/organizations/{org_id}/reseller).

Hängt organization.created und reseller.customer_started an das Organisations-Audit an. Ein Reseller, der auf die Prüfung wartet (review_state pending), kann bis zu customer_limit aktuelle Kunden anlegen; darüber hinaus lautet die Antwort 409 reseller_conflict.

Ein aktueller Kunde des Resellers. Nur Reseller-Admins; eine Organisation, die kein aktueller Kunde ist, antwortet mit 404 not_found.

Legt den Plan eines aktuellen Kunden fest, für den der Reseller zahlt. standard entfernt den Plan; plus und premium sind immer erlaubt, education nur für eine Organisation, die für education berechtigt ist. Enterprise, staff und promo werden von Mitarbeitern zugewiesen.

Ein Upgrade gilt sofort, ein Downgrade oder eine Entfernung zum nächsten UTC-Monatswechsel, wie bei Planänderungen von Organisationen (docs/billing-rollup.md). Hängt reseller.customer_plan an das Organisations-Audit an.

Die aktiven Projekte eines aktuellen Kunden mit Namen, Status, Bildschirmanzahl und der Angabe, ob der Aufrufer bereits Mitglied ist. Das Auflisten gewährt keinen Projektzugriff; POST .../access tritt einem Projekt bei.

Macht den aufrufenden Reseller-Admin zum vollwertigen Mitglied des Projekts eines aktuellen Kunden (can_approve, keine Bereiche, Quelle reseller_admin), wie der Beitritt eines Organisations-Admins, sodass er es mit PUT /api/session/project öffnen kann. Ist er bereits Mitglied, antwortet es mit dem unveränderten Projekt.

Hängt member.added_by_reseller an das Projekt und reseller.project_joined an das Organisations-Audit an und schickt dem Inhaber des Projekts eine E-Mail. Die Mitgliedschaft bleibt bis zur Entfernung bestehen; das Beenden der Delegation entfernt sie nicht.

Was der Reseller für einen UTC-Monat schuldet. Eine Zeile pro Kunde, der im Monat zu irgendeinem Zeitpunkt delegiert war, mit dem Teil seiner Nutzungsgebühren im delegierten Teil des Monats, den sein eigenes Guthaben nicht gedeckt hat (zum Listenpreis und zum Preis des Resellers), und dem Jahrespreis seines Plans.

Der Preis des Resellers ist der Listenpreis abzüglich der Marge, die zum späteren der beiden Zeitpunkte gilt: Monatsbeginn und (Neu-)Anlage des Resellers. Nur Reseller-Admins.

Ein Admin der Organisation beendet deren Delegation an ihren Reseller sofort. Ab dann zahlt die Organisation für sich selbst; ihr Plan, ihre Projekte und ihre Mitglieder bleiben unverändert, einschließlich der Mitgliedschaften, die Reseller-Admins innehaben. Der Mehrverbrauch, den ihr Wallet während der Delegation aufgelaufen ist und der dem Reseller berechnet wird, wird in derselben Änderung abgeschrieben.

Hängt reseller.customer_ended an das Organisations-Audit an. Eine Organisation ohne Reseller antwortet mit 404 not_found.

Projekte an anderen Orten, deren Eigentümer eine verifizierte E-Mail mit exakt derselben verifizierten Domain haben. Kontaktadressen und Subdomains stimmen nicht überein, und Administratoren können Projekte nicht hereinholen.

Öffnen Sie eine 7-tägige DNS TXT-Herausforderung für eine Domain, die die ausstehende Herausforderung dieser Domain ersetzt; die anderen Domains der Organisation bleiben unverändert. Platzieren Sie den genauen Wert an seinem zurückgegebenen DNS-Namen und lassen Sie ihn dort. Eine Organisation hält höchstens 20 Domains, verifiziert und ausstehend zusammen (resource_conflict). Eine Domain, die eine andere Organisation hält, ist resource_conflict.

Eine Domain, die diese Organisation bereits besitzt, kann erneut nachgewiesen werden, was den neuen Wert für die tägliche DNS-Prüfung aufzeichnet.

Überprüfen Sie eine nicht abgelaufene Challenge gegen DNS und fügen Sie deren Domain der Organisation hinzu, zusätzlich zu den Domains, die sie bereits besitzt. Jede exakte Domain gehört zu einer Organisation. Ein während der Abfrage gedrehter Nachweis wird abgelehnt. Belassen Sie den TXT-Eintrag; eine tägliche Prüfung entfernt eine Domain, deren Eintrag sieben Tage lang fehlt.

Sobald die Beanspruchung abgeschlossen ist und im Hintergrund nach dieser Antwort, wird jedes Projekt, dessen Eigentümer eine verifizierte Person mit genau dieser Domain ist und das allein in der persönlichen Organisation dieses Eigentümers sitzt, in diese Organisation verschoben (bei Namenskonflikt umbenannt in "<name> (<owner>)").

Projekte in anderen Organisationen, Projekte mit eigenem kundenbezahltem Plan und Projekte, die ihr Eigentümer oder Personal aus einer Domain-Organisation verschoben hat, bleiben dort; ein Projekt, das die Organisationsgrenzen ablehnt, wird einen Tag später erneut versucht. Die Platzierung gewährt keinen Zugriff.

Ein designierter Administrator liest die Administratoren der Organisation, die Kandidaten, die einer werden können (verifizierte, aktive Eigentümer ihrer Live-Projekte, die noch keine Administratoren sind) und die Organisationsrevision. Alle anderen werden wie bei anderen Admin-Routen der Organisation abgelehnt. Nur Personen; Agenten und Bearer-Anmeldeinformationen haben keine Admin-Route.

Ein designierter Administrator ersetzt die Administratoren der Organisation. If-Match enthält die Organisationsrevision; eine veraltete führt zu revision_conflict mit current_revision. Das Set benennt 1 bis 20 Personen, jede ein aktueller Administrator oder Kandidat, sonst invalid_request; ein Administrator entfernt sich nur, wenn mindestens ein anderer Administrator verbleibt.

Die Änderung erhöht die Revision, wird im Organisations-Audit protokolliert, gewährt keine Projektmitgliedschaft und gibt dieselbe Form wie GET zurück. Nur Personen; Agenten und Trägeranmeldeinformationen haben keine Admin-Route.

Ein benannter Admin liest die Personen der Organisation. Nur lesend. projects listet die Live-Projekte der Organisation, sortiert nach Name, maximal 500. people ist die Vereinigung der Heimatmitglieder der Organisation (member true), der aktiven Mitgliedschaften dieser Projekte (ausgesetzte Mitgliedschaften ausgeschlossen) und der benannten Admins.

Die Reihenfolge ist: zuerst Admins, dann Heimatmitglieder, dann externe Personen (die keine Heimatmitglieder sind), jede Gruppe nach Anzeigename, dann E-Mail.

Jede Person trägt ihre Rolle in jedem Projekt (owner oder member), ob sie dort Überprüfungen genehmigen kann (can_approve) und ob sie auf Bildschirme oder Uploads beschränkt ist (limited), ob sie ein Admin ist, ob sie ein Heimatmitglied ist (member), ob die Organisation sie verwaltet (managed) und, bei einer externen Person, ob die aktuelle Gastrichtlinie sie nicht zulassen würde (outside_guest_policy).

Ein Admin oder Heimatmitglied in keinem Projekt erscheint mit leerer Projektliste. email ist leer für eine Person, deren Adresse nicht verifiziert ist. Deaktivierte Personen und Agenten erscheinen nie. Es werden höchstens 500 Personen zurückgegeben, Admins immer darunter; truncated ist wahr, wenn Personen, Projekte oder Mitgliedschaften ausgelassen wurden.

Alle anderen werden wie auf den übrigen Admin-Routen der Organisation abgelehnt. Nur Personen; Agenten und Bearer-Anmeldeinformationen haben keine Route.

Ein designierter Administrator listet die Administrator-Einladungen der Organisation nach ID, 50 auf einmal, nachdem abgelaufene entfernt wurden. Empfängeradressen sind für die Administratoren der Organisation sichtbar, die sie bereitgestellt haben. Tokens und Anmelde-URLs werden nie gelistet. Nur Personen; Agenten und Bearer-Anmeldeinformationen haben keine Admin-Route.

Ein designierter Administrator lädt Personen per E-Mail ein, Administratoren zu werden. Die Annahme fügt die Person den Administratoren der Organisation hinzu und erstellt deren Login, falls noch keines besteht; es gewährt keine Projektmitgliedschaft. Maximal 20 Administratoren einschließlich ausstehender Einladungen (organization_admin_limit); eine Adresse, deren Person die Organisation bereits verwaltet, ist invalid_request.

E-Mail-Einladungen verfallen nach sieben Tagen; eine ausstehende Einladung an dieselbe Adresse wird wiederverwendet. Die Namen der Organisation und des Einladenden müssen für E-Mails geeignet sein. Nur Personen; Agenten und Träger-Anmeldeinformationen haben keinen Admin-Zugang.

Ein benannter Administrator widerruft eine ausstehende Administrator-Einladung und gibt den Administrator-Platz frei. Eine bereits widerrufene Einladung gibt 204 zurück; eine angenommene gibt invitation_consumed zurück; eine ID, die die Organisation nicht besitzt, ist not_found. Nur Personen; Agenten und Inhaber-Anmeldeinformationen haben keine Administrator-Route.

Ein benannter Admin listet die Mitgliedseinladungen der Organisation nach ID auf, 50 auf einmal, nachdem die Einladungen mit verstrichener Frist als abgelaufen gesetzt wurden. Empfängeradressen sind für die Admins der Organisation sichtbar, die sie angegeben haben. Tokens und Anmelde-URLs werden nie aufgelistet. Nur Personen; Agenten und Bearer-Anmeldeinformationen haben keine Admin-Route.

Ein benannter Admin lädt Personen per E-Mail ein, der Organisation als Mitglieder beizutreten. Die Annahme setzt die Heimatorganisation der Person auf diese Organisation, unabhängig von einer früheren Heimatorganisation, und erstellt deren Login, falls noch keines besteht; sie gewährt keine Projektmitgliedschaft.

Eine Adresse, deren Person bereits Heimatmitglied der Organisation ist, ist invalid_request; eine Adresse, deren Person eine andere Organisation verwaltet, ist managed_elsewhere. E-Mail-Einladungen verfallen nach sieben Tagen; eine ausstehende Einladung an dieselbe Adresse wird wiederverwendet. Die Namen der Organisation und des Einladenden müssen für E-Mails geeignet sein.

Wer eine Einladung zur Mitarbeiterorganisation (plan_id staff) annimmt, wird ebenfalls Mitarbeiter. Deshalb dürfen nur Mitarbeiter solche Einladungen senden: eine Adresse pro Anfrage mit einem daran gebundenen staff_grant-Nachweis (ohne ihn reauthentication_required). Nur Personen; Agenten und Bearer-Zugangsdaten haben keinen Admin-Zugriff.

Ein benannter Admin widerruft eine ausstehende Mitgliedseinladung. Eine bereits widerrufene Einladung gibt 204 zurück; eine angenommene gibt invitation_consumed zurück; eine ID, die die Organisation nicht hat, ist not_found. Nur Personen; Agenten und Bearer-Anmeldeinformationen haben keine Admin-Route.

Ein benannter Admin entfernt ein Heimatmitglied aus der Organisation.

In einer Transaktion wird die Heimatorganisation der Person gelöscht, und ihre Mitgliedschaften in allen Live-Projekten der Organisation enden, jeweils wie bei ihrer Entfernung aus diesem Projekt (ausstehende E-Mail-Einladungen dazu werden widerrufen, und ihre Sitzungen lösen es nicht mehr auf); Mitgliedschaften in Projekten anderer Organisationen bleiben unberührt, und keine andere Organisation ändert sich.

Die Änderung wird im Organisations-Audit protokolliert.

Eine Person, die ein Identitätsanbieter verwaltet (Single Sign-on oder SCIM), ergibt managed_member; ein benannter Admin ergibt organization_admin_member (zuerst den Admin-Platz mit PUT /api/organizations/{org_id}/admins entfernen); eine Person, die irgendein Live-Projekt der Organisation besitzt, ergibt member_owns_projects, und das Detail listet die Projektnamen auf (diese Projekte zuerst übertragen, nichts wird entfernt); eine Person, die kein Heimatmitglied der Organisation ist, auch eine bereits entfernte, ist not_found.

Nur Personen; Agenten und Bearer-Anmeldeinformationen haben keine Admin-Route.

Ein benannter Admin legt fest, wen die Organisation als Gäste in ihre Projekte zulässt, also Personen, deren Heimatorganisation eine andere ist oder die keine haben. mode allow (Standard) lässt jeden Gast zu, domains lässt einen Gast zu, dessen verifizierte E-Mail-Adresse bei einer der domains liegt, und none lässt keinen Gast zu. domains listet 1 bis 20 verschiedene DNS-Namen in Kleinbuchstaben auf, erforderlich für mode domains und sonst ausgelassen; alles andere ist invalid_request.

Die Richtlinie ersetzt die vorherige, erhöht die Organisationsrevision, wird im Organisations-Audit protokolliert und gibt die geltende Richtlinie zurück. Sie wird geprüft, wenn die Organisation einem Gast eine Projektmitgliedschaft gewährt: durch eine Projektmitglied-Einladung (Erstellen und Annehmen) und durch eine SCIM-Gruppenbindung, und lehnt mit guest_not_allowed ab.

Mitarbeiter und die eigenen Admins der Organisation sind ausgenommen, Agenten werden nicht geprüft, und Heimatmitglieder sind nie Gäste. Eine Verschärfung der Richtlinie entfernt niemanden; outside_policy zählt die externen Personen, die bereits in den Live-Projekten der Organisation sind und die die neue Richtlinie nicht zulassen würde, und GET /api/organizations/{org_id}/people kennzeichnet jede von ihnen (outside_guest_policy).

Nur Personen; Agenten und Bearer-Anmeldeinformationen haben keine Admin-Route.

Ein benannter Administrator legt das Bibliotheksprojekt der Organisation fest oder hebt es auf. project_id nennt eines der aktiven Projekte der Organisation; null hebt die Bibliothek auf.

Alle anderen Projekte der Organisation lesen dann die Medien, Medienordner und Playlists der Bibliothek (library=true bei GET /api/media, /api/media-folders und /api/playlists sowie per ID) und nutzen sie schreibgeschützt: Medienverweise auf Seiten, by:folder-Selektoren, die einen Bibliotheksordner benennen (Tag- und Alle-Selektoren erreichen die Bibliothek nie), Zeitpläne und Stapel der Bildschirme sowie from_template. Nur die eigenen Mitglieder der Bibliothek ändern sie.

Das Bibliotheksprojekt enthält keine Bildschirme: Ein Projekt mit Bildschirmen führt zu library_no_screens, und die Bibliothek nimmt danach keine auf. Zum Festlegen einer Bibliothek ist die Plan-Funktion library nötig (Premium, Education, Enterprise; sonst feature_not_in_plan), zum Aufheben nie, und eine nach einem Downgrade beibehaltene Bibliothek wird weiter ausgeliefert.

Wird die Bibliothek entfernt oder ersetzt, können Playlists der Mitgliedsprojekte, die ihre Elemente benennen, diese beim nächsten Schreiben nicht mehr auflösen, und Bildschirme erhalten ihre Medien nicht mehr. Wird das Projekt, das die Bibliothek ist, gelöscht oder aus der Organisation verschoben, wird sie entfernt.

Antwortet mit der Organisationsansicht, wird im Organisations-Audit protokolliert (organization.library_changed) und erhöht die Revision. Nur für Personen.

Ein benannter Admin legt in einer Anfrage den Zugriff vieler Personen auf viele Live-Projekte der Organisation fest, ohne einem davon beizutreten.

Jede der 1 bis 500 Änderungen nennt ein Projekt, eine Person und einen Zugriff, ohne dass ein Paar (project_id, user_id) doppelt vorkommt. member macht die Person zu einem Mitglied des Projekts, das Überprüfungen nicht genehmigen kann (hinzugefügt, wenn sie noch keines ist; eine genehmigende Person verliert die Genehmigung), approver zu einem Mitglied, das genehmigen kann (hinzugefügt, wenn sie noch keines ist), und none zu keinem Mitglied (entfernt, wenn sie eines ist).

Alles wird der Reihe nach in einer Transaktion angewendet, und eine einzige Ablehnung macht den ganzen Batch rückgängig; jede Ablehnung benennt changes[i] (das Projekt oder die Person) oder changes[i].access in errors[].field.

Ein Projekt, das kein Live-Projekt dieser Organisation ist, ist not_found; eine Person, die keine aktive Person ist (ein Agent, eine deaktivierte Person, eine unbekannte ID) oder die zum screenRIG-Team gehört, eine ausgesetzte Mitgliedschaft und eine hinzugefügte Person, die nicht zu den Personen der Organisation gehört (ihre Admins, ihre Heimatmitglieder und die aktiven Mitglieder ihrer anderen Live-Projekte; alle anderen treten über eine Einladung bei), sind invalid_request; der Inhaber wird nie auf member oder none gesetzt (owner_cannot_leave); ein Uploader genehmigt nie (resource_conflict, wie PUT /api/members/{user_id}/approver antwortet); den Admin selbst zu entfernen ist untersagt (ein Admin tritt über DELETE /api/members/{user_id} aus); und eine hinzugefügte Person wird so zugelassen, wie eine Einladung sie zulässt, also Heimatmitglieder und die Admins der Organisation immer und eine externe Person nur, wenn die Gastrichtlinie sie jetzt zulässt (guest_not_allowed).

Die Grenze von 200 Mitgliedern des Projekts und die Mitgliederobergrenze seines Plans gelten für das Hinzugefügte (member_limit_reached). Die Antwort wiederholt jede Änderung in der Reihenfolge der Anfrage; changed ist false für eine, deren Zugriff bereits galt, was nichts schreibt und nichts aufzeichnet.

Jede Änderung wird im Audit-Protokoll der Organisation aufgezeichnet (organization.project_member_added, organization.project_member_approver_changed oder organization.project_member_removed) und in den Ereignissen des Projekts (member.added_by_organization_admin, project.member_approver_changed oder member.removed, als Aktionen des Organisations-Admins gekennzeichnet), und der Inhaber jedes Projekts erhält einmal pro Batch eine E-Mail, es sei denn, er hat die Änderung selbst vorgenommen.

Nur Personen; Agenten und Bearer-Anmeldeinformationen haben keine Admin-Route.

Ein benannter Admin tritt einem der Live-Projekte der Organisation bei, als Mitglied ohne Bildschirm- oder Upload-Bereich, das Überprüfungen genehmigen darf. Erst der Beitritt verschafft dem Admin die Inhalte des Projekts, die die Organisationsrouten nie zeigen.

Ein Admin, der bereits Mitglied ohne Bereich ist und genehmigen darf, erhält 200 mit joined false, und nichts ändert sich; ein Mitglied mit Bildschirm- oder Upload-Bereich oder eines, das nicht genehmigen darf, wird zu einem Mitglied ohne Bereich, das genehmigen darf, erfasst als Beitritt.

Das Limit des Projekts von 200 Mitgliedern gilt (member_limit_reached); die Gastrichtlinie der Organisation gilt nie für ihre eigenen Admins. Der Beitritt wird im Organisations-Audit als organization.project_joined und in den Projektevents als member.added_by_organization_admin erfasst, und der Inhaber des Projekts erhält eine E-Mail.

Ein Projekt, das die Organisation nicht hat oder das gelöscht wurde, ist not_found. Nur Personen; Agenten und Bearer-Anmeldeinformationen haben keine Admin-Route.

Ein benannter Admin macht eine Person zum Inhaber eines der Live-Projekte der Organisation, ohne dem Projekt beizutreten, vom jeweils aktuellen Inhaber aus, auch wenn das Konto dieses Inhabers deaktiviert ist.

Der neue Inhaber ist eine verifizierte, aktive Person, die Mitglied des Projekts oder Heimatmitglied der Organisation ist (ein Heimatmitglied, das kein Mitglied des Projekts ist, wird zuerst als Mitglied ohne Bildschirm- oder Upload-Bereich hinzugefügt, das Überprüfungen genehmigen darf; die Gastrichtlinie gilt nicht für ein Heimatmitglied); jede andere Person ist invalid_request bei user_id.

Ein Admin macht sich erst nach dem Beitritt zum Projekt zum Inhaber (POST /api/organizations/{org_id}/projects/{project_id}/access), und wer kein Mitglied ohne Bildschirm- oder Upload-Bereich ist, das genehmigen darf, ist invalid_request bei user_id.

Die Wirkung ist die der eigenen Übertragung durch den Inhaber, sodass Bildschirm- und Upload-Bereich des neuen Inhabers gelöscht werden und die Legacy-Verantwortlichkeiten des Projekts an ihn gebunden werden. Die Nennung des aktuellen Inhabers ändert nichts. Die Änderung wird im Organisations-Audit als organization.project_owner_changed protokolliert, und der bisherige und der neue Inhaber erhalten eine E-Mail.

Das Limit des Projekts von 200 Mitgliedern gilt für ein hinzugefügtes Heimatmitglied (member_limit_reached). Ein Projekt, das die Organisation nicht hat oder das gelöscht wurde, ist not_found. Nur Personen; Agenten und Bearer-Anmeldeinformationen haben keine Admin-Route.

Ein benannter Admin entfernt ein Mitglied aus einem der Live-Projekte der Organisation, ohne dem Projekt beizutreten. Das hat die Wirkung der Entfernung durch den Inhaber (DELETE /api/members/{user_id}). Die Mitgliedschaft endet, die ausstehenden E-Mail-Einladungen der Person zum Projekt werden widerrufen, ihre Sitzungen lösen das Projekt nicht mehr auf, und Agentenmitgliedschaften bleiben bestehen.

Der Inhaber wird nie entfernt (owner_cannot_leave; Inhaberschaft zuerst mit PUT /api/organizations/{org_id}/projects/{project_id}/owner übertragen). Eine Person, die kein Mitglied des Projekts ist, auch eine bereits entfernte, und ein Projekt, das die Organisation nicht hat oder das gelöscht wurde, sind not_found.

Die Entfernung wird im Organisations-Audit als organization.project_member_removed und in den Projektevents als member.removed mit removed_by_organization_admin true erfasst. Nur Personen; Agenten und Bearer-Anmeldeinformationen haben keine Admin-Route.

Entfernt eine Domain, verifiziert oder ausstehend, und lässt die anderen Domains der Organisation bestehen. Zukünftige Platzierung und Entdeckung dafür stoppen, und eine andere Organisation kann sie verifizieren. Projekte, die bereits in der Organisation sind, bleiben. Eine Domain, die die Organisation weder besitzt noch nachweist, ist not_found.

Solange die Organisation Single Sign-on verlangt, ist eine verifizierte Domain resource_conflict; das Ausschalten der Option Single Sign-on verlangen wird nach 72 Stunden wirksam, und die Domain kann dann entfernt werden.

Legt fest, ob ein Mitglied genehmigen kann: Überprüfungen entscheiden und Agenten Zugriffsverwaltung gewähren. Ein Mitglied, das nicht genehmigen kann, hat seine Agenten auf Vorschlagen beschränkt. Nur der Projektinhaber oder ein Mitglied, das Admin der Organisation des Projekts ist (sonst forbidden); die eigene Zeile des Inhabers ist fixiert (resource_conflict); ein Nichtmitglied ist not_found.

Fügt project.member_approver_changed hinzu (Details user_id, can_approve).

Beschränkt ein Mitglied auf Bildschirmordner (jeweils mit jedem Ordner darin) und Bildschirme oder ersetzt den Bereich eines Mitglieds (docs/screen-scope.md).

In einer Transaktion beendet es außerdem die Agenten, die die Person ins Projekt gebracht hat (agent.disconnected, wie es ihr Entfernen täte), und hängt project.member_screen_scope_changed an (Details user_id, screen_scope, previous, changed_by_user_id). Der Bereich wird bei der nächsten Anfrage des Mitglieds gelesen: Die Änderung zeigt sich bei seinem nächsten GET /api/session, ohne dass es sich erneut anmelden muss.

Nur der Projektinhaber oder ein Mitglied, das Admin der Organisation des Projekts ist (sonst forbidden); die eigene Zeile des Inhabers, ein Uploader (ein Mitglied mit Bereich ist auf Bildschirme beschränkt, ein Uploader auf Inhalte) und ein Mitglied, das Überprüfungen genehmigt und einzelne Bildschirme im Bereich hat, sind resource_conflict; ein Nichtmitglied ist not_found; eine ID, die kein aktiver Bildschirmordner oder Bildschirm des Projekts ist, ist invalid_request bei screen_scope.folder_ids[i] oder screen_scope.screen_ids[i].

Ein Mitglied mit Bereich, das Überprüfungen genehmigt, genehmigt nur innerhalb des Bereichs; eines, das nicht genehmigen kann, liest und führt Befehle aus, ändert aber nur über genehmigende Personen, was wiedergegeben wird (approver_required).

Ein Bereich wird außerdem mit resource_conflict abgelehnt, solange die Person oder ein von ihr mitgebrachter Agent einen aktiven Service-Client des Projekts hat: Die Details nennen bis zu fünf Clients als ID (Name) und zählen die übrigen, und es wird nichts geschrieben.

Das Beschränken einer Person auf Bildschirme fällt unter den Bildschirmbereich, den der Enterprise-Plan enthält; ein Projekt, dessen Plan dies nicht enthält, wird mit feature_not_in_plan (402) abgelehnt. Ein gesetzter Bereich beschränkt die Person weiter, bis er gelöscht wird (DELETE), was jeder Plan erlaubt.

Gibt einem Mitglied mit Bereich wieder die Bildschirme des gesamten Projekts. Nur der Projektinhaber oder ein Mitglied, das Admin der Organisation des Projekts ist; ein Mitglied ohne Bereich bleibt, wie es ist. Hängt project.member_screen_scope_changed mit screen_scope null an.

Beschränkt die Mitgliedschaft eines Agenten im Sitzungsprojekt auf Bildschirmordner und Bildschirme oder ersetzt seinen Bereich (docs/screen-scope.md). Die Reichweite des Agenten ist dieser Bereich, eingegrenzt durch den Bereich der für ihn verantwortlichen Person, sodass eine Person mit Bereich nie über einen Agenten handelt, der weiter reicht als sie selbst.

Nur der Projektinhaber oder ein Mitglied, das Admin der Organisation des Projekts ist (sonst forbidden); ein Agent, der kein Mitglied des Projekts ist, ist not_found. Hängt agent.screen_scope_changed an (Details agent_id, screen_scope, previous, changed_by_user_id).

Der Bereich eines Agenten gilt bei seiner nächsten Anfrage auf der Instanz, die ihn geschrieben hat, und innerhalb von zwei Sekunden auf den anderen. Ein Bereich wird mit resource_conflict abgelehnt, solange der Agent einen aktiven Service-Client des Projekts hat: Das Detail nennt bis zu fünf Clients als ID (Name) und zählt die übrigen, und es wird nichts geschrieben.

Das Beschränken eines Agenten auf Bildschirme fällt unter den Bildschirmbereich, den der Enterprise-Plan enthält; ein Projekt, dessen Plan dies nicht enthält, wird mit feature_not_in_plan (402) abgelehnt. Ein gesetzter Bereich beschränkt den Agenten weiter, bis er gelöscht wird (DELETE), was jeder Plan erlaubt.

Entfernt den Bereich der Mitgliedschaft eines Agenten im Sitzungsprojekt. Nur der Projektinhaber oder ein Mitglied, das Admin der Organisation des Projekts ist. Hängt agent.screen_scope_changed mit screen_scope null an.

Macht ein Mitglied zum Uploader oder ersetzt den Bereich eines Uploaders (docs/uploaders.md): die Playlists, deren Seiten es ändert, und die Medienordner, in die es hochlädt.

In einer Transaktion hindert sie diese außerdem daran, Überprüfungen zu genehmigen, beendet die Agenten, die sie ins Projekt gebracht haben (agent.disconnected, wie beim Entfernen), und hängt project.member_upload_scope_changed an (Details user_id, upload_scope, changed_by_user_id).

Der Bereich wird bei der nächsten Anfrage des Mitglieds gelesen: Die Änderung zeigt sich bei seinem nächsten GET /api/session, ohne erneute Anmeldung.

Nur der Projektinhaber oder ein Mitglied, das Admin der Organisation des Projekts ist (sonst forbidden); die eigene Zeile des Inhabers ergibt resource_conflict; ein Nichtmitglied ergibt not_found; eine ID, die keine aktive Playlist oder kein aktiver Medienordner des Projekts ist, ergibt invalid_request bei upload_scope.playlist_ids[i] oder upload_scope.folder_ids[i]. access propose (Standard) schickt die Änderungen des Uploaders zur Überprüfung; manage veröffentlicht sie.

Bei einem auf Bildschirme beschränkten Mitglied ergibt dies resource_conflict: Zuerst diesen Bereich aufheben (DELETE /api/members/{user_id}/screen-scope).

Macht einen Uploader wieder zum Vollmitglied, das keine Überprüfungen genehmigt (aktivieren Sie das mit setDashboardMemberApprover). Nur der Projektinhaber oder ein Mitglied, das Admin der Organisation des Projekts ist; ein Mitglied, das kein Uploader ist, bleibt unverändert. Hängt project.member_upload_scope_changed mit upload_scope null an.