Developer guide

What is CAP-AU? A Developer Guide

CAP-AU is the Australian profile of the Common Alerting Protocol (CAP), an international XML standard for exchanging emergency alerts. If you build anything that consumes or produces Australian emergency data, you will encounter CAP-AU. This guide explains what it is, how it works, and how to use it through EmergencyAPI.

What is CAP?

The Common Alerting Protocol (CAP) is an OASIS standard (version 1.2, ratified 2010) that defines a simple XML format for all-hazard emergency alerts. It is used by over 200 countries and forms the backbone of systems like the US Wireless Emergency Alerts (WEA), the EU Alert Ready system, and Google Public Alerts.

A CAP message describes: what happened (event type, severity, urgency, certainty), where it happened (geographic area as polygon, circle, or geocode), when it happened (effective time, expiry), and what to do (instructions, response type).

The key benefit is interoperability. Any system that understands CAP can consume alerts from any other system that produces CAP, regardless of the originating country or agency.

What is CAP-AU?

CAP-AU is the Australian profile of CAP, maintained by the Bureau of Meteorology (BOM). It builds on CAP 1.2 with Australian-specific conventions:

Event codes: Australian-specific event type classifications (bushfire, flood, cyclone, storm, earthquake, tsunami, etc.) mapped to the Australian Warning System categories.
Geocodes: SA4 (Statistical Area Level 4) geocode references for geographic targeting, compatible with ABS (Australian Bureau of Statistics) boundaries.
Response types: Australian emergency response conventions (Shelter, Evacuate, Monitor, AllClear).
Warning levels: Aligned with the Australian Warning System: Advice, Watch and Act, Emergency Warning.
Sender identifiers: Standardised agency identifiers for Australian emergency services.

The current version is CAP-AU v3.0. The specification is published by BOM at their metadata portal.

Why Should Developers Care?

AusAlert launches October 2026

NEMA (National Emergency Management Agency) is launching AusAlert in October 2026. It replaces the existing Emergency Alert system with a modern, CAP-based platform. AusAlert uses CAP-AU as its native message format. If you build emergency data integrations for government, infrastructure, or emergency management, you will need to understand CAP-AU.

Interoperability

Several Australian emergency agencies already publish CAP-AU feeds. WA DFES publishes warnings in CAP-AU format. BOM publishes severe weather and cyclone warnings in CAP-AU. Consuming these feeds means parsing CAP XML.

Compliance

If your system redistributes emergency warnings (as opposed to raw incident data), CAP-AU formatting may be expected by government partners. EmergencyAPI's CAP-AU output validates against the OASIS CAP 1.2 schema and the CAP-AU Profile v3.0. Both the Atom feed (?format=cap-atom, each entry inlines a full alert) and the per-incident documents (/incidents/[id]?format=cap-au) are standards-validated with the Google CAP Validator.

CAP-AU Message Structure

A CAP-AU message has three layers: alert (the envelope), info (the content), and area (the geography). Here is an abbreviated example:

CAP-AU XML (abbreviated)

<?xml version="1.0" encoding="UTF-8"?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.2">
  <identifier>wa-dfes-2026-04-27-001</identifier>
  <sender>dfes.wa.gov.au</sender>
  <sent>2026-04-27T08:30:00+08:00</sent>
  <status>Actual</status>
  <msgType>Alert</msgType>
  <scope>Public</scope>

  <info>
    <category>Fire</category>
    <event>Bushfire</event>
    <responseType>Monitor</responseType>
    <urgency>Expected</urgency>
    <severity>Moderate</severity>
    <certainty>Observed</certainty>
    <headline>Bushfire ADVICE for Mundijong area</headline>
    <description>A bushfire is burning in the Mundijong area...</description>
    <instruction>Stay alert and monitor conditions.</instruction>

    <area>
      <areaDesc>Mundijong, Byford, Serpentine</areaDesc>
      <polygon>-32.29,115.95 -32.30,115.96 ...</polygon>
      <geocode>
        <valueName>ABS:SA4</valueName>
        <value>50602</value>
      </geocode>
    </area>
  </info>
</alert>

Key fields: severity (Minor, Moderate, Severe, Extreme), urgency (Immediate, Expected, Future, Past), certainty (Observed, Likely, Possible, Unlikely). These map directly to EmergencyAPI's incident properties.

How EmergencyAPI Uses CAP-AU

As a consumer

EmergencyAPI consumes CAP-AU feeds from WA DFES (warnings) and BOM (severe weather). The Adaptive ETL Engine parses the CAP XML, extracts the structured fields, normalises them into our GeoJSON schema, and stores them alongside incidents from all other feed formats (GeoJSON, ArcGIS, RSS, custom JSON).

As a producer

EmergencyAPI outputs CAP-AU two ways. For a feed of current incidents, add ?format=cap-atom to the incidents endpoint: you get a CAP Atom feed where each entry inlines a full, schema-valid CAP-AU alert, and incidents retracted in the last 7 days appear as Cancel messages that reference the original alert. For a single incident, add ?format=cap-au to /incidents/[id] to get one standalone CAP-AU alert document.

Both validate against the OASIS CAP 1.2 schema and the CAP-AU Profile v3.0, confirmed with the Google CAP Validator. The legacy ?format=cap-au on the list endpoint returns a non-standard wrapper and is deprecated; it is unchanged for backward compatibility, but new integrations should use the Atom feed. See the compliance page for evidence.

Consuming CAP-AU with EmergencyAPI

You do not need to parse CAP XML yourself. EmergencyAPI normalises all feeds (including CAP-AU sources) into GeoJSON. But if you need CAP-AU output for downstream systems, use the Atom feed for current incidents or the per-incident endpoint for a single alert:

curl (CAP Atom feed)

curl -s "https://emergencyapi.com/api/v1/incidents?state=wa&limit=5&format=cap-atom" \
  -H "Authorization: Bearer YOUR_API_KEY"

curl (single incident as a CAP-AU alert)

curl -s "https://emergencyapi.com/api/v1/incidents/wa-dfes-1087245?format=cap-au" \
  -H "Authorization: Bearer YOUR_API_KEY"

Python (parse the CAP Atom feed)

import requests
from defusedxml.ElementTree import fromstring  # hardened against XXE / billion-laughs

response = requests.get(
    "https://emergencyapi.com/api/v1/incidents",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    params={"state": "wa", "limit": 5, "format": "cap-atom"},
)

root = fromstring(response.text)
ns = {"cap": "urn:oasis:names:tc:emergency:cap:1.2"}

# Each Atom entry inlines a full CAP-AU <alert>; pull the info blocks out.
for info in root.findall(".//cap:info", ns):
    event = info.findtext("cap:event", default="", namespaces=ns)
    headline = info.findtext("cap:headline", default="", namespaces=ns)
    severity = info.findtext("cap:severity", default="", namespaces=ns)
    print(f"{event}: {headline} (Severity: {severity})")

The legacy ?format=cap-au on the list endpoint still works but is deprecated; it returns a non-standard wrapper. Prefer the Atom feed above.

CAP-AU vs GeoJSON: When to Use Each

Scenario	Use	Why
Building a web map or dashboard	GeoJSON	Native to Leaflet, Mapbox, deck.gl. Easy to render.
Feeding an emergency management system	CAP-AU	Industry standard. Expected by NEMA, state agencies, AusAlert.
Data analysis or machine learning	GeoJSON or CSV	Structured, easy to parse into pandas/geopandas.
Integrating with Google Public Alerts	CAP-AU	Google requires CAP format for alert ingestion.
Mobile app or IoT device	GeoJSON	Smaller payloads, simpler parsing than XML.

Most developers will use GeoJSON (the default format). CAP-AU is there when you need it for interoperability with government and emergency management infrastructure.