I’ve kept thinking about this catchy-sassy thing I wrote, with reason:
API documentation needs its TikTok layer.
What happens when an API product is placed into a situation where someone can understand what it could do for them?
The example I used was this: marketing says “resilient supply chains,” while the API reference says GET /shipments/{id}/events. Somewhere between those two is the actual capability: “Detect a transportation exception in real time and trigger an intervention.”
I was pointing to that middle as a discovery problem. But the commerce analogy behind it is broader.
Last year at DMEXCO, I was talking with marketers about large language model training, why it matters for their brand and products to be there, and the role technical documentation can play. Of course, I also wandered through the media expo, including the Netflix and Disney stands.
Beyond the private reception area and bar were several shipping containers with rooms where people were discussing product placements in upcoming productions. The scale of it was staggering. It was a physical reminder of how much money and professional attention goes into where a product appears, in whose hands, in what setting, and what that setting allows someone to understand about it.
The same principle has taken other forms in social commerce. In China, some of the most sophisticated e-commerce infrastructure in the world sits alongside an enormous industry devoted to demonstrating products, talking about them, answering questions, and building customer trust.
Making the transaction efficient did not remove the conversion work around the purchase decision, it just now mostly happens elsewhere. The same is by now true in B2B, where buyers move between human and digital channels to research and evaluate suppliers. McKinsey reports inconsistent information across teams and inability to access knowledgeable representatives among the leading reasons buyers switch suppliers. (ref: McKinsey’s 2026 Global B2B Pulse report, published May 28, 2026)
And before you say, “yes, but that is B2C merchandise,” professional buyers in China are already finding factories, touring them by video and negotiating prices online. (ref: 58th China (Guangzhou) International Beauty Expo and Alibaba 1688)
My point is the distinction between discovery, conversion, and transaction. Keep that in mind while you work on making your APIs easier for machines to discover and consume.
API discovery starts before someone searches for an API
Finding an available capability is relatively late in the story. To search for a shipment-tracking API, you have already understood and phrased enough of your problem to look for shipment tracking in the first place.
The problem is first felt differently: failed deliveries are expensive, customers are frustrated, and too much time is spent dealing with exceptions. Real-time shipment events become relevant when you can connect them to that situation, perhaps an exception can be detected early enough to contact the customer or reroute a delivery.
How LLMs change API product discovery
For many mid-market companies, the practical tool for exploring third-party services like these is an LLM. For now, they’re not sending some fabled, well-informed agent they don’t even have, let alone one harnessed to all the right systems.
Someone describes the problem, adds the context about their systems and constraints, looks at possible solutions, and then follows the questions that come up.
The LLM won’t read the provider’s entire documentation estate, too many tokens. But it needs enough first-party information and search context to work out whether to recommend the service, or recognize when it probably isn’t a good fit.
The relevant context is scattered across API documentation, product and pricing pages, and implementation guidance, while some of what matters may never have been written down at all. It sits in the experience of people who work with customers. MCP can provide access to that knowledge, but it can’t provide what hasn’t been made accessible in the first place.
Does Claude recommend my API?
Or ChatGPT, Gemini, or another LLM someone might use to explore a business problem. Before deciding what an agent-facing merchandising layer should look like, there is a more immediate question for API providers: what already happens when someone asks these models about the problems their APIs are meant to solve?
Does it find you? Does it connect the problem to the right capabilities? Does it understand where they fit? And can you tell where that understanding came from?
Those questions give us something concrete to investigate before deciding what needs to be built. They are also what we’ve started looking at in Pronovix’s Competitive API Capability Benchmark: how selected API capabilities appear in AI-generated answers, whether they connect back to the business solutions a company says it offers, and how that picture compares with relevant competitors.
If you want to see how we approach that, there’s a short introduction to our Competitive API Capability Benchmark here.
It also leads to the next question I will to explore separately: once several providers make it into an answer, what determines how the model understands the differences between them?
Registries and MCP are about standardized access. I suspect your sales and marketing teams will still want you to keep differentiation and conversion in mind.
