01Introduction
Someone raises it in a planning meeting roughly once a year. Usually an engineer, usually one who has spent the past six months inside a service nobody outside the company will ever see.
"We should sell this."
I have been in that meeting on both sides of the table. The answer was usually no. I think the answer was right, and I think it is worth writing down why, because something about it has changed.
02What we built
Before ApyHub, several of us worked at an edtech company. We built the product we were paid to build. We also built seven other things.
Master data management, because customer records arrived from six directions in five different shapes. Notification handling, because email, push, and in-app messaging each needed somewhere to live and nobody wanted three of them. Contract management.
Then file processing, across every format a school or a corporate training department could produce. Underneath it, conversion: Word to PDF, PDF to Word, HTML to PDF, Excel to JSON, image format conversion, and the compression that kept a 12MB upload from stalling on a classroom connection.
Video processing, because a course had to play on a five-year-old tablet in a classroom and a new laptop in an office with the same reliability. And watermarking, so licensed content could not walk out the door.
Two of those were the reason customers chose us. The video pipeline handled edge cases in course content that general-purpose transcoding handled badly, and prospects noticed during evaluations. Watermarking came up in conversations with rights holders before contracts were signed.
The other five were infrastructure. Load-bearing, invisible, and permanently ours. No customer ever chose us because of our notification handling. Every customer would have left if it stopped working.
Every one of the seven still runs. Every one is still being maintained by somebody. None of them was ever sold.
03The meeting where we said no
The watermarking service came up more than once. It was genuinely good, it solved a problem other content companies had, and someone had done the work of finding out that they were paying for worse versions of it.
The answer was no every time. Here is the bill the person saying no was reading.
Documentation, written for people who cannot walk over and ask a question. Support, which means someone answering tickets from people who are not our customers about a product that is not our product. Billing, metering, invoicing, tax handling in each jurisdiction, and chasing failed payments. A versioning and deprecation policy, because external consumers cannot be migrated by announcing it in a standup. A service level commitment, which changes the on-call rotation permanently and for everyone. Security and compliance review, because the first enterprise buyer sends a questionnaire before it sends a contract. And marketing, because a product nobody has heard of earns nothing.
Each item is small on its own. Together they are a company. It has its own roadmap, its own headcount, and its own ways of failing, and it competes directly for attention with the thing you are actually trying to ship.
And it makes sense. You have to be sharp about the one thing you are actually good at. Every hour that goes somewhere else is an hour the product does not get. Saying no to the watermarking business was protecting the focus that made the company work.
04It happens everywhere
This is not something one management team decided. It is what happens when focus is scarce and everything competes for it. According to the Postman State of the API Report, sixty-one percent of a typical organization's APIs are for internal use only, up from fifty-eight percent in each of the two years before, while public APIs account for fourteen percent. Most API work happens where nobody outside the building sees it.
The same report found something I keep thinking about. When API developers leave a company, the top two worries are outdated documentation and APIs nobody owns anymore. The service keeps running after the person who wrote it leaves. What they knew about it does not.
Meanwhile the cost of holding all of it keeps climbing. Chainguard's 2026 Engineering Reality Report, based on a survey of 1,200 engineers and tech leaders across the US and Europe, found that engineers spend sixteen percent of their week writing code and building new features, while ninety-three percent say that is the most rewarding part of the job. The rest goes to maintenance, technical debt, and fragmented tooling.
Seven services, five of them infrastructure, all of them maintained forever, none of them earning anything. That is a normal company.
05What changed
Every item on that bill can now sit with someone else. Documentation, billing, gateway, metering, distribution, compliance artifacts. Nobody has to build those from scratch to publish an API anymore. That was the bet behind ApyHub, and it came out of watching good teams decide, correctly, that publishing was not worth what it cost them.
The bigger change is who does the calling.
APIs are increasingly consumed by agents rather than by developers reading documentation. The 2025 Postman State of the API Report, based on responses from more than 5,700 developers, architects, and executives, found that only twenty-four percent of developers design APIs with AI agents in mind, while eighty-nine percent use generative AI in their daily work. Consumption moved faster than design did.
You can see this in any coding setup now. Claude Code, Cursor, GitHub Copilot, OpenAI Codex, and the growing set of agent runtimes that speak Model Context Protocol all reach for external tools mid-task rather than waiting for a developer to wire an integration in advance.
That matters for anyone sitting on an unpublished service, because agents pick differently than people do. A developer evaluating an API reads a landing page, compares three options, and integrates one at design time. An agent searches for a capability the moment it needs one, reads a machine-readable description, and calls it. Narrow and precisely described wins. Broad and impressive loses. Which is the exact shape of a service built to do one job for one product.
It changes the math too. Ask a coding agent to build a document conversion routine and you pay tokens for writing it, debugging it, and often writing it again. Ask it to call an endpoint that already works and you pay for the request. Over a long session that adds up.
Every endpoint in the ApyHub catalog is reachable through our MCP server, so an agent can search the catalog, evaluate what a service does, and call it without anyone writing a wrapper or a tool definition first. A service published this quarter reaches a kind of caller that did not meaningfully exist three years ago.
06What actually gets published
The services that do well in a catalog are small and specific. Boring, in the way infrastructure is boring.
Document and file work is the biggest category: PDF to Word, Word to PDF, HTML to PDF, Excel and CSV conversion, document text extraction, OCR on scanned pages, invoice and receipt data extraction. Then image and video, meaning compression, resizing, background removal, thumbnails, watermarking, transcoding, and audio extraction. Then validation and enrichment, which eats a lot of developer time: email and DNS checks, phone numbers, VAT numbers, address normalization, IP geolocation, currency conversion.
After that, text and AI endpoints for summarization, translation, entity recognition, text to speech, and resume parsing. And a long tail of utilities every builder writes at least once. QR codes, barcode reading, webpage extraction, screenshots, SERP checking.
If you build applications, SaaS products, mobile apps, or agent workflows, you have written one of these yourself. So have a lot of other people. That is the point.
See what is already in the catalog
07What I would say in that meeting now
The answer is still no for most services. Publishing everything is a bad idea. A catalog full of thin wrappers helps nobody.
What I would ask instead is five questions.
- Does someone else have this problem and not want to own the solution? If the demand is theoretical, stop.
- Do general-purpose tools handle it badly? Specificity is the entire advantage.
- Is it stable? A service that changes every sprint for internal reasons will break external consumers.
- Can one sentence describe it? If it takes a paragraph, an agent will not select it and a developer will not evaluate it.
- Would you support it in eighteen months? Not enthusiastically. Willingly.
Watermarking would have passed all five. Our contract management would have failed the first and the second, and I would have argued for it anyway, which is a good reason to have the questions written down.
One cost I should be upfront about. Publishing an internal endpoint gives it external callers, and that changes your rate limiting, your capacity planning, and your on-call. That is real work. Less work than building a company around the service. More than none.
08Where ApyHub fits
ApyHub is the distribution and consumption layer for APIs. Builders publish a capability. We take the bill from earlier. Developers and agents discover and call it at runtime.
The point is the focus. You stay sharp on the thing you are good at, which is the capability itself. The documentation, the support inbox, the billing, the versioning, the compliance questionnaire, the distribution: that is our work, not yours.
Publishing takes one of two paths. Upload an OpenAPI spec, or point at the endpoint and our system drafts the schema, the documentation, and the request and response examples. You edit what is wrong, set your price, and publish. Ten minutes for a single REST endpoint with standard authentication. Under an hour for most first publishes.
You keep the intellectual property. You set the price and change it whenever you want. You can sell the same service elsewhere, because exclusivity is not part of the agreement. Host it on your own infrastructure and we route to it, or deploy onto ours and we handle regions and service levels, which puts the service closer to whoever is calling it.
Every published endpoint ships with machine-readable certification covering data residency, retention, sub-processors, and alignment with GDPR, SOC 2, and ISO 27001. That artifact is what enterprise procurement asks for, and assembling it alone takes a solo provider a long time.
Pricing when the cost varies per call
A fixed price per call works when every request does roughly the same amount of work. Plenty of what gets published does not behave that way.
Converting a 2-page document and a 200-page document are not the same job. OCR on one scanned page and on a 400-page archive are not the same job. Transcoding thirty seconds of video and transcoding an hour are not the same job. And an AI endpoint where the caller picks the model, sends 200 tokens or 50,000, and gets back a short answer or a long one is a different cost on every single request.
For those, the provider sets a base price in atoms and then reports the real cost after processing, by returning a header on the response:
http
HTTP/1.1 200 OK
Content-Type: application/pdf
X-Apy-Atoms: 70
The gateway charges the static base price before it calls your API, then reconciles against the number you report. If the real cost was higher, it charges the difference. If it was lower, it refunds it. If you return nothing, the base price stands.
A Word to PDF endpoint priced at 50 atoms base plus 2 per page charges 70 atoms for a 10-page document and 250 for a 100-page one, on the same endpoint. A text to speech endpoint can price by voice model. An AI endpoint can combine model cost, input processing, and output processing into one figure per request. Long-running jobs report the total when the job finishes.
This is what makes AI endpoints workable. Charge the same for a 200-token request and a 50,000-token one and somebody is paying for somebody else. You lose money on the heavy calls or you overcharge the light ones.
The argument runs in the other direction too, which is the half I find more interesting. Whatever infrastructure service is next on your roadmap, someone has probably already built it and is already maintaining it. The catalog holds 400+ services and 1,500+ endpoints, with new APIs and providers onboarded continuously, across document and file conversion, OCR, data extraction, validation, geolocation, image and video processing, text and AI endpoints, and SEO utilities. All of it is callable directly over HTTPS, or through MCP if an agent is doing the calling.
Your idle service is someone else's infrastructure problem. Theirs is yours.
09Conclusion
The seven services we built at that edtech company were not a mistake, and neither was the decision to keep them. Productization costs documentation, support, billing, versioning, service levels, compliance, and marketing, and that is a second company. Declining to start one while shipping the first is a reasonable call, and it is the one I have seen made every time.
What changed is that the second company can belong to someone else. You keep the capability and the focus. We take the load around it.
Somewhere in your company there is an engineer who has spent six months inside a service nobody outside the building will ever see. They are right about it. Give them a way to find out who else needs it.
10FAQ
How long does publishing actually take? Ten minutes for a single REST endpoint with standard authentication. Longer for APIs with many endpoints, custom authentication, or webhooks. Most providers complete their first publish in under an hour.
Do I keep ownership of my API? Yes. You retain one hundred percent of the intellectual property. The provider agreement explicitly allows you to monetize the same API elsewhere, including in your own product, on another catalog, or through a direct enterprise contract.
Do I need to host it myself? No. Host it on your own cloud, a VPS, or on-premises and we route to it, or deploy onto our infrastructure and we handle regions and service levels.
Do agent calls count? Do I get paid for them? Yes. Every call is a call regardless of caller. Whether a developer triggers it from an IDE or an agent calls it through MCP, the provider earns the same.
Who can publish? Anyone with a working API and the ability to sign a standard provider agreement. There is no minimum company size, audience, or revenue threshold. Individual developers are paid directly to their bank account without registering a company.
Does every submission get accepted? No. The catalog is curated and services are turned down at review, including ones that would generate revenue. Every API should do something the others do not.
Can Claude, Cursor, or GitHub Copilot call these APIs? Yes, through MCP. Every endpoint in the catalog is reachable via the ApyHub MCP server, so any agent runtime that speaks Model Context Protocol can search the catalog, read what a service does, and call it. No wrapper, no tool definition, and no glue code on your side.
Why call an API instead of having the agent build it? Token cost and maintenance. Generating a conversion routine inside an agent session burns tokens on the implementation, the debugging, and usually a second attempt. Calling an existing endpoint costs the tokens in the request. The code an agent writes for you is also code you own and maintain from that moment on.
What kinds of APIs are in the catalog? Document and file conversion including PDF to Word, Word to PDF, and HTML to PDF. OCR and document data extraction. Image and video processing including compression, resizing, watermarking, and audio extraction. Validation and enrichment including email, phone, VAT, address, and IP geolocation. Text and AI endpoints including summarization, translation, entity recognition, and text to speech. Plus utilities like QR code generation, webpage extraction, and SERP checking. The full list is in the catalog.
I am building an app and need one small capability. Do I have to subscribe to each API? No. One subscription covers the whole catalog. Usage is billed in atoms and the headroom you buy against one API is spendable against any other. See pricing.
How do I set the price? You choose how many atoms a call costs. Atoms are ApyHub's usage unit, small enough to bill a lightweight endpoint and expressive enough to price a heavy compute call. Price flat, or tier by complexity, payload size, or compute. Change it whenever you want.
What if some requests cost me more than others? Set a base price in atoms and report the real cost of each request back to the gateway. It charges the difference or refunds it. A conversion endpoint can price per page, a transcoding endpoint per second of media, and an OCR endpoint per scanned page, all on one endpoint.
How do I price an AI or LLM endpoint? Combine the factors that drive your cost and report the total per request. Model selected, input tokens, output tokens. That way a 200-token request and a 50,000-token request are priced honestly rather than one subsidizing the other.
11About ApyHub
ApyHub is a curated API catalog and the trusted operational layer around it. Developers and AI agents discover, evaluate, and call production-ready APIs through a single subscription billed in atoms, a usage unit that reflects the actual work each call performs.
Every endpoint is verified before it is listed and ships with machine-readable certification covering data handling, residency, and alignment with GDPR, SOC 2, and ISO 27001. Every endpoint is MCP-ready by default, so agents can discover and call capabilities without hand-written wrappers or tool definitions.
The catalog holds 400+ services and 1,500+ endpoints, with new APIs and providers onboarded continuously. ApyHub is headquartered in Amsterdam, with offices in the Netherlands, Greece, and India, and serves 650,000+ developer workspaces every month.
The free tier requires no card. If you have built something worth publishing, start at apyhub.com/become-a-provider.