Alarm Integrations

Connects a facility to a monitoring partner's template and manages that connection: save (template, account number, zone map, events, facility fields), remove, request approval, send a test signal, activate after a successful test, and discard a staged change.

A live connection (active or failing) only changes with applyMode: staged keeps alarms on the live settings until a staged test succeeds and you activate it; immediate applies now. Secret fields are accepted but never returned. Needs External Integrations at the facility. Read first with alarm_integrations_read connections.

Actions:

• save: Save a connection. templateId is needed for a new connection. fields sets facility fields by key (null clears one; secrets are sealed). On a live connection pass applyMode, or the call fails with apply-mode-required. Needs partnerId. Asks for confirmation.
• remove: Remove a connection. Removes the facility's connection to the partner, with any staged change; alarms stop going to that monitoring centre from here. Needs partnerId. Asks for confirmation.
• request_approval: Request approval. Asks the monitoring centre to approve the connection or assign an account number (partner-approval templates). Needs partnerId.
• send_test_signal: Send a test signal. Queues a real test signal to the monitoring centre; poll test_signal_status. staged: true tests the staged change instead of the live settings. Needs partnerId. Asks for confirmation.
• activate: Activate a connection or change. Makes a pending connection live, promotes a staged change, or confirms an untested one. Activating needs requestId of a test that succeeded after the last change: a staged test (staged: true) promotes a staged change, a live test confirms an untested one. Needs partnerId, requestId. Asks for confirmation.
• discard_pending_change: Discard a staged change. Drops the staged change; the live settings are untouched. discarded is false when nothing was staged. Needs partnerId. Asks for confirmation.

Adds, changes, deletes and test-fires custom alarm destinations: your own monitoring receiver, a relay board, SMS, voice, email, webhooks, team chat or an on-call paging service (the channel list), at a facility (default), brand or organisation.

Non-secret settings go in config; secrets (passwords, webhook URLs, keys) go in fields by setting path and are sealed, never returned. Enabled destinations need a complete config. Facility destinations need External Integrations or Duress Configuration there; brand and organisation ones need organisation-wide access. Read first with alarm_integrations_read destinations.

Actions:

• save: Save a destination. Without connectionId adds one (channel and name needed); with it changes one (the channel stays). config, when sent, replaces the non-secret settings; secrets left out of fields are kept. Asks for confirmation.
• remove: Delete a destination. Deletes the destination; a facility relay also stops driving the alarm relay. Needs connectionId. Asks for confirmation.
• send_test_signal: Send a test to a destination. Queues a real test message to the destination; poll alarm_integrations_read test_signal_status with the facility. Brand and organisation destinations are tested from facilityId. Needs connectionId. Asks for confirmation.

Reads where a facility's duress alarms go outside Performance Hub: its monitoring-centre connections (partner, template, account number, zone map, status, readiness gaps, staged changes), custom destinations (monitoring receivers, relays, SMS, voice, email, webhooks, chat, paging) at the facility, its brand and organisation, a routing preview, the delivery log and test-signal outcomes.

Needs External Integrations or Duress Configuration at the facility. Secrets and sealed values are never shown, only { key, secret, hasValue }; people's numbers and addresses are redacted from routing and deliveries. Times are ISO. Change them with alarm_integrations_connections_write and alarm_integrations_destinations_write.

Actions:

• connections: Monitoring-centre connections. The facility's partner connections: template, account number (linkingIdentifier), zone map, events, connectionStatus, missing (what blocks going live), pendingChange (staged, not live yet) and untestedChange. canEdit: External Integrations here.
• destinations: Custom destinations. Destinations that can fire for the facility (its own, its brand's and organisation's, each with canEdit), or with ownerScope one scope's. Settings in config; secrets as fields { key, secret, hasValue }.
• routing: Routing preview. Where an alarm would go right now (live settings only), as universal-api resolves it: destinations with lane, events and config minus secrets, problems explaining anything left out, and pendingChanges not routed yet. eventType keeps only what receives that event.
• deliveries: Delivery log. Alarm deliveries newest first (status, channel, receiver, latency, public error wording). A filtered page can be short and still have nextCursor. Device alerts show as kind alert.
• test_signal_status: Test signal outcome. queued until universal-api records an attempt, then succeeded (a receiver acknowledged or it was sent) or failed, with the delivery rows. Use the facility the test was sent from. Needs requestId.