Plans

Plans are the business packaging of API access — the bundles of limits, features, and pricing that providers offer consumers — and they’re a richer and more important concept than the simple “pricing tiers” they’re often reduced to. A plan defines what a particular class of consumer gets: how many calls, which endpoints, what rate limits, what level of support, at what price. Plans are where the technical realities of an API (rate limiting, access control) meet the business realities (pricing, segmentation, monetization), which makes them one of the most consequential and most underexamined parts of API operations. I made a deliberate decision years ago to study “API plans” rather than just “API pricing,” because the plan is the whole package, not just the dollar figure, and understanding plans as the unit of business packaging reveals a lot about how API businesses actually work.

The decision to call it plans rather than pricing was foundational, and I explained it in 2015. I labeled my research “API plans” instead of “API pricing” because pricing is just one dimension of what a plan encompasses. A plan includes the rate limits, the included features, the access scope, the support level, the terms, and the price — and reducing it to “pricing” misses most of what makes plans interesting and important. The plan is the business container that bundles all the operational and commercial dimensions of API access into a coherent offer. When I have a bunch of API resources and need to figure out how to package them, as I wrote in 2015, I’m not just setting a price — I’m designing plans that bundle resources, limits, and features into offers that match different kinds of consumers. The plan is the design problem; the price is one variable within it.

The relationship between plans, rate limits, and pricing is the conceptual core, and it’s a genuine intersection rather than three separate things. I wrote in 2025 about the opportunity at the intersection of API rate limits and plans, and about how rate limits, plans, pricing, and marketplaces all work together. The rate limit is the technical mechanism; the plan is the business package that the rate limit is part of; the price is what the consumer pays for that package; and the marketplace is where plans get distributed. These four things are inseparable in practice — a rate limit without a plan is just a technical constraint, and a plan without appropriate rate limits is a business offer with no teeth. The art of API plans is designing this whole system coherently, so that the technical limits, the business packaging, the pricing, and the distribution all align to serve both the provider’s business and the consumer’s needs.

The plan-versus-usage debate is one of the most interesting business questions in this space, and I’ve never fully resolved it. I wrote in 2017 asking why AWS charges by usage while other APIs still use plans — because there’s a genuine tension between tiered plans (predictable buckets of access) and pure usage-based pricing (pay for exactly what you consume). I argued in 2017 that pricing tiers work for SaaS but not really for APIs, because API consumption is often better matched by usage-based or resource-based pricing than by rigid tiers. AWS proved that usage-based pricing can work at massive scale, yet most API providers stuck with plans. The reason plans persist despite usage-based pricing’s advantages is partly inertia, partly the predictability that plans offer consumers, and partly the simplicity of packaging. The plan-versus-usage question reflects a deeper tension between giving consumers predictable, comprehensible packages and charging them precisely for what they use.

The standardization and machine-readability of plans is where I did some of my most distinctive work, because the lack of it is a real problem. I built tooling and a machine-readable specification for gathering and organizing API plans and pricing, because I’d discovered that comparing even similar API plans across providers was genuinely hard — every provider expressed their plans differently, making it nearly impossible to compare or to build tooling around. I created base YAML templates for starter API plans, and analyzed the plans and pricing across hundreds of API platforms. The dream was machine-readable plans — plans expressed in a standard, structured format that could be compared, published, and consumed programmatically. By 2026 I was publishing machine-readable plans, rate limits, and FinOps data for thousands of API providers, realizing a version of that vision. Machine-readable plans matter because they make the business layer of APIs as legible and automatable as the technical layer, which is essential for discovery, comparison, and the FinOps discipline of managing API costs.

The honest framing is that plans are where the business and technical sides of API operations have to be designed together, and most providers do it haphazardly. I documented the numerous challenges of comparing even similar API plans, the need for release valves and overage mechanisms for rigid plans, the difficulty of communicating plan changes, and the broader question of how to express plans in machine-readable ways. The recurring theme is that plans are often an afterthought — slapped together late in the process, inconsistently structured, poorly communicated — when they should be a deliberate design exercise that aligns the technical access controls with the business model and the consumer’s actual needs. A well-designed set of plans segments consumers appropriately, matches access to value, makes the rate limits and pricing coherent, and communicates clearly what each consumer gets. A poorly-designed set of plans confuses consumers, mismatches access to need, and leaves money and goodwill on the table. The plan is the business interface to your API — the offer that consumers actually evaluate and choose among — and designing it well, with the technical and business dimensions integrated and ideally expressed in a machine-readable form, is one of the most underrated disciplines in building a successful API business. The plan is where your API stops being a technical artifact and becomes a commercial offer, and that transition deserves real design attention rather than the afterthought it usually gets.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Plans

References

Guidance Details

Explore more

Discover APIs