Clients

The API client is the consumer’s primary tool — the thing a developer actually opens to explore, test, and put an API to work. If the API is the contract and the documentation is the explanation, the client is where the rubber meets the road: the application where you make a real request, see a real response, and decide whether this API is going to work for you. I’ve spent a lot of years arguing that the client deserves far more attention than it usually gets, because the client is where API consumption actually happens. Producers obsess over their API and their docs; consumers live in their client. Understanding the realm of API clients means understanding the entire consumer side of the API economy.

At its simplest, an API client is any tool that lets you make a request to an API and work with the response. That spans an enormous range: curl on the command line, HTTPie, the browser itself, API explorers like the old Google and Facebook Graph explorers, Swagger UI and modern OpenAPI-powered explorers, full GUI clients like Postman, Insomnia, Paw, and RESTFiddle, the newer Git-native clients like Bruno and Scalar, and the generated SDK libraries you import into your own code. Even Excel and Google Sheets have served as API clients. What unites all of them is that they sit on the consuming side and turn an abstract API into something a human or a machine can actually invoke. The client is the consumer’s window into the API.

I’ve long pushed API providers to think beyond just shipping language-specific SDKs and to also speak the formats the popular HTTP clients use. Back in 2015 I argued that providers should publish Postman, Paw, and Insomnia collections alongside their SDKs, because the HTTP client is where so many developers begin. An SDK is for when you’ve committed to building production code in a specific language. A client and its collection are for the earlier, more important moment — when a developer is still figuring out whether your API does what they need. Meeting them in the client they already use removes friction at exactly the point where you’re most likely to lose them.

The single most important concept in the realm of clients is the collection. A collection — a Postman collection, a Bruno collection, an Insomnia export, the emerging OpenCollection — is a portable, executable artifact that captures a set of real API requests, complete with the environmental context needed to run them. I’ve described the collection as a quantifiable, shareable, executable unit of representation for a digital capability, and I mean each of those words. Quantifiable: you can count and measure it. Shareable: you can hand it to someone and they can run it. Executable: it doesn’t just describe the API, it runs against it. This is what distinguishes a collection from an OpenAPI definition. I’ve framed OpenAPI as the static truth of what an API can do, and collections as the real-world derivatives of that truth — reflecting how developers actually apply the API, with environments, examples, auth, and sequencing baked in. The OpenAPI is the contract; the collection is the contract in motion. For a lot of enterprise governance at the developer level, the collection is actually the more meaningful artifact, because it shows what people are really doing, not just what’s theoretically possible.

The collection is also why the client became an onboarding tool, not just a testing tool. The “Run in Postman” button was a genuinely clever innovation — an embeddable button that let a developer go from reading about your API to executing a real call against it in minutes, with the collection carrying everything they needed. That collapsed onboarding friction dramatically. I’ve described the developer onboarding use case as a progression: understand the API, build use cases, share and publish, then collaborate and improve — and the collection is the hands-on vehicle that moves a developer through all of it far more effectively than static documentation ever could. The client is where a developer’s first successful API call happens, and that first successful call is the whole game in API adoption.

Postman dominated this realm for a decade, and I watched it grow from a simple HTTP client into something much larger. I argued in 2021 that Postman would do for APIs what GitHub did for open source — become the platform where the work happens, the collaboration layer, the network where APIs are discovered and shared. Postman expanded to service dozens of stops along the API lifecycle: definitions, versioning, environments, testing, mocking, documentation, monitoring, governance, collaboration through workspaces, and discovery through the public API network. The client became a platform, and for a while it looked like the entire API lifecycle might consolidate inside it.

Then came what I’ve called the great unbundling of the API client. As Postman grew into a heavy, cloud-centric, increasingly commercial platform, a wave of specialized alternatives emerged that pulled functions back out — Bruno, Scalar, and others, often open source, often local-first. Bruno in particular caught my attention because it gets back to the roots of why we all fell in love with Postman in the first place, while reflecting what developers actually need now: developer-first, a local application, and Git-ops powered. The defining shift is that Git is how you run in Bruno — collections live in Git repositories rather than cloud workspaces, “Run in Bruno” replaces “Run in Postman,” and the whole model moves from cloud-centric to local-first and version-controlled. This unbundling is a healthy correction. The monolithic platform offered convenience at the cost of lock-in and bloat; the unbundled, Git-native, open-source clients offer focus and control. I’m careful, though, not to celebrate unbundling for its own sake — bundling and unbundling are often vendor and market framings that obscure what consumers actually need. The real question is always what the developer in front of the client requires, not which way the market happens to be cycling.

The collection format itself is now an arena of its own, which tells you how central the client has become. The emergence of OpenCollection as a specification extending the Bruno collection is the realm maturing — a flat, simple, Git-friendly Bruno collection on one end, and a more enterprise-oriented, modular, extensible OpenCollection on the other, adding broader protocol support across HTTP, GraphQL, gRPC, and WebSocket, richer auth, environment inheritance, and structured assertions. Bruno prioritizes developer experience and a lean schema; OpenCollection aims at comprehensive enterprise coverage. That we’re now standardizing the collection the way we standardized the API definition shows that the executable consumer-side artifact has become as important as the contract itself.

The client realm also has to account for protocol diversity and for the changing nature of the consumer. A client is no longer just a REST tool — what you expect from a client spans SOAP, REST, hypermedia, GraphQL, gRPC, WebSocket, webhooks, and event-driven patterns, and the best clients are becoming multi-protocol. And the consumer behind the client is changing too. For years the next generation of clients looked like bots, voice, and conversational interfaces — Alexa, Slack bots, Google Home. Now it’s AI agents. This is where knowing your API consumers matters: there are human consumers operating GUI and CLI clients, and there are machine consumers — bots, scripts, and increasingly autonomous agents — that consume APIs programmatically and need different authentication, authorization, and observability. An agent is just the newest kind of API client. The realm of clients has always been about the tools consumers use to call APIs; it’s just that “consumer” now includes machines reasoning their way through your capabilities, not only developers clicking through requests.

The throughline across fifteen years is that the client is the center of gravity for everything on the consuming side of an API. It’s where exploration, testing, onboarding, and real consumption happen. The collection is its unit of value — portable, executable, the contract in motion. The landscape has cycled from explorers, to the rise and dominance of Postman, to the great unbundling toward Bruno and Scalar and Git-native, local-first, open-source tooling, to the standardization of the collection itself through OpenCollection, and now to agents arriving as a wholly new class of client. Producers who only think about their API and their docs are missing half the picture. The other half — the half where adoption is actually won or lost — lives in the client.

References

• Thinking Beyond Just Language-Specific Clients And Also Speaking The Formats Popular HTTP Clients Are Using
• An Embeddable Run In Postman Button For Your API
• Bots, Voice, And Conversational APIs Are Your Next Generation Of API Clients
• API Life Cycle Basics: Clients
• OpenAPI Is The Static Truth And Postman Collections Are Real-World Derivatives Of That Truth
• Postman Will Do For APIs What GitHub Did For Open Source
• Elevating The Bruno API Client As A Cornerstone Of API Operations
• Git Is How You Run In Bruno
• The Intersection Of Static Docs, Interactive Docs, Explorer, And API Clients
• The Great Unbundling Of The API Client
• Know Your API Consumers
• What Is The Diff Between Bruno Collection And OpenCollection