FEMA Is Retiring the NFIP Claims Endpoint on 15 October 2026

If any part of your flood analytics reads FimaNfipClaims from the OpenFEMA API, it has a deadline. FEMA's own dataset metadata gives the endpoint a deprecation date of 15 October 2026.

You can verify this yourself in one request, and we would encourage you to rather than take our word for it:

GET https://www.fema.gov/api/open/v1/DataSets?$filter=name eq 'FimaNfipClaims'

  version=2  depDate=2026-10-15  recordCount=2,721,780

The successor is renamed, not re-versioned

This is the part that costs people time. The natural way to look for a replacement is to bump the version in the path:

GET https://www.fema.gov/api/open/v3/FimaNfipClaims   →  404

A 404 reads as "there is no successor yet", which is wrong. The dataset was renamed. The replacement is NfipClaims v3, with no deprecation date and a slightly larger record count:

NfipClaims  v3  depDate=none  recordCount=2,724,656

Three things change together

Migrating is not a one-line path edit. Three things move at once, and the middle one is the dangerous one.

1. The base URL. FimaNfipClaims becomes NfipClaims, v2 becomes v3.

2. The payload key. v2 returns claims under data.FimaNfipClaims; v3 returns them under data.NfipClaims. If you change the URL and not the key, your parser reads undefined, treats it as an empty page, stops paging, and reports success having stored nothing. Every state. Exit code zero. This is the failure mode worth designing against explicitly: a renamed key is indistinguishable from a finished result unless you make it distinguishable.

3. The census field. v2 exposes censusTract, an 11-digit tract GEOID. v3 exposes censusGeoid, a 12-digit block group GEOID. The tract is exactly the first 11 characters, so the conversion is trivial — but storing the raw 12-digit value into a column that has always held a tract silently redefines that column, and anything joining on tract stops matching without ever raising an error.

A field that never existed

One more trap, unrelated to the deprecation. There is no field named floodZone in the OpenFEMA claims data model — not in v2, not in v3. Requesting it does not return null; it rejects the entire request:

HTTP 400  OF_OQP_003
Criteria includes field "floodZone" not found in the data model.

The field you almost certainly want is ratedFloodZone — the zone the property was rated in at the time of loss, which is the one that corresponds to the claim. There is also floodZoneCurrent, the present-day mapped zone, but it is populated on roughly 29% of records against 94% for ratedFloodZone, because it is only filled where FEMA has remapped. For loss calibration you want the rated zone.

Why this matters beyond one endpoint

NFIP claims are the longest-running public record of US flood loss. They underpin flood frequency calibration, repetitive-loss analysis, and any attempt to sanity-check a flood model against something other than another model. An analytics pipeline that quietly stops receiving them does not announce itself — it just gets a little more wrong each quarter.

Two dates are worth putting in a calendar. The first is 15 October 2026. The second is whenever your team last verified that its ingestion actually returned rows, rather than that it exited without error.

Figures in this post were read from the OpenFEMA API on 12 August 2026 and are reproducible with the requests shown.