Alarmintegrationen

Verbindet eine Einrichtung mit der Vorlage eines Überwachungspartners und verwaltet diese Verbindung: speichern (Vorlage, Kontonummer, Zonenzuordnung, Ereignisse, Einrichtungsfelder), entfernen, Freigabe anfordern, ein Testsignal senden, nach einem erfolgreichen Test aktivieren und eine vorgemerkte Änderung verwerfen.

Eine Live-Verbindung (aktiv oder fehlerhaft) ändert sich nur mit applyMode: staged belässt Alarme auf den Live-Einstellungen, bis ein vorgemerkter Test erfolgreich ist und Sie ihn aktivieren; immediate wendet die Änderung sofort an. Geheime Felder werden angenommen, aber nie zurückgegeben. Erfordert External Integrations an der Einrichtung. Lesen Sie zuerst mit alarm_integrations_read connections.

Aktionen:

• save: Verbindung speichern. Für eine neue Verbindung ist templateId erforderlich. fields setzt Einrichtungsfelder nach Schlüssel (null löscht ein Feld; Geheimnisse werden versiegelt). Übergeben Sie bei einer Live-Verbindung applyMode, sonst schlägt der Aufruf mit apply-mode-required fehl. Erfordert partnerId. Fordert eine Bestätigung an.
• remove: Verbindung entfernen. Entfernt die Verbindung der Einrichtung zum Partner samt einer vorgemerkten Änderung; Alarme von hier gehen nicht mehr an diese Notrufzentrale. Erfordert partnerId. Fordert eine Bestätigung an.
• request_approval: Freigabe anfordern. Bittet die Notrufzentrale, die Verbindung freizugeben oder eine Kontonummer zuzuweisen (Vorlagen mit Partnerfreigabe). Erfordert partnerId.
• send_test_signal: Testsignal senden. Stellt ein echtes Testsignal an die Notrufzentrale in die Warteschlange; fragen Sie test_signal_status ab. staged: true testet die vorgemerkte Änderung statt der Live-Einstellungen. Erfordert partnerId. Fordert eine Bestätigung an.
• activate: Verbindung oder Änderung aktivieren. Schaltet eine ausstehende Verbindung live, übernimmt eine vorgemerkte Änderung oder bestätigt eine ungetestete. Zum Aktivieren ist die requestId eines Tests erforderlich, der nach der letzten Änderung erfolgreich war: Ein vorgemerkter Test (staged: true) übernimmt eine vorgemerkte Änderung, ein Live-Test bestätigt eine ungetestete. Erfordert partnerId, requestId. Fordert eine Bestätigung an.
• discard_pending_change: Vorgemerkte Änderung verwerfen. Verwirft die vorgemerkte Änderung; die Live-Einstellungen bleiben unverändert. discarded ist false, wenn nichts vorgemerkt war. Erfordert partnerId. Fordert eine Bestätigung an.

Fügt benutzerdefinierte Alarmziele hinzu, ändert und löscht sie und löst Tests aus: Ihren eigenen Überwachungsempfänger, eine Relaisplatine, SMS, Sprachanruf, E-Mail, Webhooks, Team-Chat oder einen Bereitschafts-Pagingdienst (die Kanalliste), auf Ebene einer Einrichtung (Standard), einer Marke oder der Organisation.

Nicht geheime Einstellungen gehören in config; Geheimnisse (Passwörter, Webhook-URLs, Schlüssel) gehören nach Einstellungspfad in fields und werden versiegelt, nie zurückgegeben. Aktivierte Ziele benötigen eine vollständige config. Ziele einer Einrichtung erfordern dort External Integrations oder Duress Configuration; Ziele einer Marke oder der Organisation erfordern organisationsweiten Zugriff. Lesen Sie zuerst mit alarm_integrations_read destinations.

Aktionen:

• save: Ziel speichern. Ohne connectionId wird ein Ziel hinzugefügt (channel und name erforderlich); mit connectionId wird eines geändert (der Kanal bleibt). config ersetzt, wenn übergeben, die nicht geheimen Einstellungen; in fields weggelassene Geheimnisse bleiben erhalten. Fordert eine Bestätigung an.
• remove: Ziel löschen. Löscht das Ziel; ein Relais einer Einrichtung steuert dann auch das Alarmrelais nicht mehr. Erfordert connectionId. Fordert eine Bestätigung an.
• send_test_signal: Test an ein Ziel senden. Stellt eine echte Testnachricht an das Ziel in die Warteschlange; fragen Sie alarm_integrations_read test_signal_status mit der Einrichtung ab. Ziele einer Marke oder der Organisation werden von facilityId aus getestet. Erfordert connectionId. Fordert eine Bestätigung an.

Liest, wohin die Duress-Alarme einer Einrichtung außerhalb von Performance Hub gehen: ihre Notrufzentralenverbindungen (Partner, Vorlage, Kontonummer, Zonenzuordnung, Status, fehlende Voraussetzungen, vorgemerkte Änderungen), benutzerdefinierte Ziele (Überwachungsempfänger, Relais, SMS, Sprachanruf, E-Mail, Webhooks, Chat, Paging) der Einrichtung, ihrer Marke und Organisation, eine Routing-Vorschau, das Zustellprotokoll und Testsignal-Ergebnisse.

Erfordert External Integrations oder Duress Configuration an der Einrichtung. Geheimnisse und versiegelte Werte werden nie angezeigt, nur { key, secret, hasValue }; Telefonnummern und Adressen von Personen werden in Routing und Zustellungen unkenntlich gemacht. Zeiten im ISO-Format. Ändern Sie sie mit alarm_integrations_connections_write und alarm_integrations_destinations_write.

Aktionen:

• connections: Notrufzentralenverbindungen. Die Partnerverbindungen der Einrichtung: Vorlage, Kontonummer (linkingIdentifier), Zonenzuordnung, Ereignisse, connectionStatus, missing (was den Livebetrieb verhindert), pendingChange (vorgemerkt, noch nicht live) und untestedChange. canEdit: External Integrations hier.
• destinations: Benutzerdefinierte Ziele. Ziele, die für die Einrichtung auslösen können (eigene, die ihrer Marke und Organisation, jeweils mit canEdit), oder mit ownerScope die eines einzelnen Bereichs. Einstellungen in config; Geheimnisse als fields { key, secret, hasValue }.
• routing: Routing-Vorschau. Wohin ein Alarm gerade gehen würde (nur Live-Einstellungen), so wie universal-api es auflöst: Ziele mit lane, events und config ohne Geheimnisse, problems mit Erklärungen zu allem, was ausgelassen wurde, und noch nicht geroutete pendingChanges. eventType behält nur, was dieses Ereignis empfängt.
• deliveries: Zustellprotokoll. Alarmzustellungen, neueste zuerst (Status, Kanal, Empfänger, Latenz, öffentlicher Fehlertext). Eine gefilterte Seite kann kurz sein und trotzdem einen nextCursor haben. Gerätewarnungen erscheinen als kind alert.
• test_signal_status: Testsignal-Ergebnis. queued, bis universal-api einen Versuch erfasst, dann succeeded (ein Empfänger hat bestätigt oder es wurde gesendet) oder failed, mit den Zustellzeilen. Verwenden Sie die Einrichtung, von der aus der Test gesendet wurde. Erfordert requestId.