Use cases

Monitoring Platforms

Monitoring-platform integrations connect an alarm receiving, central-station, or control-room system to AURA Guard Response. The monitoring platform remains the operator workspace; AURA supplies the response network, lifecycle events, and post-incident artifacts.

Use this pattern when an operator or automated alarm rule needs to request AURA response for a known Fixed Location.

When to use this

  • Your platform already stores protected locations, account numbers, zones, alarm types, and operator notes.
  • AURA should respond to fixed locations rather than a moving user.
  • Operators need AURA status updates written back into the alarm event history.
  • False alarms or resolved incidents must be cancellable from the monitoring platform.

If the emergency starts from a mobile user, use People Protect. If the alarm is sent directly by a physical device, use IoT Devices.

Build a small server-side adapter between your monitoring platform and AURA. The adapter owns authentication, Fixed Location reconciliation, dispatch requests, webhook handling, and status mapping.

Map Fixed Locations first

Create AURA Fixed Locations before operators need to dispatch. Use your platform’s location, account, or premises identifier as the AURA externalReferenceId, and keep it stable.

At minimum, store:

  • Your platform’s location or account identifier.
  • The AURA Fixed Location id.
  • The AURA externalReferenceId.
  • The location name, address, and coordinates used for dispatch.

List Fixed Locations regularly, or after bulk changes in your own system, so you can detect missing, renamed, moved, or deleted Fixed Locations before an alarm event. For large portfolios, use the Fixed Location CSV import route on the Panic API host.

Dispatch from an alarm

When an alarm should trigger AURA response, the adapter should:

  1. Resolve the alarm’s Fixed Location to an AURA externalReferenceId.
  2. Create the Fixed Location callout.
  3. Store the returned AURA callout id against the platform alarm or incident.
  4. Write an operator-visible event confirming that the AURA request was created.

Pass the most useful operator context you have through the callout fields and callout event stream: alarm type, zone, location contact notes, gate instructions, reference numbers, and whether the request is a staging/test incident.

Status updates

Prefer Webhooks for monitoring-platform integrations. Each webhook event should update the platform incident history and any visible status badge for the operator.

Map AURA callout events to the concepts your platform exposes, for example:

AURA event or statePlatform action
NEW_CALLOUT or createdMark response requested
RESPONDER_MANUALLY_DISPATCHED or Responder DispatchedMark responder dispatched
RESPONDER_ACKNOWLEDGED_CALLOUT_WITH_ETAShow ETA if your platform supports it
RESPONDER_ARRIVED_ON_SCENE or Responder ArrivedMark responder on location
RESPONDER_COMPLETED or Responder CompletedMark response complete
CALLOUT_NO_LONGER_REQUIRES_RESPONSE or Responder CancelledMark response cancelled
CALLOUT_CLOSED or closedClose the AURA response lifecycle

If webhooks are not available, poll the callout on an interval while it is active. Keep polling conservative, and stop when the callout reaches closed.

Cancellation and operator notes

Operators often need to cancel a response after calling the site, confirming a false alarm, or receiving a reset from the alarm panel. Keep the AURA callout ID on the platform incident so cancellation can be issued without searching.

Use callout events for operator notes and controller communication. Notes should be written back to the platform event history so the monitoring record and AURA record stay aligned.

Reports

After the callout closes, a resolution report is available in the AURA portal — it is not retrieved through the API. Operators and customer-service teams can review response and resolution details there; if your platform supports files or rich event history, download the report from the portal and attach it to the platform incident.

Go-live checklist

  • Confirm production API credentials are server-side only.
  • Register representative fixed locations in staging.
  • Verify every platform location can resolve to exactly one AURA externalReferenceId.
  • If using CSV import, verify callback handling and post-import reconciliation.
  • Test a real dispatch flow end to end in staging, including status updates.
  • Test cancellation from the operator console.
  • Test webhook authentication, idempotency, and event-to-status mapping.
  • Confirm where resolution reports will be stored or linked.
  • Agree on operational handling for missing Fixed Locations, duplicate references, and webhook delivery failures.

In the API Reference