Projekt-Ereignisse-API

Dauerhafte Projekt-Ereignisse aufsteigend nach Sequenz auflisten.

Paging ist zusammenhängend: Geben Sie den zurückgegebenen next_cursor als after weiter, um genau dort fortzusetzen, wo die Seite aufgehört hat. next_cursor ist der Cursor des zuletzt zurückgegebenen Ereignisses, während neuere Ereignisse bereits existieren, und null am Ende der Historie. Limit standardmäßig 50 und akzeptiert 1-200; ein Wert außerhalb dieses Bereichs wird mit invalid_request und einem errors[]-Element abgelehnt, das limit benennt.

Offset-Paging wird nicht unterstützt. source=log listet stattdessen das Player-Protokoll auf: die Bedingungsberichte, die Spieler senden (runtime.reported), aufsteigend nach Empfangszeit, gefiltert nach screen_id und Schweregrad über ein Zeitfenster von bis (standardmäßig die letzten 24 Stunden, maximal 31 Tage).

Seine Cursor sind undurchsichtig: lg1_ oder ev1_ je nachdem, wo der Server das Player-Protokoll speichert, also geben Sie den zurück, den eine Seite geliefert hat; ein Cursor des anderen Typs wird mit invalid_request abgelehnt, der das Feld nennt. Player-Protokolleinträge haben keine Sequenz, sind nicht auf GET /stream/project und werden nicht an Webhooks geliefert.

Ein Eintrag wird bestätigt, wenn die Player-Log-Warteschlange ihn akzeptiert und für die Ereignisaufbewahrung des Projekts gespeichert wird. Eine Abfrage mit dem letzten Cursor und dem Standardfenster folgt dem Log. Player-Log-Einträge sind nicht in der Standardliste (source=project). from und to werden mit invalid_request abgelehnt, sofern source nicht log ist.

Die Projektliste nimmt screen_id, playlist_id und application_id, um die Ereignisse eines Bildschirms, einer Playlist oder einer Anwendung zu lesen, alle auf das Projekt der Anmeldeinformationen beschränkt (eine ID benennt, welche Ereignisse gelesen werden, niemals wessen): screen_id enthält die Ereignisse, deren Ressource dieser Bildschirm ist; playlist_id die Ereignisse, deren Ressource diese Playlist ist, plus die Ereignisse, die sie als details.playlist_id benennen (ein Bildschirm, der sie verwendet); application_id die Ereignisse, deren Ressource diese Anwendung ist, plus diejenigen, deren Ressource sie als application_id trägt (ihre Releases und Schlüssel/Wert-Einträge).

Ein Wert, der keine ID seines Typs ist, wird mit invalid_request abgelehnt, wobei das Feld benannt wird; playlist_id und application_id werden mit source=log abgelehnt, dessen Datensätze nur zu einem Bildschirm gehören.

Beide Quellen verwenden resource_id, Typ und Schweregrad (mindestens), kombiniert miteinander, mit den ID-Filtern und mit der Paginierung; ein Player-Protokolleintrag ist ein runtime.reported-Eintrag, dessen Ressource sein Bildschirm ist, daher ergibt eine resource_id, die nicht dieser Bildschirm ist, oder ein Typ, der runtime.reported ausschließt, eine leere Seite. Vorher (oder order=desc) zeigt die neuesten zuerst: next_cursor ist dann der Cursor des ältesten zurückgegebenen Elements und wird als before zurückgegeben, um zu älteren Elementen fortzufahren.

Ohne from erreicht eine neueste-zuerst source=log-Seite über die standardmäßigen 24 Stunden hinaus den ältesten Datensatz, den die Ereignisaufbewahrung des Projekts hält, höchstens 31 Tage unterhalb der oberen Seitenkante pro Anfrage. Eine neueste-zuerst source=log-Seite kann weniger als limit Datensätze enthalten, auch keine, mit next_cursor; null beendet sie dennoch am Ende des aufbewahrten Logs.

Ein auf Bildschirme beschränkter Aufrufer (docs/screen-scope.md) liest einen gefilterten Feed: Ereignisse von Bildschirmen innerhalb seines Bereichs, von den Bildschirmordnern, die er sehen kann (seine eigenen, die darüber und die darin; screen.moved nur, wenn das Ziel innerhalb seines Bereichs liegt), von Kampagnen, Playlists, Medien, Anwendungen und Karten sowie playlist_change-Überprüfungen.

Jedes andere Ereignis wird ausgelassen, sodass eine Seite weniger Ereignisse als limit enthalten kann, sogar keine, mit einem next_cursor; blättern Sie damit weiter. source=log braucht eine screen_id innerhalb des Bereichs. Ereignisse über das Projekt selbst werden nicht gesendet.

Wiederholbarer Listen-Stream des Projekts. Player-Log-Einträge (runtime.reported) werden mit GET /api/events?source=log gelesen und sind nicht in diesem Stream enthalten. Das Öffnen dieser Anfrage kostet 1 Credit als Listen-Abonnement. Credit-Header werden weggelassen. Spätere abgerechnete Ereignisse kosten jeweils 1 Credit; screen.*, runtime.*, alert_mute.* und application.event sind ausgenommen.

Herzschläge und die Wiederholungs-Vorabmeldung werden nie berechnet. stream.cursor und stream.resync_required werden berechnet. Debit-Idempotenz ist sse-event:<project_id>:<sequence>, sodass das erneute Verbinden und Abspielen kostenlos ist. Ein unbezahltes berechnetes Ereignis wird nicht geschrieben und der Stream schließt.

Ein mit einer Dashboard-Sitzung geöffneter Stream rechnet nichts ab (weder das Öffnen noch seine Ereignisse), wie die API-Anfragen des Dashboards; er belegt dennoch einen der Stream-Slots des Projekts. Ein auf Bildschirme beschränkter Aufrufer (docs/screen-scope.md) erhält denselben gefilterten Feed wie GET /api/events: Für ein verworfenes Ereignis wird kein Frame gesendet, und stream.cursor hält die Position in Bewegung.

Der Bereich wird beim Öffnen des Streams gelesen und der Ordnerbaum bei einem Verschiebe- oder Ordner-Ereignis erneut; ein verengter Bereich gilt für einen offenen Stream, wenn er sich neu verbindet.