> For the complete documentation index, see [llms.txt](https://api-v2-docs.disasteraware.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://api-v2-docs.disasteraware.com/readme.md).

# Introduction

Documentation for DisasterAWARE Enterprise V2 API

This documentation is the reference for the DisasterAWARE Enterprise V2 API. It is kept current with the deployed API; when an endpoint's behaviour changes, the affected pages here are updated.

### Production status

**The V2 API is in production and supported for production use.** Build against it directly.

Fields are added over time as hazard enhancement and new sources come online, so write clients that tolerate unfamiliar fields rather than rejecting them, and treat an absent optional field as "not applicable to this record" rather than an error. Each endpoint page lists the fields that are always present.

Please contact <support@disasteraware.com> with any questions about the API.

### Why V2

The V2 API delivers hazards reported by the RICHTER hazard identification system. Hazards delivered via the V1 API lacked several fields — `incident`, `alertGeometry`, `features` and `exposureAssessment` — which required additional API calls or were not available at all.

V2 was explicitly designed to reduce the number of API calls needed to pull all hazard information: one record carries the incident detail, the alert and feature geometry, and the exposure assessment together.

### Push delivery via webhook

The endpoints documented here are pull-based: you query them on your own schedule. Hazard updates can also be **pushed to an endpoint you provide** as they are published, so your systems react without polling.

**The payload is a single hazard, exactly as documented here — with no wrapper.** The body of each delivery is one hazard object in the same shape the pull endpoints return, so the [response fields](/hazards/requesting-active-hazards.md#response-fields) and the [hazard sample pages](/hazards/hazard-samples/earthquake-sample.md) describe a webhook body as they do a record retrieved by query. There is no envelope, no event metadata around it and no batching: one hazard per delivery.

That means a client that already parses the active hazards feed can handle a webhook body with the same code — the records are the same records, arriving by a different route.

**Authentication is whatever you require.** We can accommodate the authentication mechanism your receiving endpoint expects, so you do not have to adapt your infrastructure to ours. Tell us what your endpoint requires when the integration is set up.

**Updates arrive in timestamp order.** When a hazard is updated more than once, the deliveries follow the order of the updates, so the last body you receive for a hazard is its most recent state.

Webhook delivery is fully supported and configured per account. To set it up, contact <support@disasteraware.com> or your PDC account representative, who will confirm the delivery details for your integration.

### OpenAPI Specification

{% file src="/files/wYQaKpPZEdPb68ZWOF6w" %}
Download OpenAPI Specification
{% endfile %}