Deploy

Integration testing

Use staging to prove both the API contract and your operational behaviour before requesting production access.

Test setup

  1. Use staging credentials and resolve staging response and subscription type IDs.
  2. Register test customers with recognisable external references.
  3. Configure a staging webhook receiver over HTTPS.
  4. Use the Responder Simulator in the staging AURA portal to progress callouts through dispatch, arrival, completion, and closure.

Staging callouts are not closed by a live control room. Most Responder Simulator steps (dispatch, arrival, completion, closure) advance callout state without emitting webhook events for those transitions — poll instead. The exception is cancelling through the simulator’s Response Cancelled flow, which does emit CALLOUT_NO_LONGER_REQUIRES_RESPONSE.

Core scenarios

ScenarioWhat to verify
AuthenticationTokens are cached safely, renewed before expiry, and never exposed to the client
Customer creationYour external reference maps reliably to the returned customerId
SubscriptionThe customer is entitled only during the intended validity window
Callout creationCorrect response type and location are sent; the returned calloutId is retained
Existing calloutA repeated customer panic does not create an unintended duplicate experience
Live trackingLocation updates stop after closure; unknown statuses remain non-terminal
CancellationCustomer and trusted-backend cancellation paths behave as designed
WebhooksSignalling is handled asynchronously and duplicate events are safe
Rate limits429 and RateLimit-Reset produce backoff rather than a retry storm
Transient failureTimeouts and 5xx do not create unsafe duplicate writes

Product-specific scenarios

For People Protect, test poor GPS accuracy, background/foreground movement, an expired subscription, and customer cancellation.

For Property Protect, test an unknown external reference, a deleted Fixed Location, CSV validation and callbacks, and an alarm for a site that already has an active callout.

For white-label, test first launch, authentication, subscription choices, panic and tracking, support links, notifications, deep links, and store-ready builds for every enabled brand and environment.

Evidence for go-live

Keep a short test record containing the scenario, timestamp, environment, request correlation or resource IDs, observed result, and owner. Never paste tokens, secrets, full customer profiles, or payment data into the record.

Continue with Production readiness and the go-live checklist for your product.