> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.aurasos.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.aurasos.com/_mcp/server.

# 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](/people-protect). AURA's device-linking API links a device to
an individual customer, not a Fixed Location — an alarm panel or sensor at a
property should notify your own adapter (below), which then creates the Fixed
Location callout.

## Monitoring centres with installers

If the monitoring centre manages sites for several installers, use one parent
customer source and ask AURA to configure each installer under it. At integration
setup:

1. Call [List installers](/api-reference/installers/list-installers) and store
   each installer's `installerIdentifier` and `customerSourceId`.
2. Reconcile the centre's own sites and each installer's sites separately. Send
   `installerIdentifier` when creating a site for an installer, and omit it for
   a centre-owned site. If your platform sends an installer value on every site,
   ask AURA to assign unmatched installers to the centre; see [Unmatched installers](/property-protect/fixed-locations#unmatched-installers).
3. Use the parent credential for estate-wide reads and administration. Use an
   installer credential when that installer must be isolated to its own sites.
4. Keep ownership stable. Updating a site cannot move it to another owner; move
   it by deleting and recreating it under the new owner.
5. Create callouts using the site's `externalReferenceId`. AURA attributes the
   callout to the customer source that owns the resolved Fixed Location.

The parent and installer portfolios should each have one declared source of
truth. If using CSV, the file must contain the complete rows for the parent and
every installer reported with `bulkSyncManaged: true`. If using REST, do not mix
a partial CSV upload into the same portfolio.

## Recommended architecture

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.

```mermaid
sequenceDiagram
    participant Platform as Monitoring platform
    participant Adapter as Integration adapter
    participant Aura as AURA Panic API
    participant Ops as Operator console

    Adapter->>Aura: Create server token
    Adapter->>Aura: Create or update Fixed Locations
    Platform->>Ops: Alarm event opens for a known Fixed Location
    Ops->>Adapter: Request AURA response
    Adapter->>Aura: Create callout by externalReferenceId
    Aura-->>Adapter: Return callout id and status
    Adapter-->>Platform: Store AURA callout id on the alarm
    Aura->>Adapter: Webhook lifecycle events
    Adapter-->>Platform: Write status updates to event history
    Ops->>Adapter: Cancel response if no longer needed
    Adapter->>Aura: Cancel callout
    Aura->>Adapter: Closed or cancelled event
    Adapter-->>Platform: Attach final status or report
```

## 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](/overview/core-concepts/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 state                                            | Platform action                       |
| -------------------------------------------------------------- | ------------------------------------- |
| `NEW_CALLOUT` or `created`                                     | Mark response requested               |
| `RESPONDER_MANUALLY_DISPATCHED` or `Responder Dispatched`      | Mark responder dispatched             |
| `RESPONDER_ACKNOWLEDGED_CALLOUT_WITH_ETA`                      | Show ETA if your platform supports it |
| `RESPONDER_ARRIVED_ON_SCENE` or `Responder Arrived`            | Mark responder on location            |
| `RESPONDER_COMPLETED` or `Responder Completed`                 | Mark response complete                |
| `CALLOUT_NO_LONGER_REQUIRES_RESPONSE` or `Responder Cancelled` | Mark response cancelled               |
| `CALLOUT_CLOSED` or `closed`                                   | Close 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`.
* For an installer estate, verify parent and installer credentials see the
  intended scopes, and that each CSV row has the correct `installerIdentifier`
  when CSV sync is used.
* 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

* [Authentication](/api-reference/authentication) - create a
  server token for the adapter.
* [Fixed Locations](/api-reference/fixed-locations) - manage
  Fixed Locations and create Fixed Location callouts.
* [Bulk upload fixed locations](/api-reference/fixed-locations/bulk-upload-fixed-locations) -
  import large Fixed Location lists by CSV.
* [Callouts](/api-reference/callouts) - cancel, annotate,
  and poll callouts.
* [Webhooks](/api-reference/webhooks) - register the
  lifecycle events that update your monitoring platform.