Most of our users won't be human

More and more users of Open Opportunities are agents not humans.

So we're building Open Opportunities as a tool that serves software agents as well as people. A bid team's assistant might check overnight for new tenders. A sales tool might build a pipeline, or a model might draft a market report. A person still decides whether to bid. The agent does the searching and the reading.

We treat agents as first-class customers alongside people, and we are building every Open Opportunities product with them in mind.

A person who is unsure what a field means can email us. An agent cannot, so it guesses, and a wrong guess reaches the bidder as a fact. If an agent read the date a notice was published as the date bids are due, a supplier could miss a deadline without knowing why. Our job is to make sure an agent has no need to guess.

Our web app runs on our API

The Open Opportunities web app has no private route to the data. Every search a customer runs in the app goes through the same API we sell. Anything the app does, a developer or an agent with an API key can do too. The API is how our own product works, so we cannot let it fall behind.

Our documentation has instructions for models

We use language models to write code against our API, and we are happy for customers to do the same. Our API documentation includes a section written for developers and the models they work with. That section can be downloaded as a single file to add to a model's context.

The section tells a model how to work with procurement data correctly:

• Buyers publish different amounts of detail. Every record carries a title, our CPV codes and a published date, and a model should check for any other field before using it.
• Field names must come from our published schema. A model should never assume a name that a procurement API "ought" to use.
• Our search ranks results by relevance. A model should not filter out results that do not contain the search term word for word, because those are often the best matches.
• The same tender can appear on more than one portal. A model can use our cross-source identity field to remove duplicates.
• We update twice a day, usually around 06:00 and 11:00 GMT. A model should not poll between those times, since it will receive no new data.

The documentation also sets out how pagination ends, the limit of 20 calls a minute, and how to read an error.

Every date in a record says which date it is. release_date is the publisher's own publication date. tender_end_date is the deadline for submissions. Contract start and end dates have their own fields. The release_tags field marks each notice as a planning notice, a tender or an award. An agent can therefore tell a live opportunity from a contract already let before it reads any award fields.

How we enrich the data

We collect notices from more than 1,050 official sources. We keep what the buyer published separate from what we add, so an agent can use either.

We assign five codes from the Common Procurement Vocabulary (CPV), the EU's procurement classification, to every notice. These sit in fields marked cpv_aug (augmented), next to any codes the buyer supplied. Each of our codes carries a relevance score. Because every notice has these codes, filtering on one of them finds matching notices in every country and language.

We also read each notice and record the work the buyer needs done. Our search matches against that record. Across 100 searches on each of nine portals, it found 94% of the relevant open tenders. We published the benchmark with every portal's result left in, so anyone building an agent can check it before trusting it.

We convert values into pounds, euros and dollars on the date we collect the notice, and the documentation names our exchange rate source. We clean buyer addresses and give every buyer a standard country code. Every record links back to the original publication through tender_url. We check every field of every source every day and publish what we find, including errors.

What comes next

We will soon release aggregation tools. These will return counts, averages and sums across all Open Opportunities data, using the same filters as our search. An agent will be able to measure a market without downloading every record. We are also testing products built on the Model Context Protocol (MCP), the open standard that assistants such as Claude use to connect to outside data.

Every API call carries a bearer token issued against a customer's credentials.

If you are building an agent that needs procurement data, start with the API documentation, then talk to us about access.

Illustration: Screen grab from the excellent "The Humans Are Dead" by Flight of the Conchords, offered without apology.