Find a Tender API: What It Gives You and What It Doesn't

Yes, and it is genuinely usable. Find a Tender exposes notices as OCDS release packages — the Open Contracting Data Standard, which models a procurement as a process with a stable identifier and a series of releases against it. You request a window of releases and page through them; there is no key and no registration for reading.

It is worth separating two APIs that share a service, because the documentation situation invites confusion. The service's API documentation page describes the submission side, which is how a buyer publishes a notice and which does require a key. The read side used here is the OCDS endpoint, and it is anonymous.

The same is true of Contracts Finder, and it is the more commonly misread of the two. Its published documentation describes an OAuth flow, and that governs the write side. The read endpoint returned 200 to an honest user-agent with no key when we tested it directly against the running service on 1 and 2 September 2026.

So the access story is easy. The modelling story is where the work is.

The unit is a release, and releases are grouped under an `ocid` that identifies the whole procurement process. A planning notice, the tender notice, an amendment and the eventual award all share one `ocid`, which is what lets you fold a republished notice into a change rather than counting it twice.

The fields you will spend your time on are predictable: the buyer among the `parties`, the classification on `tender.items[]`, the delivery addresses, `tender.value`, and `tender.tenderPeriod.endDate`, which is the closing date and the single most decision-relevant value on the whole object. The release tag tells you the stage — planning, tender or award — and maps cleanly onto pipeline, opportunity and award.

OCDS is a good standard and it is still only a shape. It says where a value goes; it does not make a buyer put one there. Values are frequently absent, delivery addresses are frequently absent, and a notice with neither still has to be classified somehow. Any usable filter is going to be a set of fallbacks rather than a single field read.

Find a Tender's window is driven by `updatedFrom` and `updatedTo`, and the word is doing real work: it selects releases updated in the window, not procurements started in it. A four-year framework amended last week appears in a seven-day window even though the process began in 2022.

That single behaviour has a large practical consequence, and we tested it rather than assuming it. Widening a window buys award history, not live opportunities. Running the same collection over 7, 30 and 90 days, the 7-day window returned 1,706 Find a Tender releases and the 90-day window returned 30,019 — but going from 30 days to 90 days tripled the surviving row count and added no open opportunities at all.

We also tried 180 days and rejected it on the evidence. Its first two seven-day slices covered 5,173 releases and yielded one in-area row between them, at roughly two hours of deliberately polite paging. If you are building an alert rather than an archive, a short window run often beats a long window run occasionally.

Both registers throttle, and throttling is the failure that hurts most because it is silent. Find a Tender refused a burst at 0.35 seconds per page. Contracts Finder returned a 429 on two requests two seconds apart. If a walk treats an exception as a dead source, one 429 mid-window truncates it and the run reports a thin day rather than a throttled one.

This is the headline gap. Neither register offers a server-side filter on CPV classification, region, value or postcode on the OCDS endpoints. `stages` filters server-side on Contracts Finder and is the only thing that does. Everything else has to happen after the bytes arrive.

The scale of that is easy to underestimate until you count it. Answering one narrow question — what electrical work is out to tender in Cornwall and Devon — over a 90-day window meant pulling 30,019 releases from Find a Tender and 9,580 from Contracts Finder, 39,599 in total. Of those, 1,210 matched an electrical CPV family, 31 were deliverable in the two counties, and 23 records were published after the value threshold and the fold. That is 0.078% of the national window surviving.

CPV matching itself is prefix work plus judgement. Electrical installation, fire and security, lighting, data and comms, maintenance and compliance and EV charging each have their own families, and the parent refurbishment codes have to be admitted only when the title also matches an electrical keyword, or a general building refurbishment arrives labelled as electrical work.

Geography is harder than CPV, because it is often not stated. Find a Tender releases may carry an ITL region code on a delivery address; Contracts Finder publishes region as an English name such as “South West”, never as an ITL or NUTS code, so it falls to postcodes and town names. Both of those have traps, and one of them cost us a row.

This is the bug most likely to bite anyone building on Find a Tender for the first time, and it is invisible until a human clicks a link. A notice's attachments live in the same `documents[]` array as the notice itself. Take the first https URL in that array and you can end up citing a pricing spreadsheet at `/Notice/Attachment/A-21364` rather than the advert.

It hit 2 of 23 rows in our run, and one of the two was an open opportunity — which is the one link on a page like that which absolutely has to work. The fix is to stop trusting position: a document only counts as the notice when it says so by `documentType`, or when it is a `/Notice/` URL that is not a `/Notice/Attachment/` one. Failing both, construct the URL from the register's own id scheme.

Geography has an equivalent trap. Our first completed run placed an East of England NHS trust's lift replacement in Cornwall, because the buyer's address locality reads St Ives — and there is a St Ives in Cambridgeshire as well as the one in Penwith. Two rules killed the class rather than the instance: a stated postcode is a veto over any town name on the same address, and a town is read from the locality and never from the free-text street line, because “Cornwall Road” and “St Ives Court” exist in most English cities.

They look like two instances of the same thing and they are not. The differences below are all confirmed against the running services on 1 and 2 September 2026, and each one costs you something if you assume otherwise.

The most important structural point is coverage rather than mechanics: in 90 days the two registers did not overlap once. Contracts Finder now carries the pre-Act tail rather than mirroring Find a Tender, which means deduplicating across them is much less work than expected and skipping one of them loses real notices.

The table below is six rows out of the 23 published by the Cornwall & Devon electrical tenders feed in its 2 September 2026 run: two open opportunities, one closed, and three awards, spanning both registers.

Two things in it are worth looking at as an API user rather than as a bidder. The last row is the Contracts Finder id problem made visible — the release id carries a trailing sequence the notice page does not, so the link is shorter than the id it came from. And the Corserv notice in the first row has a twin: the same work was published under two different `ocid`s, once closing 26 August and once closing 9 September, because the buyer re-advertised. Sorted by deadline the live one is at the top; sorted by publication date it would sit under fifteen awards.

If you want award coverage across the UK and EU rather than one region and one trade, that is the Tender & Award Watch feed, which runs daily against the same registers.

The endpoints hand you releases. Everything that makes those releases usable is yours to build, and it is worth being clear-eyed about the list before starting: a CPV family table with a keyword gate for the parent codes, a geography resolver with postcode veto and locality-only town matching, a fold on `ocid` so republished notices become changes rather than duplicates, a document resolver that will not cite an attachment, and a backoff that treats a 429 as a retry rather than a dead source.

None of that is difficult. All of it is the difference between a feed and a firehose, and none of it is in the API. If you would rather consume the result than the raw window, both feeds above serve exactly these rows with the notice link on every one.