How to Evaluate a Climate Risk API: 8 Features That Matter

Physical climate risk is increasingly bought as an API, not a dashboard. Consultants build it into their own platforms, banks wire it into origination screens, insurers enrich underwriting with it. That changes how you evaluate it. A dashboard can be judged by looking at it. An API has to be judged by what it lets you build, and the brochure cannot show you the response payloads.

The real evaluation question is not “does it return data.” It is “can this take an address all the way to a number a client, a board, or an auditor will accept.” Here are eight features that separate an API that can do that from a science demo, each with a test you can run in an afternoon.

1. It covers the full assessment chain, not one step of it

A complete physical risk assessment is a sequence, and every step depends on the one before it:

1. Resolve the asset. Address to coordinate, with a quality score on the match, so you know whether you are assessing the building or the centroid of the city.
2. Establish location context. Elevation, distance to the coast, land cover. An assessment that thinks a riverside plant is a forest will misprice fire and flood alike.
3. Project the hazards. Heat, flood, drought, storm, water stress and the rest, across climate scenarios and time horizons.
4. Resolve flood depth. Riverine and coastal water depth at the site, from the common 1-in-10-year event to the rare 1-in-500-year event.
5. Translate depth into loss. Depth-damage curves convert metres of water plus a replacement value into a damage figure.
6. Integrate into expected annual damage. EAD, the average loss per year across all event severities. This is the number that prices the risk.
7. Cross-check against history. What has already happened at this site, independent of any model.

Most products cover one or two of these boxes. A hazard-scores-only API leaves you sourcing flood depth, damage curves, and event history from three other vendors and integrating them yourself, which is where most climate risk projects actually die.

The test: count how many of the seven steps you can complete without leaving the API.

2. It ends in a loss figure, not a rating

Hazard ratings rank sites. Only currency prioritizes capital. A board can act on “this plant carries an expected annual damage of 1.2 million dollars from flooding, rising 40 percent by 2050 under the high scenario.” It cannot act on “flood risk: High.”

Getting there requires depth-damage curves (FEMA HAZUS for US-style assets, the JRC global curves elsewhere), a stated building type, and a replacement value, returning a loss per flood severity. The final integration into expected annual damage can reasonably live in your own code, a few lines of arithmetic, as long as the API gives you the per-severity losses and every assumption behind them is visible: building type, number of stories, replacement value, which return periods were used.

The test: take one coordinate to a 1-in-100-year dollar loss, then write down every assumption behind that number. If you cannot list them, neither can your auditor.

3. It carries the historical record, not just projections

Projections tell you where the risk is going. The record tells you what is already true. An API that holds both lets you cross-examine each with the other, and that cross-examination is the strongest credibility check in the field.

Useful scale here: our event layer holds 2.6 million historical flood events and 50,000 landslides, queryable by radius around any coordinate. The step beyond raw events is flood-trigger thresholds: the rainfall that has historically flooded a specific site. At one Thai manufacturing site in our worked example, 123 recorded flood episodes resolve to a median trigger of roughly 15 millimetres of daily rain. When projections push more days past that observed trigger, you have a concrete escalation line rather than “risk goes up.”

The record also catches what models miss. A Houston-area site in the same portfolio reads near zero on modelled future flood depth, yet the event record shows 39 flood episodes nearby. One of those two sources is misleading you, and without the history you would never know to ask.

The test: ask the API when this site last flooded and how much rain it took. Most cannot answer either question.

4. Its scenarios and horizons match the disclosure you will write

If the output feeds an IFRS S2, ESRS, or California SB 261 disclosure (the main climate disclosure rules), the scenario set is not a preference, it is a requirement. Scenario analysis expects at least a Paris-aligned low scenario (SSP1-2.6, roughly 1.8 degrees Celsius of warming by 2100) and a high scenario (SSP5-8.5, roughly 4.4 degrees), across horizons that map to business planning, typically 2030 and 2050 against a recent baseline.

Ask which scenarios are native model output and which are proxied or interpolated, and ask it per layer. In our own pipeline the 12-hazard projections carry all three scenarios natively, while the flood-depth layer carries two; we say so rather than papering over it. Any vendor should be able to give you the same per-layer answer.

The test: put the vendor’s scenario list next to the framework you report under and look for gaps. Then ask which scenarios are native.

5. It tells you when it does not know

A zero is the most dangerous number in climate risk, because three different situations all print as zero. The flood map may have no coverage at the site: not dry, just unmapped. The site may be modelled as outside the floodplain: dry, for now, per the model. Or the future projection may be missing and today’s value silently carried forward: a number that looks stable but contains no climate signal at all.

Those three zeros demand three different responses, and an API that will not distinguish them will eventually put an indefensible number in a disclosure. Look for explicit data flags on every value: coverage gaps, carried baselines, substituted defaults, partial results. This is unglamorous engineering, and it is the difference between a number you can defend in audit and one you cannot.

The test: run a site you know has flooded. If the API returns zero risk, does it tell you why, or just leave you to guess?

6. You can rehearse the whole pipeline before you spend

Integration is where the evaluation cost lives. A serious climate risk API offers a dry-run mode: the full request-response cycle, realistic response shapes, every endpoint, unbilled. That lets you build and test the entire integration, polling, parsing, error handling, before the first paid call.

The companion feature is pricing you can compute in advance. Per-call credits with published rates mean you can price a 10-site screen, or a 5,000-asset portfolio, on paper before running it. “Contact sales” pricing on a developer product signals that the vendor has not decided what the product costs, and your budget owner will notice.

The test: build your full integration against the sandbox, then compute the exact cost of your first real portfolio run before you make it.

7. It handles portfolios, not postcards

A real assessment takes minutes of computation per site, and real portfolios run to thousands of sites. That means the API must be built around asynchronous jobs: submit, get a job ID, poll for status, fetch results. Batch endpoints matter just as much, and so do partial-failure semantics. One bad address in a batch of 5,000 must fail as one item with its own error, not kill the other 4,999. Upstream satellite data sources hiccup; the API should retry transient failures and tell you it is doing so, rather than handing you a silent gap.

The test: submit a small batch with one deliberately broken address and watch what happens to the rest.

8. Every number traces back to a named dataset

The question that ends vendor relationships is “where did this number come from,” asked by an auditor two years after integration. Every value should trace to a named public dataset: climate projections from NASA NEX-GDDP-CMIP6, water stress from WRI Aqueduct, flood depths from JRC, damage curves from FEMA HAZUS and JRC, land cover from ESA WorldCover, cyclone tracks from NOAA IBTrACS. And the methodology that combines them should be published, including its limitations: which single climate model was used, what the grid resolution hides, the fact that global flood layers assume no levees or floodwalls exist.

A vendor that publishes its warts has thought about them. A vendor that publishes none has either solved physics or stopped looking. If you are still mapping the landscape of providers, our roundup of the best climate data APIs is a place to start.

The test: pick any one number from the output and ask the vendor to walk it back to its source dataset and formula. Time how long the answer takes.

See the chain produce a real deliverable

A checklist tells you what to look for. A worked example shows you what the result looks like when every step is in place. We ran the full chain across a ten-site manufacturing portfolio, hazards, flood depths, losses, expected annual damage, and the historical cross-check, with every assumption and data flag visible: read the manufacturing worked example.

Sites referenced are from an illustrative worked example, not real clients. Climate projections from NASA NEX-GDDP-CMIP6; water stress from WRI Aqueduct; flood depth from JRC; damage curves from FEMA HAZUS and JRC; land cover from ESA WorldCover; cyclone tracks from NOAA IBTrACS; rainfall thresholds from ERA5. Continuuiti publishes worked examples and tools on top of these third-party datasets.

Frequently Asked Questions

How do you evaluate a climate risk API?

Judge it by what it lets you build, not by its brochure. Check whether it covers the full assessment chain from address to dollar loss, ends in a loss figure rather than a rating, carries the historical record alongside projections, flags missing data, offers a sandbox, handles portfolio-scale batches, and traces every number to a named public dataset.

What is the difference between a climate risk API and a climate data API?

A climate data API returns raw inputs such as temperature or precipitation series. A climate risk API runs the full assessment chain on top of that data, resolving an address, projecting hazards, computing flood depth and damage, and integrating expected annual damage, so you get a decision-ready figure rather than a data feed to model yourself.

Why should a climate risk API return a loss figure instead of a rating?

A rating such as ‘flood risk: High’ ranks sites but cannot prioritize capital. A loss figure, such as an expected annual damage of 1.2 million dollars rising 40 percent by 2050, is something a board, an auditor, or an underwriter can act on. It requires depth-damage curves, a building type, and a replacement value behind every number.

What climate scenarios should a climate risk API support for disclosure?

For an IFRS S2, ESRS, or California SB 261 disclosure, expect at least a Paris-aligned low scenario (SSP1-2.6, about 1.8 degrees Celsius) and a high scenario (SSP5-8.5, about 4.4 degrees), across horizons like 2030 and 2050. Ask which scenarios are native model output and which are proxied, per layer.