This month, ApyHub turns five.
Five years is a long time for a bootstrapped startup to survive — especially one that spent most of it quietly disagreeing with how its own category was supposed to work. We were called an API marketplace for most of that time. We answered to the name because it was close enough, and because explaining what we actually were took longer than most conversations allowed.
So instead of a victory lap, I want to trace how a handful of decisions that once looked strange added up to something we can finally name. Because what we've spent five years quietly becoming isn't a bet on where APIs are going. It's where they already are.
01The pricing decision
Early on, we made a decision that confused almost everyone: we charged per API call, dynamically, based on the actual cost of the work — not a flat per-request fee, and not a credit system you need a spreadsheet to decode.
The logic was obvious to us and strange to everyone else. All APIs are not equal, and even the same API can't cost the same on every call, because the cost depends on the input and the ask. A trivial request and a heavy one aren't the same product. Charging the same for both isn't simplicity — it's one side subsidising the other and hoping nobody notices.
The market disagreed. We got pushback, and there were stretches where we seriously considered rolling it back to the flat-fee model everyone expected, just to stop having the same argument. For a long time, part of the job was simply explaining — customer after customer — why usage-aligned pricing was the fairer deal, even when it was the less familiar one.
Then large language models arrived, and every AI service on earth started billing by the token.
Suddenly we didn't have to explain anything. I won't pretend we saw tokens coming — we didn't. But the principle under our pricing and the principle under token billing turned out to be the same one: you pay for the work actually done, not for a flat abstraction of it. We'd committed to it early and held on through the years it was inconvenient.
That was the first sign we were reading this market differently than everyone around us. It wouldn't be the last.
02We never really fit the category
The bigger sign was in the shape of the whole business — not just how we priced a call, but how we structured the relationship between customers, providers, and us.
Every API marketplace let each provider set their own plans, tiers, and paywalls. Most still do: you're a shelf, the providers are the brands, and each brand prices its own box.
We went the other way and ran it like Spotify. One subscription for the customer, revenue distributed to providers based on what actually got consumed. You don't buy twelve plans from twelve providers on Spotify — you pay once, you listen to everything, and artists are paid from the pool by what people actually played.
Providers were wary, understandably — we were asking them to give up direct control of their pricing and trust a consumption split. But customers understood it instantly. One relationship, one bill, the whole catalogue, nothing to negotiate service by service. It worked, and it worked well.
At the time I'd have called that a billing decision. It wasn't. Looking back, it was the moment we quietly stopped being a marketplace — because a single subscription spanning an entire catalogue isn't how a marketplace behaves. It was the first hint of what we'd actually become, though it took us years to say it plainly.
03Which is why the label never fit
We kept calling ourselves an API marketplace anyway, because it was the closest word and the alternative required a paragraph. Marketplaces solved a genuine problem — aggregation, discovery, one vendor instead of twenty — and we did that part well. But we were never really one of them. We'd borrowed their name while we grew into our own.
This release is us owning the real one.
The marketplace model was built for a world where a human browses, evaluates, signs up, reads the docs, and integrates — slowly, at design time. That isn't the world software is built in now. Increasingly, software is composed rather than written: assembled from existing capabilities and called at runtime by applications and, more and more, by agents acting with no human in the loop.
You can't retrofit your way into that world. Bolting an MCP endpoint onto a decade-old marketplace doesn't make it ready for how software gets built today — it just puts a modern label on a legacy model. The reality underneath has to change. So ours did.
We brought providers onto our own servers, so we could stand behind real service levels instead of pointing at someone else's uptime when something broke. And the single subscription we started with became the one relationship through which humans — and now agents — discover, select, and call any capability in the catalogue.
We also opened the doors. Publishing on ApyHub is now open to any builder with a capability worth shipping. Point us at your endpoint, and the monetisation, billing, gateway, and distribution — all the machinery that quietly turns a good API into a second full-time job as a mediocre SaaS business — becomes ours to run. Yours is to build the thing only you can build.
I think this is one of the best times in years to be a specialist. The reason most excellent, narrow capabilities never break through was never the capability. It was everything around it. That's the part we want to carry, so builders can stay builders.
On the agent side, we made a deliberate choice about discovery. You don't load the entire internet into your head to search it — you ask when you need something. Agents should work the same way: an agent's attention is finite, and a thousand unused tool descriptions leave less room to think. So rather than hand an agent the whole catalogue up front, we followed the search-and-use pattern — the same approach Anthropic uses — where the agent searches for the capability it needs and calls it at runtime.
04We didn't bet on this future. We formalised it.
The interesting work was never building another place to list APIs. It's building the layer underneath — where specialists distribute what they build, and where software and agents consume it, through a single relationship.
A distribution and consumption layer for APIs. I should be precise about that phrase, because "distribution and consumption" can sound like a marketplace wearing a nicer suit. It isn't, and the difference is the whole point.
A marketplace does sit in the consumption path — it's usually the gateway your calls route through. But its real job ends at procurement: making the commercial relationship smoother. Discovery in one place, one gateway, simpler billing. Underneath, you're still stitching together a separate subscription for every vendor, each with its own plan and limits. The marketplace aggregated discovery; it never aggregated the relationship.
Our layer starts where theirs stops. One subscription covers every service in the catalogue, and you pay as you go for what you consume — we handle the metering and distribute the revenue to providers behind the scenes. No per-vendor plans, no seams to feel.
But the deeper difference is the technical side of consumption — the part most marketplaces treat as someone else's problem. If a call from your US application to an EU-hosted API spends a hundred milliseconds crossing the Atlantic before any work happens, a marketplace shrugs. That's the provider's headache. It was never what a procurement layer was for.
It is exactly what an infrastructure layer is for. Because we encourage providers to host with us rather than list an endpoint they run themselves, we can place a capability in a region close to the caller, stand behind real service levels, and answer for latency and uptime ourselves. Hosting is what earns us the right to optimise the call path at all — you can't move an endpoint closer to someone if you don't run it.
The test is simple: when a call is slow, or something breaks at 3am, whose problem is it? A marketplace points at the provider — the performance of the call was never its remit. A layer owns it, because the call was running on its infrastructure the whole time. That's not a rename. It's a different position in the stack: from the directory you check before you build, to the infrastructure you depend on while you run.
None of this was a gamble. Each decision looked strange the day we made it and obvious a few years later, and after enough of those you stop calling it luck. You were building for where the world was going, while everyone else built for where it happened to pay that year.
That world is now the one we're in. Software is composed, not written. It's called at runtime, as often by an agent as by a person. And it needs a layer to be distributed and consumed through — one place that owns the whole path, from a capability being published to a call being answered, in the right region, at the right moment, on a single relationship.
That layer isn't a prediction anymore. It's here, it's running, and we're the first to stop pretending it's a marketplace and name it for what it is.
We didn't arrive at this future. We've been living in it for five years. Today we're formalising it — and opening the door for everyone else to build in it too.