Use case

EmergencyAPI for developers

One integration instead of eight parsers, in a schema that does not change when a state quietly changes its feed.

The problem

Australian emergency data is fragmented across eight jurisdictions. Each publishes in a different format (GeoJSON, GeoRSS, ArcGIS, RSS, XML, CAP-AU) with different field names, different coordinate systems, and different update intervals.

If you want national coverage, you need to write and maintain parsers for every single feed. That is weeks of work before you can build anything useful.

How EmergencyAPI helps

One API. Every state and territory. 34 feeds normalised into GeoJSON with CAP-AU compatible fields (severity, urgency, certainty). Get your first incident in 30 seconds.

Request
GET /api/v1/incidents?state=nsw&eventType=bushfire&format=geojson

Filter by state, event type, severity, warning level, bounding box, or proximity. Cursor-based pagination. CSV export, a validated CAP Atom feed (?format=cap-atom), and per-incident CAP-AU documents (/incidents/[id]?format=cap-au) available.

What you get

  • 34 feeds across every state and territory
  • Bushfires, floods, storms, earthquakes, rescues, hazmat, warnings
  • Updates every 30 seconds to 2 minutes
  • GeoJSON FeatureCollection responses (RFC 7946)
  • CAP-AU compatible severity, urgency, certainty fields
  • Bounding box and proximity search (PostGIS spatial indexing)
  • Event clustering via /v1/events with boundary polygons and summaries
  • 5,000 API calls per month on the free tier
  • No credit card required