Fixed Locations | Aura Panic API

Fixed Locations are pre-registered properties that AURA can respond to — stores, branches, commercial premises, residential properties, or other managed sites. They provide rapid, location-verified security response to secure physical assets when an alarm sounds or an incident occurs.

You register Fixed Locations up front, then create Fixed Location callouts to request response. Since coordinates and details are pre-registered, no live device GPS is required at dispatch time.

When to use this

Business or property security: alarm response and on-site emergencies.
Many Fixed Locations under one integration, each identified by your own reference.

How it works

Authenticate with a server token using your integration credentials.
Register each Fixed Location with its coordinates and your externalReferenceId.
Keep the Fixed Location list in sync by listing, updating, and deleting Fixed Locations as your source system changes.
Create a callout against a Fixed Location by externalReferenceId. AURA resolves the stored location and dispatches a responder. No live GPS from a device is required.
Track and resolve the callout through the standard callout lifecycle, using webhooks where possible.

A callout can take a live latitude/longitude or a predefinedLocationId — for Fixed Locations you use the stored Fixed Location so you don’t pass coordinates each time.

Fixed Location identifiers

Where your system has one, send a stable externalReferenceId for each Fixed Location. Treat this as the integration key you use to reconcile records, create Fixed Location callouts, and connect AURA activity back to your platform.

If your platform groups Fixed Locations by client, installer, branch, or portfolio, encode that grouping in your own reference data. AURA can then report on the resulting records without requiring operators to re-key location details during an alarm.

externalReferenceId is optional. When a parent credential supplies a non-empty value on a create or update, it must be unique across the monitoring centre’s own sites and every installer site. An installer credential can enforce uniqueness only within its own visible scope, so maintain estate-wide uniqueness in your source system. AURA does not require existing records to have a reference, and legacy duplicate records may still be returned while you repair them. Supply it whenever you intend to reconcile records or raise callouts by your own reference, and keep active references unambiguous. The list endpoint accepts an exact, case-sensitive externalReferenceId filter and can return multiple matches so duplicate data can be identified and repaired. Use the returned AURA id for singular reads, updates, and deletes; it is the canonical key and is always present.

Installer-owned Fixed Locations

Monitoring centres that manage sites for installers can use one parent customer source for the whole estate. AURA configures the installers under that source. Call List installers to discover their installerIdentifier values.

With a parent credential:

list and singular Fixed Location reads include the centre’s own sites and its installers’ sites;
send installerIdentifier when creating a site for one of your installers;
send installerIdentifier on updates only when it restates the site’s current owner; ownership cannot be changed by updating a site;
create Fixed Location callouts by external reference. AURA attributes each callout to the customer source that owns the resolved site.

An installer credential sees its own sites and does not see the parent centre’s other installers. The customerSourceId returned on each Fixed Location is the stable owner identifier when you need to distinguish sites across the estate.

installerIdentifier is the configured identifier returned by List installers, not a substitute for customerSourceId. An unknown or empty identifier is rejected when creating or updating a site. Omitting it on create assigns the site to the authenticated customer source. On callout requests, the legacy field is accepted but ignored; the Fixed Location’s customerSourceId is authoritative.

Operation	Parent credential	Installer credential
List or get	Own sites and all configured installer sites	Own sites only
Create	Own site, or an installer site named by `installerIdentifier`	Own site
Update or delete	Own sites and installer sites it can reach	Own sites only
Fixed Location callout	Any reachable site, attributed to its owner	Own sites only

Ownership is immutable. To move a site between the parent and an installer, or between installers, delete it and create it again under the new owner.

Points of contact

A Fixed Location can include a pointOfContact collection. One contact can be marked isPrimaryContact; that contact must have a mobile number and receives the web-dispatch tracking link. Contacts marked isIncidentReportSubscriber must have a valid email address and receive the incident report.

Create contacts with the Fixed Location, or reconcile them through the update endpoint. When updating:

omit pointOfContact to leave the current collection unchanged;
pass pointOfContact: [] to remove every contact;
pass a non-empty array as the complete desired collection, retaining the AURA contact id for existing contacts and omitting it for new contacts.

Point-of-contact email addresses and mobile numbers are returned by singular Fixed Location reads but are deliberately omitted from the broad list response.

Syncing Fixed Locations

For most integrations, use the fixed-location REST endpoints to create, list, update, and delete Fixed Locations. For large Fixed Location portfolios, AURA also supports a bulk CSV import flow on the Panic API host.

Note that each CSV upload is a full sync - active Fixed Locations missing from the file are marked as deleted, so use CSV either as a one-off seed (maintaining sites via REST afterwards) or as the ongoing source of truth, not both at once. See Bulk CSV import for the upload, callback, and reconciliation flow.

Deleting a Fixed Location removes it from active service. After deletion, do not create new callouts against that reference unless you first recreate the Fixed Location.

Creating a Fixed Location callout

Create the callout with Create a fixed-location callout. Store the returned callout id against your incident, alarm, or job record; you will use that ID for cancellation, chat/events, and polling, and to match the callout to its post-incident resolution report in the AURA portal.

For central-station or alarm-monitoring use cases, see Monitoring Platforms.

The request can optionally include your own calloutExternalReferenceId and calloutDetails describing the alarm. The dispatch location is resolved from the stored Fixed Location, so do not send a live location object. The legacy installerIdentifier field is accepted but ignored and should be omitted from new integrations.

The monitoring-centre model above assumes sites have no linked customer record. For a site linked through customerId, the linked customer’s source takes precedence when the callout is created.

Tracking and cancellation

Use Webhooks to receive callout lifecycle events in your backend. If you cannot receive webhooks, poll the callout while it is active and stop polling once it reaches closed.

If the alarm is confirmed as a false alarm or no response is needed, cancel the callout from your trusted backend. For more detail, see Cancel a callout.

In the API Reference

Fixed Locations — manage Fixed Locations and create a callout by external reference.
Bulk upload fixed locations — import a fixed-location CSV for asynchronous processing.
Callouts — track, cancel, and annotate callouts.