Benachrichtigungen: CLI-Befehle

Operationen

Uploads und Veröffentlichungen laufen als Operationen. media upload, media replace und app upload warten standardmäßig auf ihre; mit diesen Befehlen schließen Sie eine ab, die Sie mit --no-wait laufen ließen.

operations show <id>

screenrig operations show op_01EXAMPLEOPERATION00000

operations wait <id> [--timeout MS] [--poll-ms MS]

screenrig operations wait op_01EXAMPLEOPERATION00000

operations cancel <id>

screenrig operations cancel op_01EXAMPLEOPERATION00000

Ereignisse

Das Projekt-Ereignisprotokoll zeichnet auf, was das Projekt und die Flotte getan haben. Eine veröffentlichte Version fügt application.published hinzu; eine App, die screenrig.emit(code) aufruft, fügt ihr eigenes Ereignis hinzu, das der direkteste Beweis ist, dass sie auf einem Bildschirm lief.

Präsenz ist auch im Protokoll. screen.offline wird geschrieben, sobald ein Bildschirm 60 Sekunden offline war, und screen.online wenn er zurückkommt; eine Wiederverbindung innerhalb dieser 60 Sekunden schreibt keines von beiden. screen.offline enthält details.offline_since und, wenn der Bildschirm zuvor online war, details.last_online_at. screen.online enthält details.last_online_at plus details.offline_at, wenn der Bildschirm zuvor offline war, bevor er zurückkehrte. Wie jedes screen.*-Ereignis sind sie im Listen-Stream kostenlos, sodass ein Agent events follow offen halten kann, um eine Flotte zu überwachen.

Inhaltsaktualisierungen eines Players treffen als screen.manifest_changed, screen.manifest_activated und screen.manifest_upgrade ein, deren details manifest_revision, state und, falls vorhanden, code und attempt enthalten. Ein failed-Upgrade hat die Schwere „Fehler“, und retrying, blocked und partial sind Warnungen.

events list [--after CURSOR] [--limit N] [--type TYPE] [--source project|log] [--screen-id ID] [--playlist-id ID] [--app-id ID]

screenrig events list --limit 25
screenrig events list --type application.event --screen-id scr_SCREEN
screenrig events list --playlist-id pl_PLAYLIST
screenrig events list --source log --screen-id scr_SCREEN

events follow [--after CURSOR] [--timeout MS] [--type TYPE]

screenrig events follow

Benachrichtigungen

Eine Benachrichtigung informiert eine Person oder ein anderes System, wenn ein Bildschirm den Zustand wechselt. Eine E-Mail-Benachrichtigung sendet jedem Empfänger eine E-Mail, eine Webhook-Benachrichtigung sendet einen signierten HTTPS-POST, und eine Slack-, Teams-, PagerDuty- oder Telegram-Benachrichtigung postet eine Nachricht in einen Chat oder Pager. Eine Organisation hat höchstens 50 über alle Kanäle und alle ihre Projekte zusammen, und jedes Projekt beginnt mit einer E-Mail an seinen Eigentümer, wenn ein Bildschirm 10 Minuten offline war.

Eine Benachrichtigung überwacht die Bedingungen, die Sie nennen:

Eine Bedingung löst eine Meldung aus, sobald sie --hold Minuten angedauert hat (Standard 10), sodass eine kurze Wiederverbindung ruhig bleibt. Endet sie vorher, wird nichts gesendet; endet sie, nachdem eine Meldung gesendet wurde, folgt eine Behebungsmeldung. crashing wird sofort gesendet. Eine Meldung wird außerdem übersprungen, wenn jemand den Alarm des Bildschirms während der Wartezeit quittiert oder zurückstellt oder wenn eine Stummschaltung den Bildschirm abdeckt. --tag beschränkt eine Benachrichtigung auf Bildschirme mit diesem Tag; ohne Tag zählt jeder Bildschirm.

Jede Meldung hat einen Schweregrad. Eine geöffnete Meldung ist error für screen_offline und warning für jede andere Bedingung, und eine behobene Meldung oder ein Test ist info. --min-severity LEVEL (info, warning oder error) erzeugt keine geöffnete Meldung unterhalb dieser Stufe, und eine behobene Meldung folgt ihrer geöffneten. --severity CONDITION=LEVEL, wiederholbar, setzt die Stufe einer Bedingung für diese Benachrichtigung, etwa --severity not_playing=error; sie zählt für --min-severity. Teams und PagerDuty zeigen die Stufe immer an, der Text von E-Mail, Slack und Telegram nennt sie, wenn die Benachrichtigung --min-severity oder --severity setzt, und ein Webhook-Body enthält severity.

--active-hours SPEC sendet geöffnete Meldungen nur innerhalb wöchentlicher Fenster, gelesen in --timezone ZONE, das es voraussetzt. SPEC ist DAYS HH:MM-HH:MM, etwa "Mon-Fri 08:00-22:00"; bis zu 16-mal wiederholbar. Mit --outside-hours hold, dem Standard, wartet eine Meldung, die außerhalb der Zeiten fällig wird, auf das nächste Fenster und geht dann hinaus, wenn ihre Bedingung noch gilt; eine Bedingung, die vorher endet, sendet also nichts. Mit drop wird die Meldung als outside_hours übersprungen, was notifications deliveries auflistet. Eine behobene Meldung zu einer gesendeten geöffneten Meldung geht immer hinaus, crashing folgt den Zeiten wie jede andere Bedingung, eine Zurückstellung wird zuerst geprüft, und notifications test ignoriert Zeiten, Schweregrad und Zielgruppe.

--audience FILE (Inline-JSON, eine Datei oder - für stdin) wählt die Bildschirme mit den Regeln einer Kampagnen-Zielgruppe aus, etwa {"all":[{"tag":"level2"},{"tag":"overhead"}]} für Bildschirme mit beiden Tags; --all-tags TAG und --any-tag TAG sind die Kurzformen für eine all- und eine any-Regel von Tags, und --tag bedeutet ein beliebiges der Tags. --tag, --any-tag, --all-tags und --audience schließen einander aus.

loop_stalled, glass_blank und glass_frozen sind Urteile, die screenRIG aus den Wiedergabeberichten und Screenshots zieht, die es erhält, und sie lassen aus, was sie nicht beurteilen können: einen Bildschirm, der offline ist, dessen Anzeige aus ist, der übernommen oder gesperrt ist, der ein einzelnes Standbild oder eine Videowand zeigt oder dessen Player keine Wiedergabenummern sendet. Beurteilt screenRIG einen Bildschirm nicht mehr, den es in einem dieser Zustände gefunden hatte, wird der Alarm geschlossen, aber E-Mail, Slack, Teams und Telegram senden keine Behebungsmeldung, weil nichts gezeigt hat, dass sich der Bildschirm erholt; PagerDuty behebt seinen Vorfall trotzdem.

source_failed und source_stale überwachen die Datenquellen des Projekts, nicht seine Bildschirme: Eine Meldung nennt die Quelle und verlinkt ihre Seite, und --tag passt nie auf eine Quelle.

card_data_stale beobachtet eine Karte, keinen Bildschirm. Schreiben Sie die Daten einer Karte mit einem Ablauf, der auf den Zeitplan ihres Schreibers abgestimmt ist (card data put --ttl 30m): Hört der Job oder Agent auf, der sie erneuert, laufen die Daten ab, die Karte ist auf jedem Bildschirm leer, der sie zeigt, und diese Bedingung meldet es Ihnen. Die Meldung nennt die Karte und wann ihre Daten abgelaufen sind und verlinkt den Seiteneditor auf einer Seite, die sie platziert. Die Dokumente einer Datenquelle werden hier nie gemeldet (source_stale deckt sie ab), ebenso wenig eine Karte, die kein Bildschirm zeigt, ohne Ablauf geschriebene Daten oder gelöschte Daten. --tag trifft nie auf eine Karte zu.

reach_dropped und group_empty überwachen eine Kampagne, nicht einen Bildschirm. Die Meldung nennt die Kampagne und die Bildschirme, die sie zuvor und jetzt erreicht hat, oder den leeren Tag oder Ordner und verlinkt auf den Kalender der Kampagne. Eine Kampagne gehört zum Projekt, daher schränken --tag, --any-tag, --all-tags und --audience diese beiden nie ein; --min-severity, --severity, --active-hours und --hold gelten wie für jede Bedingung, und beide sind standardmäßig warning. --reach-drop-screens N und --reach-drop-percent P senden eine reach_dropped-Meldung nur bei einem Rückgang um mindestens N Bildschirme und mindestens P Prozent der Bildschirme, die die Kampagne bei ihrer Veröffentlichung erreicht hat; ein Rückgang muss beides erfüllen, und ohne sie löst jeder Rückgang eine Meldung aus. Sie setzen reach_dropped in --conditions voraus. Jeder leere Tag oder Ordner einer Kampagne ist eine eigene Meldung, und notifications deliveries zeigt ihn als audience_group (tag:Lobby oder folder:sfd_…). Eine Veröffentlichung, die eine leere Gruppe aus der Zielgruppe entfernt, schließt einen PagerDuty-Incident und den Alarm eines Webhooks, sendet aber keine Behebungs-E-Mail und keine Chat-Nachricht.

E-Mails gehen an die verifizierte Adresse jedes Empfängers: eine E-Mail pro Empfänger für alles, was innerhalb von etwa zwei Minuten fällig wird, mit einem Link zu jedem Bildschirm und zur Benachrichtigung im Dashboard. Empfänger sind owner, also wer beim Versand der Meldung Projektinhaber ist, und die Benutzer-IDs von Projektmitgliedern. Ein Empfänger, der keine verifizierte Adresse hat oder das Projekt verlassen hat, wird übersprungen. Benachrichtigungs-E-Mails und Bildschirmmeldungen sind kostenlos.

Jede E-Mail enthält einen Abmeldelink für ihren eigenen Empfänger: die Abmelden-Schaltfläche von Mail-Apps und einen Link in der Fußzeile. Wer ihm folgt, beendet die E-Mails dieser Benachrichtigung an genau diese Person, ohne sich anzumelden, und die geöffnete Seite hat eine Schaltfläche Resubscribe. Die anderen Empfänger sind nicht betroffen, und die Person bleibt unter den Empfängern. notifications show listet mit unsubscribed auf, wer sich abgemeldet hat, und notifications resubscribe schickt ihr wieder E-Mails. Eine Meldung, für die niemand mehr übrig ist, wird als no_recipients übersprungen.

Eine Webhook-Benachrichtigung sendet jede Meldung als JSON per POST; Sie verifizieren sie, wie unter Lieferung verifizieren beschrieben. Mit --events sendet sie außerdem rohe Projekt-Ereignisse per POST, sobald sie eintreten; diese Zustellungen werden wie unter Webhooks beschrieben gemessen.

Eine Slack-, Teams-, PagerDuty- oder Telegram-Benachrichtigung postet eine Nachricht pro Ausfall und Bildschirm oder pro Gruppe von Bildschirmen: den Bildschirm, was sich geändert hat, seit wann, das Projekt, einen Link zum Bildschirm und, wenn ein Offline-Bildschirm zurück ist, seine wahrscheinliche Ursache, falls sie dann bekannt ist. Eine Wiederherstellungsnachricht folgt, sobald die erste gesendet wurde, und löst in PagerDuty den Vorfall auf, den die erste geöffnet hat. Die Zugangsdaten gibst du einmal an (--slack nimmt die URL eines eingehenden Webhooks, --teams die URL eines Workflows-Webhooks, --pagerduty einen Routing-Schlüssel der Events-API v2, --telegram ein Bot-Token mit --telegram-chat); sie werden versiegelt, nie wieder angezeigt, und destination_hint zeigt nur ihr maskiertes Ende. Ein - liest sie aus einer Zeile von stdin, damit sie nicht in deinem Shell-Verlauf landen. Ein fehlgeschlagener Post wird 24 Stunden lang wiederholt, und eine Benachrichtigung, die 72 Stunden lang fehlschlägt, wird deaktiviert.

Wenn drei oder mehr Bildschirme innerhalb von fünf Minuten in dieselbe Bedingung geraten und ein Netzwerk, einen Standort, ein Modell, eine Player-Version oder einen Tag teilen, sendet eine E-Mail-, Slack-, Teams-, PagerDuty- oder Telegram-Benachrichtigung eine Meldung für sie statt einer pro Bildschirm, und eine Meldung nennt die Gruppe, wenn ihr letzter Bildschirm wieder in Ordnung ist; die Meldung jedes anderen Bildschirms wird als grouped übersprungen. Ein Webhook sendet weiterhin eine Meldung pro Bildschirm.

Das Lesen von Benachrichtigungen und ihren Zustellungen erfordert Nur-Lese-Zugriff; das Anlegen, Ändern, Testen und Löschen einer Benachrichtigung, das Erneuern ihres Secrets und das erneute Anmelden einer Person erfordern Verwalten-Zugriff.

notifications create (--email RECIPIENTS | --webhook URL | --slack URL | --teams URL | --pagerduty KEY
                      | --telegram TOKEN --telegram-chat CHAT_ID) [--conditions LIST] [--events TYPES]
                     [--tag TAG... | --any-tag TAG... | --all-tags TAG... | --audience FILE] [--hold MINUTES]
                     [--min-severity LEVEL] [--severity CONDITION=LEVEL]... [--active-hours SPEC]...
                     [--timezone ZONE] [--outside-hours hold|drop] [--reach-drop-screens N] [--reach-drop-percent P]
                     [--description TEXT] [--disabled]

screenrig notifications create --email owner --conditions screen_offline,display_disconnected --tag Lobby

screenrig notifications create --webhook https://hooks.example.com/screenrig --conditions screen_offline,crashing

screenrig notifications create --slack - --conditions screen_offline,crashing < slack-url.txt

notifications list

screenrig notifications list

notifications show <id>

screenrig notifications show ntf_01EXAMPLENOTICE00000

notifications update <id> [--email RECIPIENTS | --url URL | --destination VALUE] [--telegram-chat CHAT_ID]
                          [--conditions LIST | --clear-conditions]
                          [--events TYPES | --clear-events] [--tag TAG... | --any-tag TAG... | --all-tags TAG... | --audience FILE | --all-screens]
                          [--hold MINUTES] [--min-severity LEVEL | --clear-min-severity]
                          [--severity CONDITION=LEVEL]... [--clear-severity]
                          [--active-hours SPEC]... [--timezone ZONE] [--outside-hours hold|drop] [--clear-active-hours]
                          [--reach-drop-screens N] [--reach-drop-percent P] [--clear-reach-drop]
                          [--description TEXT | --clear-description] [--enable | --disable]
                          [--snooze WHEN] [--expect-rev REVISION]

screenrig notifications update ntf_01EXAMPLENOTICE00000 --snooze 2h

notifications delete <id> [--expect-rev REVISION]

screenrig notifications delete ntf_01EXAMPLENOTICE00000

notifications rotate-secret <id> [--expect-rev REVISION]

screenrig notifications rotate-secret whk_01EXAMPLEWEBHOOK00000

notifications test <id>

screenrig notifications test ntf_01EXAMPLENOTICE00000

notifications resubscribe <id> --user USER_ID

screenrig notifications resubscribe ntf_01EXAMPLENOTICE00000 --user usr_01EXAMPLEPERSON0000

notifications deliveries <id> [--before CURSOR] [--limit N]

screenrig notifications deliveries ntf_01EXAMPLENOTICE00000 --limit 20

Lieferung verifizieren

Der Body einer Bildschirmmeldung ist JSON: type (alert.opened oder alert.resolved), id (die Zustellungs-ID), notification_id, project_id, condition, screen (id und name), since (wann die Bedingung begann), at (wann sie lange genug angedauert hat oder behoben wurde), event_id und severity (info, warning oder error: die Stufe der Bedingung bei alert.opened, info bei alert.resolved). alert.resolved für screen_offline enthält außerdem likely_cause (device_restart, app_crash, app_restart, network oder platform), null solange die Ursache unbekannt ist. Bei einer Datenquelle, einer Kampagne oder einer Karte benennt screen sie, und eine Kampagnenmeldung fügt reach (published und current Bildschirme) für reach_dropped oder audience_group (kind tag oder folder und value) für group_empty hinzu. Ein rohes Ereignis von --events ist dasselbe JSON-Objekt, das events list zurückgibt. Die Header sind ScreenRig-Webhook-Id (die Benachrichtigungs-ID), ScreenRig-Event-Id (stabil bei Wiederholungen: die Zustellungs-ID bei einer Meldung, der Ereignis-Cursor bei einem Ereignis) und ScreenRig-Signature: t=<unix seconds>,v1=<hex>, wobei v1 HMAC-SHA256 über "<t>.<raw body>" ist, mit dem geheimen String als Schlüssel. Berechnen Sie es über die Rohbytes vor dem Parsen von JSON, vergleichen Sie in konstanter Zeit, lehnen Sie ein altes t ab und deduplizieren Sie anhand von ScreenRig-Event-Id, da die Zustellung mindestens einmal und ungeordnet erfolgt. Antworten Sie innerhalb von 10 Sekunden mit 2xx; Weiterleitungen werden nicht verfolgt.

import { createHmac, timingSafeEqual } from "node:crypto";

// rawBody: the request body bytes (Buffer) exactly as received.
function verify(rawBody, signatureHeader, secret, toleranceSeconds = 300) {
  if (typeof signatureHeader !== "string" || !signatureHeader) return false;
  const parts = Object.fromEntries(signatureHeader.split(",").map((part) => part.split("=", 2)));
  const t = Number(parts.t);
  if (!Number.isInteger(t) || Math.abs(Date.now() / 1000 - t) > toleranceSeconds) return false;
  const expected = createHmac("sha256", secret).update(`${t}.`).update(rawBody).digest();
  const given = Buffer.from(parts.v1 ?? "", "hex");
  return given.length === expected.length && timingSafeEqual(given, expected);
}

Alarme

Ein Alarm ist ein Problem auf einem Bildschirm, solange es besteht. Er wird geöffnet, wenn ein Bildschirm in eine der Benachrichtigungsbedingungen für Bildschirme (screen_offline, display_disconnected, running_hot, on_battery, storage_full, content_stuck, not_playing, loop_stalled, glass_blank oder glass_frozen) gerät, ob eine Benachrichtigung sie überwacht oder nicht, und wird behoben, wenn die Bedingung endet. Ein Bildschirm hat pro Bedingung höchstens einen offenen Alarm. Eine Absturzserie, eine Datenquelle, eine Karte und eine Kampagne sind Meldungen, nie Alarme. Ein Bildschirm, der für einen von screenRIG gesendeten Neustart neu startet (screen reboot oder ein Neustartplan), öffnet keinen screen_offline- oder display_disconnected-Alarm, bis der Neustart abgeschlossen ist oder zehn Minuten nach dem Senden vergangen sind; eine Bedingung, die dann noch besteht, öffnet ihren Alarm. alerts list zeigt, was gerade offen ist.

Ein offener Alarm braucht Aufmerksamkeit, bis jemand ihn quittiert oder zurückstellt oder eine Stummschaltung seinen Bildschirm abdeckt. Quittieren bedeutet, dass sich jemand darum kümmert: Der Alarm bleibt offen, hält fest, wer ihn wann quittiert hat, und braucht bis zu seiner Behebung keine Aufmerksamkeit. Zurückstellen quittiert bis zu einem Zeitpunkt, der höchstens 30 Tage in der Zukunft liegt, und der Alarm braucht dann wieder Aufmerksamkeit, wenn er noch offen ist. Ein späteres Quittieren oder Zurückstellen ersetzt das frühere. Solange ein Alarm quittiert oder zurückgestellt ist, wird die Meldung einer Benachrichtigung dazu, die noch in der Wartezeit ist, übersprungen.

Eine Stummschaltung ist für Wartungsarbeiten gedacht: Sie nennt Bildschirme, Tags oder beides und endet zu einem Zeitpunkt, der höchstens 30 Tage in der Zukunft liegt. Sie deckt einen Bildschirm ab, solange seine ID aufgeführt ist oder er einen aufgeführten Tag trägt; ein später getaggter Bildschirm ist also abgedeckt, einer, der den Tag verliert, nicht mehr. Die Alarme eines stummgeschalteten Bildschirms werden weiterhin geöffnet und behoben, mit muted markiert, brauchen aber nie Aufmerksamkeit, und jede Benachrichtigung überspringt ihre Meldungen. Eine Organisation hat höchstens 50 aktuelle Stummschaltungen über alle ihre Projekte.

counts.attention in alerts list ist die Zahl, die das Dashboard neben Alarme anzeigt. Das Öffnen, Beheben und Quittieren eines Alarms fügt screen.alert_opened, screen.alert_resolved und screen.alert_acknowledged zum Projekt-Ereignisprotokoll hinzu, und das Anlegen und Beenden einer Stummschaltung fügt alert_mute.created und alert_mute.deleted hinzu. Sie sind im Listen-Stream und bei Webhooks kostenlos, wie jedes screen.*-Ereignis. Behobene Alarme bleiben für die Ereignisaufbewahrung des Tarifs aufgelistet. Das Lesen von Alarmen und Stummschaltungen erfordert Nur-Lese-Zugriff; Quittieren, Zurückstellen, Stummschalten und Aufheben der Stummschaltung erfordern Verwalten-Zugriff.

alerts list [--state open|resolved|all] [--screen-id ID] [--before CURSOR] [--limit N]
            [--format json|csv|xlsx|pdf] [--output FILE]

screenrig alerts list

screenrig alerts list --state all --screen-id scr_01EXAMPLESCREEN00000000

screenrig alerts list --state all --format csv --output alerts.csv

alerts show <id>

screenrig alerts show alr_01EXAMPLEALERT000000

alerts ack <id>

screenrig alerts ack alr_01EXAMPLEALERT000000

alerts snooze <id> (--for DURATION | --until TIME)

screenrig alerts snooze alr_01EXAMPLEALERT000000 --for 4h

alerts mute [--screen-id ID]... [--tag TAG]... (--for DURATION | --until TIME) [--note TEXT]

screenrig alerts mute --tag Lobby --for 2h --note "Rewiring the lobby displays"

alerts mutes

screenrig alerts mutes

alerts unmute <mute-id>

screenrig alerts unmute amt_01EXAMPLEMUTE0000000

Webhooks

Ein Webhook sendet die eigenen Ereignisse dieses Projekts an einen von Ihnen betriebenen HTTPS-Endpunkt als signierte POSTs, sodass ein passendes Ereignis einen Agenten, Bot oder Ihren eigenen Dienst wecken kann. Jedes passende Ereignis kommt als dasselbe JSON-Objekt an, das events list zurückgibt. Ein Webhook ist eine Benachrichtigung in ihrer ursprünglichen Form: Er wird auf die 50 Benachrichtigungen der Organisation angerechnet, und notifications list zeigt ihn an. Richten Sie Neues mit notifications ein; damit lassen sich auch E-Mails und Bildschirmmeldungen senden.

Jeder Zustellversuch ist kostenlos und zählt nicht zum stündlichen Limit der Organisation für Agentenanfragen.

webhooks create --url URL --event-types TYPES [--description TEXT] [--disabled]
webhooks list
webhooks show <id>
webhooks update <id> [--url URL] [--event-types TYPES] [--description TEXT | --clear-description]
                     [--enable | --disable] [--expect-rev REVISION]
webhooks delete <id> [--expect-rev REVISION]
webhooks rotate-secret <id> [--expect-rev REVISION]
webhooks test <id>
webhooks deliveries <id> [--before CURSOR] [--limit N]

webhooks create antwortet mit webhook_limit_reached (Exit 5), wenn die Organisation bereits 50 Benachrichtigungen hat, während notifications create mit notification_limit_reached antwortet. Eine abgelehnte URL ist bei beiden webhook_url_rejected (Exit 8).

--url nimmt eine https-URL auf Port 443 oder 8443, deren Host nur auf öffentliche Internetadressen auflöst, geprüft wie bei notifications create; eine URL mit Zugangsdaten oder einem #-Fragment wird lokal mit Exit 2 abgelehnt. --event-types nimmt 1 bis 32 kommagetrennte exakte Typen, etwa screen.online, oder Präfixe, die auf .* enden, etwa screen.*. --description hat höchstens 200 Zeichen. --disabled legt den Webhook deaktiviert an. webhooks update --enable löscht den Fehlerzustand und beginnt beim aktuellen Ereignis, sodass nichts aus der Zeit der Deaktivierung gesendet wird, und --disable lässt ausstehende Zustellungen mit webhook_disabled fehlschlagen. --expect-rev sichert die Revision ab (revision_conflict, Exit 6).

webhooks create und webhooks rotate-secret geben das Signaturgeheimnis einmal in data.secret mit der Warnung webhook_secret_shown_once aus; nach einem unterbrochenen oder mehrdeutigen Aufruf führen Sie denselben Befehl innerhalb von 24 Stunden erneut aus, um dieselbe Antwort zurückzubekommen. Die Zustellung beginnt mit dem ersten Ereignis nach dem Anlegen des Webhooks. webhooks test stellt eine webhook.test-Zustellung nur für diesen Webhook in die Warteschlange; sie funktioniert bei einem deaktivierten Webhook, wird einmal ohne Wiederholungen versucht, wird wie jede Zustellung gemessen und ist auf 20 pro Minute und Organisation begrenzt (rate_limited, Exit 7). webhooks list zeigt die Webhook-Benachrichtigungen dieses Projekts, älteste zuerst, und eine Nur-Lese-Anmeldeinformation erhält jede url leer mit url_redacted true. webhooks deliveries liest das Protokoll beginnend mit dem neuesten Ereignis, 1 bis 200 Zeilen pro Seite (Standard 50), mit next_cursor (whc1_…) als --before; der state einer Zeile ist pending, succeeded oder failed, mit last_status und einer festen last_error-Klasse. Verifizieren Sie eine Zustellung wie unter Lieferung verifizieren beschrieben.