The consultant's guide to UK flood data APIs
By Chris Cameron-Hann · Published
Choosing between live warnings, historical hydrometry and flood mapping, with a practical workflow for a defensible project data pack.
If you have ever opened three agency tabs, downloaded a spreadsheet and then wondered which river level you actually needed, this is for you. Flood data is awkward because several perfectly reasonable questions sound almost identical. What is happening now? What happened during an event? What is the long-term behaviour of this catchment? What flood mapping applies to the site? Those questions need different evidence, even when the answers arrive as rather similar-looking JSON.
I would start with the question, rather than the cleverest integration. An API makes retrieval repeatable; it does not make every retrieved number relevant. This guide uses the TerraMCP registry snapshot in data/listings.json on 15 October 2026. The service descriptions, coverage and access statements below come from that snapshot. The workflows are my suggested way of using those records, rather than a claim that I have run a project through every service.
First, separate warnings, observations and mapping
The EA Flood Monitoring API is listed for England, offering public flood warnings, river levels, rainfall and monitoring-station observations. The EA Hydrology API, also listed for England, describes hydrological station metadata and quality-labelled flow, level, groundwater and rainfall time series. The NRFA API is listed for the United Kingdom, with gauged daily flows, catchment rainfall, peak flows and catchment metadata.
That is already a useful division of labour. For current operational context, look at Flood Monitoring. For a historical hydrometric investigation, inspect Hydrology. For gauged flow and catchment context across the UK, inspect NRFA. I am deliberately saying inspect: a catalogue description establishes a promising starting point, not the suitability of a particular station or time series for your calculation.
Flood mapping is a separate branch of the exercise. The registry describes the Defra Data Services Platform as supplying flood zones, SEPA Flood Maps as Scottish flood extent, and DataMapWales as the Flood Map for Planning Wales. A gauge observation and a mapped zone answer different questions. Keep both in the evidence pack if you need both, and label their roles before anybody starts combining them.
England: use Flood Monitoring for the question it answers
Flood Monitoring's registry record lists warnings and alerts, flood areas, water level and flow measurements, station information and rainfall. It records free open access without authentication or registration, under Open Government Licence version 3, with attribution requested. That makes it an approachable first connection for a small script or a site context check. Save the attribution alongside your retrieval instructions, rather than relying on someone remembering it when the report is almost finished.
The timing deserves a proper look. The enrichment says levels and flows are usually sampled every 15 minutes, but data is typically transferred once or twice per day, more often during heightened flood risk. Sampling interval and delivery interval are different things. A sequence with quarter-hour timestamps does not, by itself, establish that your copy was available a quarter of an hour after each measurement. Record the latest observation timestamp and the time you retrieved it.
There are some useful implementation notes in the same record. Responses may redirect, some endpoints have default length limits, and readings can arrive in batches. The record recommends using the since filter for a complete history and checking limit and offset metadata. For a repeatable extraction, I would store the request, follow redirects, inspect pagination, and retain the unmodified response before cleaning anything. That is much less exciting than a dashboard, but far more helpful when a colleague asks where a missing day went.
England: Hydrology needs a series selection step
Hydrology's listed data includes instantaneous and daily flow series, river levels, rainfall totals and groundwater observations. It also lists water quality parameters. The important point for a flood study is that the station alone is not the complete selection. Flow, level and rainfall are different quantities; instantaneous values, daily means and daily maxima are different summaries. Write down the parameter, units and aggregation you actually intend to use before fetching a long record.
The registry gives a concrete reason to be careful with identifiers: some stations need a composite key including a wiskiID because station identifiers are not always unique. Its groundwater notes also say sub-daily observations may mix 15-minute and hourly intervals. I would therefore keep the upstream series identifier and inspect actual timestamp spacing, instead of manufacturing a uniform sequence from the advertised resolution. An apparently tidy resampled file can hide precisely the irregularities you need to understand.
Bulk access has its own constraints. The record lists a soft limit of 100,000 rows per call, an overridable soft limit through _limit, and a hard limit of 2,000,000 rows. It says to use the batch API for bulk downloads and otherwise keep one non-batch request in flight. Those are snapshot values, not promises about future capacity. Build a resumable extraction with explicit date windows and consult the upstream reference before a substantial run.
UK catchment context: bring NRFA in deliberately
The NRFA record describes daily flows, catchment rainfall, peak flows and catchment metadata. Its authentication field says no controls currently, with NRFA terms applying. A second record, NRFA Data API, explicitly describes free access without an API key at the time recorded. I treat these as two catalogue routes into the same named service family, rather than two independent sources that corroborate each other.
My suggested workflow is to choose a candidate station, inspect its metadata, establish which record is available, and then decide what period and quantity the analysis needs. Do not silently substitute a daily series for an event-scale series simply because the download was easier. Equally, do not discard a daily record when the actual question concerns broader catchment behaviour. The useful choice depends on the analytical question, not the number of rows you can retrieve.
The licence field is NRFA Data Terms and Conditions, not the Open Government Licence attached to the EA records. Keep that distinction in the project register. A common downloading script can handle several providers, but a common software interface does not unify their terms. I would give every output file a companion note identifying its source, access date, selected station or series, and applicable terms. It makes later reuse a conscious decision rather than an accidental assumption.
Scotland and Wales need their own source decisions
For Scotland, the SEPA Time Series API describes river level, flow and rainfall time series through KiWIS. The access field says no key for normal access and a key for bulk access, with Open Government Licence 3.0 recorded. The registry also contains SEPA KiWIS Time Series API, whose enrichment explains that an access key is needed for large amounts of data over short periods. Again, recognise overlapping records before counting sources.
For Wales, NRW River Levels is described as Welsh river level data and records an API key through the NRW API portal. The separate NRW API Portal record describes Welsh flood warnings and levels, also with an API key. Both list OGL-3.0. That establishes the need to investigate credentials; it does not establish a price, a quota or an application turnaround time. Leave those unknown until you have checked the service documentation.
The England label on the EA records matters here. It would be convenient if an England integration automatically settled a UK-wide commission, but the catalogue does not support that assumption. For a project spanning jurisdictions, write a small coverage matrix: study area, observation provider, mapping provider, access requirements and outstanding checks. That gives your team a visible gap list before development time disappears into the wrong connector.
A practical extraction and review workflow
Suppose the brief is an event review near a river. Start by stating the event window and the question the observations should resolve. Find candidate stations and inspect their metadata before asking for readings. Save your station selection reasoning separately from the extraction code: proximity might be useful, but I would not treat the nearest returned station as automatically representative. The registry suggests nearest-gauge lookup as a possible use case; it does not certify hydrological representativeness.
Next, fetch a small sample and inspect units, timestamps, missing values and quality information. Confirm that the selected quantity is what the analyst meant. Only then retrieve the complete window, respecting pagination and provider constraints. Save raw responses, request details and a separate processed table. If a transformation changes timezone, units or aggregation, make that an explicit processing step with an explanation. Your reviewer should be able to distinguish source data from your decisions without reverse-engineering the notebook.
Finally, produce a short evidence note with the station and series identifiers, retrieval time, observation period, known gaps, quality flags, terms and source links. Record an empty result as an empty result, rather than turning it into zero. If two services appear to disagree, compare their quantities, time windows and processing before averaging anything. The first useful output is often a clear explanation of why two numbers cannot yet be compared.
Where MCP helps, and where I would keep a script
EA Flood MCP describes access to near real-time warnings, water levels, flow and station information. MCPBundles EA Hydrology describes a hosted wrapper for hydrological stations and time-series observations. They are plausible routes for conversational discovery: asking what sources or stations might be relevant, inspecting metadata and assembling an initial query plan. Their listed capabilities should not be stretched into claims about tools the registry has not verified.
For a repeatable numerical extraction, I would still want the exact upstream request and response retained, whether an MCP server or a direct script made the call. Ask the assistant to return identifiers, parameters and timestamps with its explanation. If it cannot show them, you have a useful lead rather than a completed evidence trail. A polished paragraph is easy to generate; a recoverable chain from source to calculation is the thing worth keeping.
The handover I would want to receive
Give the next person a compact manifest, not a mystery folder called final-final-data. Include source records, upstream documentation, retrieval instructions, licence notes, raw files and the processing steps that produced the working table. Explain which parts of the original question remain unanswered. Mapping gaps, uncertain series selection and unavailable quality information are legitimate findings; concealing them behind a successful HTTP response is not helpful.
The catalogue itself records Flood Monitoring as a trial or beta service without a service-level guarantee and says it should not be relied on for safety-critical applications. Keep that limitation attached to any proposed operational use. For ordinary consultancy data gathering, the opportunity is straightforward: use the right service, keep the context and make retrieval reproducible. You can automate quite a lot of the clicking while leaving the important engineering judgements visible to the people responsible for them.