API strategy
Platform integration
Public API pricing models compared: tiered, usage-based, credit-based, and hybrid. Which one fits SaaS in the agent era, and where each one breaks.
Every commercial API team eventually lands in the same room. Finance wants predictable revenue. Product wants adoption. Engineering wants pricing that doesn't punish reliability work. And now there's a fourth voice at the table: the agent product manager, whose bot is about to make 40x more API calls than any human user ever did.
This comparison is for platform and product leaders at established B2B SaaS companies who need to price a public API — and who know agent traffic is already reshaping the maths. We'll walk through the four dominant public API pricing models, compare them on the dimensions that actually matter, and end with a recommendation.
One-line summary: tiered subscriptions win on predictability, pure usage-based wins on fairness, credit-based wins on flexibility across mixed workloads, and hybrid platform fees plus usage wins on enterprise revenue. The right pick depends on how your customers consume the API — and increasingly, on whether agents are the ones consuming it.
Tiered subscription pricing packages API access into fixed monthly plans. Free, Starter, Pro, Enterprise. Each tier includes a cap: request quota, rate limit, feature set, sometimes a seat count. Overage either blocks the caller or bills at a defined per-unit rate.
This is the model behind most SMB developer tools and productivity SaaS — think GitHub, Postman, or Mailchimp — where a per-seat or per-plan fee anchors the relationship. Buyers like it because the invoice is predictable. Finance likes it because ARR maps cleanly to seats or plans. Engineering likes it because capacity planning is a function of tier count, not per-user unpredictability.
The weakness is fit. A team making 100 calls a month and a team making 90,000 calls a month sit on the same Pro tier until one of them hits the ceiling. That's fine for human developers who consume in bursts. It breaks fast when agents enter the picture — a single agent workflow can burn a month of quota in an afternoon, and the customer feels punished for adopting AI.
Pure usage-based billing charges per unit of consumption. Per API call, per request, per successful response, per token, per compute-second. No monthly floor, no seat count — the meter runs when the API is used and stops when it isn't.
Stripe and Twilio built the modern template for this — Stripe with its per-transaction fee from day one, Twilio with pay-as-you-go pricing from its 2008 launch. AWS, OpenAI, and Anthropic have since made this the default mental model for AI infrastructure. It's fair in the sense that light users pay little and heavy users pay a lot. It aligns provider revenue with customer value: a customer only spends more when they're getting more work done.
The cost is unpredictability on both sides. Buyers get invoices they can't forecast, which triggers procurement friction at enterprise scale. Providers get revenue that swings with customer adoption cycles, which makes it harder to model ARR. Usage-based also demands metering infrastructure that actually works — accurate counters, idempotent billing events, dispute handling. If you can't produce a defensible usage record on demand, you can't invoice on it.
For a deeper look at how the meter itself needs to change when agents are the caller, our piece on API monetization strategy in the agent era covers what breaks and what to price instead.
Credit-based pricing sits between tiers and pure usage. Customers buy a pool of credits — monthly, annually, or top-up — and different API operations debit different credit amounts. A cheap read might cost 1 credit. A heavy compute-bound call might cost 50. A generation that consumes an expensive downstream model might cost 500.
Make.com meters in operations against a shared credit pool. Cloudinary uses a single credit unit that covers transformations, storage, and bandwidth against one pool. Most AI platforms with mixed workloads — cheap embeddings alongside expensive generations — end up here whether they call it credits or not.
The strength is flexibility. One meter covers many operation types, so you don't need a separate SKU for every endpoint. It gives customers a single number to budget against ('we bought 100,000 credits this month') while still charging more for expensive work. It's also the easiest model to expose to procurement: credits are a purchase order line item, not a variable invoice.
The weakness is transparency. Customers need to understand what each operation costs before they call it, or they get surprise burn-downs. That's a documentation problem for human developers and a real design problem for agents — an agent that doesn't know a tool call costs 500 credits will happily call it in a loop.
Pick tiered subscription when your API is a feature of a broader product, when your customers are mostly SMB, and when the calls-per-customer distribution is relatively flat. It's also the right pick when you have no metering infrastructure yet and need to ship pricing before you ship a billing system — a tier cap is easier to enforce than a per-call meter.
Avoid it if you know agent traffic is coming. Agents don't sit inside a Pro tier's assumed usage curve. They compress a month of human traffic into an hour, and the customer experience of hitting a wall mid-workflow will kill adoption of both your API and their agent.
Pick pure usage-based when your customer base is developer-heavy, when consumption varies by 100x or more across accounts, and when the value of each API call is tightly correlated with the customer's own revenue. AI infrastructure is the archetypal fit — the customer pays you when their agent works, so their willingness to pay scales with their outcomes.
Avoid it for enterprise-first go-to-market. Procurement teams need a number to sign off on. If the only number you can give them is 'it depends on how much you use it,' the deal will stall on legal and finance objections. Pure usage-based also demands operational discipline: rate limiting, spend caps, alerting, and dispute workflows all become customer-facing features, not internal ones.
If you're going this route, API rate limiting best practices for SaaS in the agent era is worth reading before you launch — the rate limit is now part of the pricing surface.
Pick credit-based when your API has genuinely mixed workloads — cheap reads and expensive writes, or a range of models with different compute profiles. Credits let you unify the meter without hiding the cost differences. They also work well when customers want to pre-purchase capacity, which many enterprise procurement processes prefer over open-ended usage.
Credits shine for agent workloads specifically, because you can price expensive tool calls higher and let the agent's planner factor cost into its decisions. But that only works if the credit cost of each operation is documented, machine-readable, and stable. If your credit table changes silently or lives only in a marketing page, the model breaks.
Avoid credit-based when your operations are homogeneous. If every call costs roughly the same to serve, credits add abstraction without adding fairness. Just charge per call.
Pick hybrid when you're selling into mid-market or enterprise and you need both revenue predictability and fair scaling. A platform fee covers a baseline of included usage, seats, and support. Overage bills either per unit or per credit. This is where most mature commercial APIs eventually land — Segment and Datadog both run variants of it, and Twilio has layered committed-use platform pricing on top of its usage core over time.
The hybrid model is also the most defensible against agent traffic. The platform fee gives you an ARR floor that doesn't collapse when a customer's agent goes quiet for a month. The usage component means you capture upside when the agent gets busy. Neither side of the meter carries the entire commercial relationship.
The cost is complexity. Every hybrid model needs a clean answer to five questions: what does the platform fee include, how is overage priced, what happens at renewal if usage grew or shrank, how do commitments and overage interact, and how do you communicate all of this without a spreadsheet. Get any of them wrong and you'll spend more time on billing disputes than on product.
Pricing an API for agent-era SaaS runs into a deeper problem than model choice: most established SaaS products don't have the API surface their agents need in the first place. Your APIs expose a fraction of what your product can do, so even a perfectly priced meter is running on the wrong endpoints. Buyers won't renew usage-based contracts for capabilities that don't exist yet, and platform fees won't hold if the agent can't do the work the deal was signed on.
Pontil sits in the tools layer of the agent stack. We generate the tools agents need from the code and APIs you already have, run them as the authenticated user, and keep them current as your product changes. That means the surface you're pricing is the surface agents can actually reach. If you're sizing the gap between your current API and what your agents need, our resource on why agent projects stall is a good place to start, or book a demo to see the runtime.
For an established B2B SaaS company building a public API in 2026, with agent traffic already in the roadmap: hybrid platform fee plus credit-based overage.
The reasoning: the platform fee anchors procurement and gives finance a predictable ARR line. Credits let you price expensive operations honestly, which becomes essential when agents — not humans — are choosing which endpoints to call in a loop. Together they hold up across human developer workloads, agent workloads, and enterprise procurement cycles.
Pure usage-based is a better fit for infrastructure companies whose customers are themselves developers with high consumption variance. Tiered subscription still works for SMB-heavy products where the API is a feature, not the product. Credit-only works when you can't yet commit to platform fees but need mixed-workload flexibility. Everyone else — most established SaaS companies reading this — should be planning the hybrid path.
The pricing model matters. The API surface matters more. Fix both, in that order.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
