The Data Marketplace for Agent-Ready Web Data

A data marketplace does for datasets what an app store did for software: it puts supply in one place, with a description, a schema, a sample and a price, so a buyer can evaluate before committing. The alternative is the way most data still changes hands, which is a discovery call, a scoping document, a bespoke quote and a six-week wait before anyone sees a row.

The category has a well-earned reputation problem, and it is worth naming. A great deal of what is listed on data marketplaces is a dump: a CSV assembled at some unstated point in the past, sold with a row count and a field list and no way to check either. It arrives, it looks impressive, and its accuracy quietly decays from the moment it is generated. Nobody can tell you when a given value was last confirmed, because nothing recorded it.

That works, barely, when a human reads the file, spots the obvious staleness and compensates. It fails completely when the consumer is a piece of software that will act on the value without hesitating.

“Agent-ready” is not a synonym for “available over an API”. An agent is a consumer with a specific and unforgiving profile: it does not notice that a page looked odd, it cannot tell truncation from an empty result, it will treat a plausible sentence as a fact, and it acts immediately. Data sold to agents has to be built for that reader.

Four properties make the difference in practice, and a set that is missing any one of them will eventually cause an agent to do something confidently wrong.

A receipt is the smallest useful unit of proof: the source URL, the fetch time, and the hash of the page the value came from. Those three fields answer the three questions that matter when a number is challenged. Where did this come from? When was it true? Is the page still saying it?

The hash is the part that does the work people expect a timestamp to do. A URL tells you where to look; a hash tells you whether what is there now is the same document we read. If the hash no longer matches, the value is not necessarily wrong, but it is no longer supported by the evidence on file, and it should be re-checked rather than re-asserted. That distinction is the whole reason for keeping one.

First-seen is the quietest of the three and the one that changes how a dataset feels to use. With a first-seen date on every row, “what is new since Tuesday” is a query. Without it, it is a diff against a copy you hopefully kept, and every gap in your collection looks exactly like a genuine new entry.

Every set in the catalogue is the output of a feed that keeps running. Buying a snapshot and subscribing to the feed behind it are the same data at two different tempos, which is why the table below lists both what each one tracks and how often it re-runs.

The row counts are the rows published in the current snapshot after the sanity filter has run, not the raw fetch. Rows that fail the filter — an implausible number, a duplicate primary key, a version stamp that leaked into a price column — are withheld and counted, never silently corrected.

Two things are for sale and they are priced differently, because they are different products.

A job is a one-off: you describe a set, we build it, you get the rows with their receipts. Jobs start at £150 and are quoted per job, because the honest cost driver is not row count but how hard the sources fight back. A public register with a clean export and a site that changes its markup weekly are not the same work, and pricing them identically only means one of us is being overcharged.

A feed is the same set kept alive: it re-runs on the cadence in the table above, and you take the change rather than re-reading the whole thing. Feeds are billed monthly per feed. We are not quoting a per-feed figure here, because the feed pricing is being reset — the current numbers live on the pricing page, which is the page to trust if this one ever disagrees with it.

The reason the two exist together is that most buyers do not know which they need at the start. Buy the job, use the rows, and find out whether the answer decays. If it does, the feed behind it is already running; if it does not, you have paid once for a thing you only needed once. Start from the dataset catalogue if you want to see the shipped sets, or the live feeds if you want to watch one work before you buy anything.

The same five questions work on us and on everybody else, and they can all be answered from a sample. If a vendor cannot answer them from a sample, that is itself the answer.

Run these before you look at the row count. A large set that fails questions two and three is worth less than a small one that passes all five, because the small one can be trusted by software and the large one has to be checked by a person.