Most companies with a good API give it away, and most of them have never asked whether that was a decision or an accident.
It is usually an accident. The API was built to serve the mobile app, opened up so a partner could integrate, and never revisited. Meanwhile it quietly became the thing several customers depend on most.
Decide what the API is for
Before any pricing conversation, answer one question: is the API a channel, or a product?
As a channel, it exists to make your main product stickier. Integrations reduce churn, partners extend your reach, and the API earns its keep indirectly. Charging for it works against the goal, and free is correct.
As a product, the API is the thing customers buy. Data providers, payment processors, communications platforms — the endpoint is the deliverable and pricing is the business model.
Most companies are somewhere between, and the useful test is whether anyone would pay for the API if your main product vanished. If several customers would, you have a product and are giving it away.
Getting this wrong in either direction is expensive. Charging for a channel API kills the integrations that were reducing your churn. Giving away a product API funds someone else's business with your infrastructure.
The pricing models, and when each fits
Per call. Simplest to understand and to implement. Works when calls have roughly equal cost and value. Breaks when one endpoint returns a boolean and another runs a heavy computation — customers arbitrage toward the expensive one, and your margins follow.
Tiered subscriptions. A monthly fee with an included allowance. Predictable for both sides, which finance teams on both ends prefer to metered billing. The design work is choosing tier boundaries that match real usage clusters rather than round numbers, and deciding what happens at the limit — hard stop, overage, or throttle. That decision shapes customer experience more than the price does.
Per unit of value. Priced by the thing the customer cares about — verified identities, messages delivered, documents processed — rather than by HTTP requests. Harder to meter, considerably easier to justify at renewal, and it survives you changing your API design.
Token or compute metering. Increasingly common where the endpoint wraps something expensive, particularly model inference. Aligns your price with your cost, which protects margin, but it is genuinely hard for customers to forecast. Pair it with spend caps or you will have a bad conversation about a surprise invoice.
Freemium. A free tier generous enough to build on, paid tiers for production volume. The engine behind most successful developer products, and the risk is a free tier so generous that nobody upgrades. Set the boundary at production readiness — rate limits and support, not crippled functionality.
Fig. — The model is the easy decision. The metering underneath is the build.
The infrastructure you actually need
This is where monetization projects stall, because charging for an API requires machinery that a free API never needed.
Metering that customers trust. Every billable event recorded accurately, attributed to the right key, and visible to the customer in near real time. A customer who cannot see their usage until the invoice will dispute the invoice.
Quota enforcement. Limits that actually stop consumption, distinct from rate limits that smooth traffic. These are different mechanisms and conflating them produces either runaway bills or throttling that looks like an outage.
Key management with scopes. Customers need multiple keys — production, staging, per-environment — with independent limits and independent revocation.
A self-serve path. If signing up requires talking to sales, you have lost the developer audience entirely. The ability to get a key and make a first call in minutes is the single strongest predictor of adoption for a developer product.
Build versus buy is a real decision here. API management platforms handle metering, quotas, and billing integration, at a per-call cost and a loss of flexibility. Rolling your own is a quarter of engineering that produces no customer-visible feature. For a first attempt, buy.
Documentation is the sales page
For a paid API, documentation is not support material. It is the entire pre-sale experience, and it converts or it does not.
A developer evaluating you will not book a demo. They will open your docs, look for the thing they need, try to picture the integration, and decide within a few minutes whether to proceed. If that reading produces uncertainty — about what an endpoint returns, what the errors mean, what it costs at their volume — they leave, and you never learn they were there.
The things that measurably help: a runnable example on the first page, real response payloads rather than schemas alone, an explicit error reference, and a pricing page with a calculator rather than a table. That last one matters more than teams expect. "Contact us for pricing" on a developer product is read as expensive and slow, and the evaluation ends there.
A changelog is worth more than it looks, too. It signals that the API is maintained, which is the quiet question underneath every integration decision — nobody wants to build on something that will be abandoned.
Support is part of the product now
Charging changes the relationship in a way that catches teams out. A free API's users work around problems. A paying customer files a ticket, and reasonably expects an answer.
That means budgeting for developer support before launch rather than after the complaints. It does not have to be large — a responsive channel, a status page that is actually updated, and someone who owns the queue. But it has to exist, because the first outage after you start charging is the moment your customers decide whether this was a good decision.
Status and reliability communication deserve particular attention. An API customer has built your uptime into their product, so your incident is their incident, and they are explaining it to their own users. Teams that handle that well retain customers through failures that would otherwise have cost them.
Pricing mistakes that are hard to undo
Starting too cheap. Raising prices on existing customers is painful and generates churn at exactly the wrong moment. Starting higher with negotiated discounts leaves room to move.
Pricing against your own cost. Customers pay for value received, not for your infrastructure bill. An endpoint that saves someone a day of manual work is worth more than a cheap query, regardless of what each costs you to serve.
No enterprise path. Large customers need invoicing, contracts, SLAs, and a procurement process. An API that can only be bought with a card caps your deal size.
Punishing growth. A pricing curve where a customer's bill grows faster than the value they get produces a customer actively looking for an alternative. Volume discounts are not generosity; they are retention.
Where to start
Instrument before you price. Most teams cannot answer basic questions — which endpoints get used, by whom, in what volume, and which customers would be affected by a given tier boundary. A month of usage data turns pricing from a guess into arithmetic.
Then talk to the five customers who use it most. Ask what they would pay, what they use it for, and what it replaced. The answers reframe pricing more usefully than any competitive analysis, and occasionally reveal that your API is doing something you did not know it was doing.
And grandfather your existing free users generously when you launch. They are your proof it works, your reference customers, and the people most likely to tell everyone if the transition is handled badly. The revenue they represent is small; the goodwill is not.
Turning an internal API into something sellable is the sort of work we do at CODT.
