Consumption

API consumption is half the equation that most API programs forget to govern. We spend enormous energy on the producing side — design, deployment, management, documentation — and then we assume that once the API is out there, consumption takes care of itself. It doesn’t. Consumption has its own patterns, its own friction, its own dependencies, and its own governance concerns, and the organizations that treat consumption as a first-class discipline end up with dramatically better integrations, more resilient systems, and more honest relationships between the teams and companies that depend on each other through APIs. I’ve spent a lot of time on both sides of the API conversation, and the consuming side is where I think the most improvement is still available.

The place to start, always, is with the consumer experience — and specifically with what frustrates developers when they try to integrate with an API for the first time. I wrote about this back in 2010, cataloging what drives developers crazy: inconsistent error messages, missing or wrong documentation, APIs that throw exceptions instead of errors, confusing authentication, no sandbox environment, SDKs that are outdated or broken. The registration process is often the first failure — the hoops a consumer has to jump through to get an API key are sometimes so elaborate and so poorly designed that developers give up before they make their first call. I argued in 2011 that the quality of an API’s value and reliability ultimately matters more than the quality of its docs and code samples, because a developer can work around gaps in documentation but can’t work around an API that doesn’t do what it says. The baseline is: can a consumer actually succeed? If they can’t, everything else is theater.

Onboarding is the moment that determines whether a consumer succeeds or abandons, and it’s worth treating as a distinct discipline. In 2019 I was writing about onboarding best practices — the full arc from understanding the API, building initial use cases, sharing and collaborating with others, and continuously improving the integration. The collection-based model, where you hand a developer a pre-built Postman, Bruno, or Insomnia collection they can run immediately, was a genuine breakthrough for consumer onboarding friction. The key was meeting developers in the tools they already use — the HTTP client — rather than requiring them to read through documentation before making a single call. The developer onboarding use case for Postman was specifically about collapsing the time from “heard about this API” to “made a real call that worked.” That gap is where you lose most people, and the collection is the best mechanism the industry found for closing it. Simple versus complex collection tiers — beginner-friendly entry points alongside advanced, power-user variants — let you serve different consumer skill levels without forcing everyone through the same door.

The tension between providers and consumers is older than any of the tools, and it was one of the more uncomfortable things I wrote about in 2012. Providers want consumers to follow their rules, integrate cleanly, respect rate limits, build applications that reflect well on the platform. Consumers want APIs to do more, to be more reliable, to be better documented, to be cheaper, to not change without notice. Both are legitimate, and both sets of interests get violated all the time. The honest framing is that API design is a conversation about where effort lives — in the provider’s implementation or in the consumer’s integration. I made this explicit in 2018: every design decision about an API either does work on the producer side or transfers that work onto the consumer. A well-designed API absorbs complexity on the producer side; a poorly designed API exports its technical debt to every consumer who integrates with it. That calculation should inform every design decision, because what feels like “simplifying the API” often just means making consumption harder.

Consumption at scale has its own problems, and this is where governance becomes unavoidable. When I wrote in 2015 about managing my own API usage across 35 external APIs, I was confronting what every team operating at any scale has to confront: you are not just consuming one API, you are managing a portfolio of dependencies, each with its own rate limits, its own authentication patterns, its own change cadences, its own deprecation policies. That portfolio of dependencies is risk. An API you depend on can change its pricing, throttle you, go down, deprecate a feature you rely on, or shut down entirely — and if you haven’t tracked and documented your dependencies, you discover these things the hard way. I argued in 2017 that API dependencies belong inside your API definition — that an OpenAPI file describing your API should also declare what it consumes, because your API’s behavior is a function of the APIs you’ve integrated, and that chain of dependencies is governance-relevant information. The build-versus-depend decision is one of the most consequential choices a team makes, and I wrote about it in 2017 as a real tradeoff: depending on a third-party API gains you capability quickly and cheaply, but it also hands someone else control over a piece of your system. Understanding that tradeoff, tracking the dependency, and having a plan for when the dependency changes — these are consumer governance responsibilities.

Rate limits are the most visible constraint the producing side places on consumption, and navigating them well is a learned skill. In 2019 I wrote about the reality of navigating rate limit differences across platforms — the bewildering variety of how platforms express their limits (requests per minute, per hour, per day, per endpoint, per user, per application), how they communicate limit state (headers, error bodies, documentation), and how a consumer is supposed to handle them gracefully. My argument in 2025 was about matching limits to consumer type: different consumers have different needs and different risk profiles, and a blanket rate limit policy that treats an individual developer the same as an enterprise integration is both a disservice and a missed governance opportunity. Know your consumers, and apply appropriate limits — limits calibrated to what they’re actually trying to do rather than a one-size-fits-all ceiling. That same 2025 piece on knowing your consumers was the one that most clearly articulated the case for consuming-side identity governance: you can’t govern consumption you can’t identify, and you can’t identify consumers you haven’t characterized.

Consumer-side tooling governance is where consumption and the API lifecycle start to converge. In 2025 I was writing about the choice between investing in SDKs versus just shipping an OpenAPI spec and documentation, and the honest answer is that it depends on who your consumers are and what they need. An OpenAPI specification is the foundation — the contract that SDK generators and client tools can derive from. SDKs reduce consumer friction for committed integrators building production code in specific languages. The intersection of static documentation, interactive documentation, explorers, and API clients is the realm consumers actually live in, and governing what you offer at each of those layers is a producing-side decision with direct consequences for consumption experience. The governance question is: are you meeting your consumers where they are, with the artifacts they need, in the formats the tools they use already speak?

The most interesting governance development in recent consumption patterns is what I wrote about in 2026 as baseline rules for API consumption governance. The premise is that consumption, like production, needs explicit governance — rules about how APIs should be consumed within an organization, not just how they should be built. That means defining how teams are expected to handle authentication credentials, how they declare and track their dependencies, how they respond to deprecation notices, how they handle rate limit errors, how they test their integrations continuously, and how they ensure the APIs they depend on are still meeting their expectations. This is consumption as a first-class operational practice, with the same lifecycle discipline on the consuming side that we’ve demanded on the producing side for years. Application definition matters here too — in 2020 I was tracking how providers are rethinking what constitutes “an application” when consumers onboard, because the application boundary is where consumer governance begins: who is consuming, as what entity, at what scale, for what purpose.

The shift I’d most want to see in how teams approach consumption is the same shift I’ve been pushing on the producing side for a long time: treat it as an ongoing practice, not a one-time integration event. Consuming an API means accepting a dependency, and that dependency needs to be tracked, monitored, tested continuously, and factored into deprecation and change planning. The API producer has responsibilities — clear deprecation timelines, versioning discipline, communication about changes — and so does the consumer. Consumer governance is the discipline of fulfilling those responsibilities: knowing what you depend on, staying current with what changes, building resilient integrations that degrade gracefully rather than failing catastrophically, and governing the portfolio of dependencies your organization has accumulated across every team and every service. The organizations that are best at consumption governance are the ones that have the most reliable integrations, the fewest surprise outages from upstream API changes, and the clearest picture of their external dependencies. That’s not accidental. It’s the result of treating consumption with the same intentionality and discipline that the best producers bring to building and publishing their APIs.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Consumption

References

Guidance Details

Explore more

Discover APIs