The API Selection Pressure

The Beehive integration took one session. 26 February 2026, a single afternoon — the Stock Feed API client landed in the morning, a command to load every active supplier through it landed by lunch, the trade-price importer was working before tea. Two days later the daily cron was firing and a stock report was hitting my inbox at first light. Two weeks after that, on 10 March, I wired in the restock API endpoint so the system would know not just what was in stock but when the next pallet was due.

One session. Nothing remarkable about the code. The remarkable part is that I never had to think about Beehive’s stock again. It checks itself.

The other suppliers — the ones who email a CSV when they remember — sit in a different category entirely. I check them when something prompts me. A customer asks about a product, I open my email, find the most recent feed, see it’s three weeks old, and have to decide whether the lines marked “in stock” actually are. Often they aren’t. The supplier with an API tells me. The supplier with a CSV is a Schrödinger’s catalogue.

Not a preference — structural

I want to be careful with how I say this, because it sounds like a technology argument and it isn’t.

It isn’t that I prefer API suppliers because they’re more modern. It isn’t that the CSV ones are bad businesses. Some of them make better furniture. Some of them have better margins. Some of them have been trading longer than the API suppliers have existed.

It’s that the API supplier compounds into the infrastructure and the CSV supplier doesn’t. Every day the Beehive API runs, the Indoor Luxury catalogue learns something — a product comes back in stock, a price ticks up, a discontinued line gets archived. The system absorbs it without anyone noticing. Six months in, the Beehive catalogue on the site is the Beehive catalogue in their warehouse, to the hour. The supplier and the storefront are the same surface.

The CSV supplier sits frozen at whichever moment I last imported them. The longer I leave it, the more drift accumulates between what they have and what I’m telling customers I have. The system can’t see them. They effectively don’t exist to it until I remember to look.

The Matthew Principle applied to data

There’s a line in Matthew: To everyone who has, more will be given. The kingdom of heaven, in context. But it’s also exactly what happens at the API layer.

To the supplier who exposes their data programmatically, the operator gives priority — automatic stock rotation, real-time pricing, restock notifications wired into reorder logic, the product feed staying fresh without anyone touching it. The supplier accrues attention they don’t have to ask for. They get more, in the form of catalogue real estate that updates itself, because they made it easy for the system to pay them attention.

To the supplier who doesn’t expose their data, the operator gives whatever residual attention is left after everything else has been handled. The CSV gets imported when there’s time. The stock gets checked when something breaks. The relationship has to be tended by hand, and hand-tending doesn’t scale.

This isn’t a moral observation. It’s not about deserving. It’s about which supplier the system can metabolise without effort. The one that’s metabolised effortlessly compounds. The one that requires effort decays.

The same physics, at every layer

Once I started looking for this, I started seeing it everywhere.

Government APIs work the same way. The EPC register publishes its data programmatically — every property’s energy assessment, every recommendation, every grant eligibility flag. I wired it into Energy Pages in a session. A homeowner types their postcode and sees their actual house, their actual rating, their actual eligibility — pulled live from the same dataset every other energy aggregator could be using and almost none of them are. The data was free. The presentation layer was the gap.

Companies House is the same shape. Free, authoritative, programmatic. Every UK company’s filings, every director, every charge. The operator who can wire it into a product is building on raw material no competitor can replicate at no licensing cost. The Insolvency Service has director disqualifications. Land Registry has ownership records. Planning Portal has every planning application in the country.

Each one is an unreplicateable dataset behind a search box from 2006. Each one is waiting for someone to turn it into something an ordinary person would actually use. The government collected the data and stopped there. The presentation layer is where the value accrues, and the door is unlocked.

Platform APIs work the same way too. The consultancy that authenticates against Stripe, Brevo, Shopify, Google Ads, Merchant Centre, GSC, DataForSEO once and then operates them from a single terminal for years — that consultancy serves clients in a way nobody clicking through dashboards can match. The one that’s still logging into a web UI for every task is making the same trade as the CSV supplier, in a different domain. They’re choosing manual.

I’m not arguing that everyone should learn to code. I’m arguing that the operators and suppliers who already have — or who can — compound away from the ones who haven’t. The compounding rate is not linear. It’s the kind of curve that produces five years of foundation by the time the late arrivals realise the foundation matters.

What’s actually getting selected

The strongest version of the argument: the supplier without an API doesn’t just lose to the supplier with one. The supplier without an API becomes structurally invisible to any business operating at scale through software.

I’m not their enemy. I’d happily stock their products. The system simply can’t see them well enough to keep them in rotation. Their lines drift out of stock without the storefront knowing. Their prices change without the website following. Their new releases sit in a PDF in someone’s inbox while their competitor’s new releases auto-populate three storefronts overnight.

The CSV supplier might be cheaper. They might have a better range. They might have terms an API supplier wouldn’t match. None of it matters if their catalogue is six weeks behind reality. The customer arrives, the product is listed, the order goes in, the supplier emails back “out of stock since April.” Trust costs more than the margin saved.

I think of it as structural Darwinism. The trait under selection isn’t quality. It isn’t price. It isn’t relationship. It’s metabolisability — can the operator’s infrastructure absorb this supplier without manual intervention? The ones it can compound. The ones it can’t don’t survive long-term in any portfolio operating on automation.

The piece for the supplier reading this

If you sell products into businesses that operate online — and almost everyone does now — your survival depends on whether the operators downstream of you can wire you in.

You don’t need to build a product API. You don’t need a developer team. You need to publish your stock, your prices, your product catalogue in a format the operator can fetch on a schedule and parse without configuration. A JSON feed at a stable URL is enough. A REST endpoint is better. Webhooks for stock changes are better still.

The cost of building this is small. The cost of not having it is your products quietly disappearing from your customers’ storefronts over the next eighteen months, while their competitors who do have it stay live. You won’t be told you’ve been deselected. The drift will just continue until you notice the order volume has thinned.

The kindest framing I can offer: the operators on your downstream side are not abandoning you. They are physically unable to maintain a manual relationship at the speed the market now moves. The work has been pushed up the stack. The supplier who exposes their data is the supplier who gets the work, because the system can do the rest.

The compounding gap

Beehive went live on 28 February 2026. By the time I’m writing this, eleven weeks later, the Indoor Luxury site has rotated several hundred Beehive products through in-stock and out-of-stock states without my touching the catalogue. The new lines that landed at Beehive in April appeared on the site within twenty-four hours. The lines they discontinued in early May vanished from the carousel the same week.

Eleven weeks of zero manual maintenance, on a catalogue that would have required hours of attention every week under the CSV regime. Time that compounded into architecture, content, client work — anything that wasn’t import-and-reconcile.

That’s the gap. Not the technology. The hours. And the hours compound into everything else.

The CSV suppliers, meanwhile, are running on the same hours-per-week tax they were running on the day I onboarded them. The cost isn’t going down. The catalogue isn’t getting fresher. The relationship has the same maximum bandwidth it had a year ago, because the maximum bandwidth is whatever my human attention can sustain.

The API supplier gave me a tool. The CSV supplier gave me a recurring obligation. One of those scales. One of those doesn’t.

I don’t think most suppliers have realised this is the choice they made. I don’t think most operators have realised they’re selecting on it.

The selection is happening anyway.

Related: The Moment I Stopped Clicking Buttons is the operator-side argument — every dashboard login is friction cosplaying as security. Ingeniculture is the practice of providing the infrastructure for the AI to thrive. The CLI Is the Interface is the developer-side argument from 2026 — the same physics, applied to where the work happens.