911Cellular CAP Endpoint
This article explains how to use the CAP Endpoint to receive OASIS Common Alerting Protocol (CAP) alerts, how to set the incident type and use Local Assist to avoid the Emergency Dashboard, and how to set up workflows that send communications using the CAP (and ) content.
What is the CAP Endpoint?
The CAP Endpoint accepts inbound CAP alerts (XML or JSON), matches them to your security zones or geofences, and creates an internal alert that runs through your existing panic pipeline—including workflows and mass notifications.
Endpoint:
POST /cap-endpoint/{institutionId}
- {institutionId} – Your institution ID.
- Request body – A valid OASIS CAP 1.2 message in XML or JSON.
- Authentication – The endpoint allows anonymous POST; secure it at your perimeter (e.g. firewall, API gateway, or reverse proxy) as needed.
The response includes whether a zone or geofence was matched and the resulting alert (panic) details.
---
## Sending the incident type (and using Local Assist)
You can tell the system *what kind* of incident the CAP represents by passing an incident type that matches one of your configured Emergency Button (incident type) names.
Query parameter:
incidentType (optional)
Example:
POST /cap-endpoint/123?incidentType=Severe%20Weather
- The value is matched case-insensitively to the Name of an Emergency Button for that institution.
- If the name does not match any Emergency Button, the API returns 422 with a message like: Incident type not found: <value>.
- If you omit incidentType, the alert is still processed; the incident type may be treated as unspecified for workflow and routing.
Why this matters:
- Workflows (panic subscriptions) can be filtered by Emergency Type. Setting incidentType ensures the right workflows run (e.g. “Severe Weather” vs “Fire”).
- If the Emergency Button for that name has Local Assist enabled, the system treats the CAP as a Local Assist incident.
Using Local Assist to avoid the Emergency Dashboard
Local Assist is intended for incidents that should be handled locally (e.g. by on-site staff or ERT) without escalating to the full Emergency Dashboard and without robo-calling the security zone phones.
To use Local Assist for CAP:
1. In the portal, create or edit an Emergency Button (incident type) with the exact name you will send in incidentType (e.g. Severe Weather).
2. Enable Local Assist for that button.
3. Send CAP requests with ?incidentType=Severe%20Weather (or whatever name you configured).
- When the incident type matches a Local Assist Emergency Button:
- The system does not place robo-calls to the security zone (primary/secondary) phones.
- The alert can be completed without going through the full Emergency Dashboard flow in the same way as a standard panic.
- Local Assist ERT members can still receive text or automated calls according to your configuration.
So: set the incident type via the query parameter, and enable Local Assist on that Emergency Button in the portal if you want CAP-driven alerts to be handled as Local Assist and avoid the Emergency Dashboard-style escalation.
How zone and geofence matching works
The system decides which security zone to assign to the CAP alert in this order:
1. Addresses (zone name)
If the CAP message includes an <addresses> element, the system looks up a security zone whose name matches one of the listed addresses. If found, that zone is used and no geofence check is needed.
2. Area (circle or polygon)
If the CAP includes <area> with <circle> or <polygon>:
- The system checks your geofences for the institution.
- It finds a geofence whose geometry is contained within the CAP area (circle or polygon).
- If one is found, the zone linked to that geofence is used.
3. Fallback
If no address match and no geofence match is found, the alert is assigned to the root security zone for the institution.
Only one zone is chosen; address match is tried first, then area/geofence, then root zone.
Setting up workflows and using (and )
When a CAP is accepted, the system builds an internal alert (panic) and runs it through the same pipeline as other alerts. The first <info> block of the CAP is used to populate:
- Headline → panic.Options["Headline"]
- Description → panic.Options["Description"]
Workflows (panic subscriptions) that run on this alert can send mass notifications (email, SMS, app, etc.). In the message content and title of those notifications you can use:
- – Replaced with the CAP headline.
- – Replaced with the CAP description.
This lets you “initiate communication in response to the inbound CAP” by sending the actual CAP headline and description (or surrounding text) to your audiences.
Steps to set up the workflow
1. Create or choose a workflow (panic subscription)
- Attach it to the security zone(s) that will receive CAP-driven alerts (or the root zone if you rely on fallback).
- Set Emergency Type to the same incident type you send in incident Type (e.g. “Severe Weather”), or leave as “Any” if you want all CAP alerts to trigger it.
2. Create or choose a mass notification
- This is the message template that will be sent when the workflow runs.
3. Use the variables in the message and title
- In the notification title and message (and HTML message if used), include:
- where you want the CAP headline.
- where you want the CAP description.
- Example title: Alert:
- Example message: or Please note: —
4. Link the workflow to the mass notification
- Ensure the panic subscription is configured to send that mass notification when the alert matches (zone + incident type, etc.).
When a CAP is posted:
- The endpoint creates the alert with Headline and Description from the CAP.
- The pipeline runs and evaluates workflows.
- Any matching workflow triggers the mass notification.
- Before sending, the system replaces and with the CAP headline and description (and can translate them if you use multiple languages).
Result: recipients get a message driven by the inbound CAP content, so you can initiate communication in response to the CAP using (and ) in your workflow templates.
Summary
| Topic | Detail |
| Endpoint | POST /cap-endpoint/{institutionId} with CAP XML or JSON in the body. |
| Incident type | Optional query: ?incidentType=Name; must match an Emergency Button Name for the institution. |
| Local Assist | Enable Local Assist on that Emergency Button in the portal to avoid Emergency Dashboard escalation and zone robo-calls. |
| Zone matching | Addresses (zone name) → CAP area vs geofences → root zone. |
| Workflows | Create panic subscriptions for the right zone(s) and incident type; link a mass notification. |
| CAP content in messages | Use and in the notification title and message to send the CAP headline and description to your audiences. |