Thanks to pioneers like Twilio and Stripe, API products have redefined what a great developer experience (DX) looks like. These companies have demonstrated how targeted API products, along with exceptional documentation and onboarding, can make developers enthusiastic advocates for their brands. However, the API product market is shifting — the rise of AI agents means APIs must now serve both human developers and AI consumers. This shift requires a fundamental rethink of how companies build API products.

At Platform Summit 2025 in Stockholm, Sweden, four industry experts — Fredrik Appelros, Tyler Ayers, Derric Gilling, and Ketty Zakariasy — shared their insights on building API products for today’s consumers. This article highlights key takeaways from their discussion.

API Product vs. API as a Product

It’s important to know the difference between a product that uses APIs and an API-as-a-product as the panelists touched on both throughout the discussion. For our purposes, an API product is built around business capabilities and is designed to solve a specific problem.

“The main difference in an API product is that you build on top of the business, so everything is driven by the business team,” explains Ketty Zakariasy, Principal Consultant and Co-Founder, So-API Consulting. “The IT team may provide the technical solution, but the business ideas don’t come from them, they come from others who explain them — and that is the productization of the API team.”

On the other hand, API-as-a-product is where the API is a standalone product that you’re selling, and it serves as the core value of your business. Twilio and Stripe are well-known examples of companies with an API-first business model.

Although most end users achieve value through SaaS and UI-based applications, the API is a primary conduit for delivering this value. As such, both sides need forethought, explains Derric Gilling, VP and GM of API Platform BU, WSO2. “When you think about productizing that interface — which starts with creating the definitions and the contract — you need to think about what that experience looks like from a developer standpoint versus from a typical user standpoint,” Gilling comments.

Rethinking Key Aspects of Building API Products

44% of enterprises assessed or deployed AI agents in 2025, found NVIDIA’s annual State of AI report. As more organizations deploy these autonomous AI applications, API product companies will need to cater to AI consumers and human developers. Our panelists offer key advice about building API products, especially now in the age of AI.

Consider Different API Consumers

Providers need to consider the requirements for as many different consumers of their APIs as possible. What if the consumer is an AI agent? Real-world tasks are complex, and the agent will likely have to consume multiple APIs in a specific order. That agent will need to understand how each API works and its context. An MCP server would likely be used to orchestrate those APIs for AI consumers.

Human developers, on the other hand, may opt for different integration options. Gilling explains that a developer integrating products like Twilio or Sinch should code that integration rather than go through an MCP server since they would generally be setting up a high-volume production use case. However, an individual end user using a single tool like Tableau may want to call different API functions through an MCP server.

If you’re a provider, you need to anticipate how your APIs will be used and how different use cases will impact API consumption. By planning ahead, you can better prepare for usage spikes from AI and effectively manage the costs associated with API usage.

Break Up the Monolithic API

Too many companies think of an API product as a large, monolithic service. They want to do everything in one single API. However, that is not the most effective way to build an API product.

“It’s okay to duplicate APIs and to deliver value for each one specifically,” Zakariasy says. It’s better to build smaller, targeted APIs, each for a specific business use case. A smaller API reduces the cognitive load for the developer as it’s easier to understand, faster to integrate, and more likely to have clear documentation.

“If you put a lot of code inside your API, then at the end of the day it will do too much, and no one will understand exactly what that API is for,” Zakariasy comments. This integration friction often leads to developers searching for a simpler service that gets them to “Hello World” faster.

Providers that develop smaller and more targeted APIs will see end results that include acquiring and retaining developers, lowering the barrier to entry for customers, and a better product-market fit for each API.

Support Multiple API Styles and Protocols

No single architectural style or protocol fits every use case. Some developers may want the simplicity of a REST API, while others need the asynchronous communication of webhooks. You may have customers who need your API to drive MCP server tools for an AI agent.

Also, consider enterprise integration and AI. Do your APIs support the protocols needed to bridge between the AI and the legacy layer? The more architectural styles and protocols you can provide, the more AI use cases your APIs can support and the wider the market for your API products.

Tyler Ayers, Global Principal Architect at Google, explains that most LLMs are multimodal, meaning they can process text, images, audio, and video. Similarly, he prefers API products to be multi-protocol.

“We do this at Google a lot — everything is gRPC internally. Externally, everything is REST and maybe some gRPC if we know there are system-to-system use cases there,” Ayers says. “I think for MCP and A2A I’d like to see that similarly — it’s one product, but multi-protocol. And so your developer or customer can choose their preferred way of interacting with that product.”

Offering different styles and protocols removes the technical barriers that prevent different types of consumers from adopting your API products. This expansion of options makes each product compatible with more market segments.

Treat Internal APIs as Products

The entire panel agrees on the idea that internal APIs should be treated as products. Gilling explains that if you don’t treat internal APIs as products, you end up with employees trying to figure out how to integrate with these APIs. They end up working things out through Slack messages or support tickets, and then information gets lost, making the onboarding experience quite horrible.

“That’s where the concept of an internal developer platform comes in — a central spot where a developer can discover APIs, find the documentation, learn how to authenticate, and then get up and running,” Gilling says. “Having that one spot can be really helpful, especially for new employees who are onboarding and need to find everything.”

Fredrik Appelros, Senior Product Manager at Sinch, agrees with Gilling, adding that “even if it’s an internal API, it still has its users, and they deserve the same kind of care about the experience.” It’s valuable to have an internal developer portal and documentation for new and existing employees.

“You can have employees who have been there for ten years, and they still might not know all the inner workings of everything,” Appelros comments. “It’s important to care about that audience as well.”

Treating internal APIs as products means that they become more than just sets of endpoints but complete packages with their own self-service developer portal. Having easy access to everything from one place helps boost productivity because new users don’t have to spend time hunting down the information they need to get started with each API.

Monetize the API Experience

Experts concur that when you monetize an API, you’re monetizing the experiences that it enables and the value it delivers. Appelros explains using the analog example of wanting to go to a museum.

“I’m not monetizing the door into the museum — I’m monetizing the experience of going into the museum,” Appelros explains. “So going back to APIs as being products in their own right, you’re monetizing the services behind them and those experiences.”

Similarly, Gilling emphasizes that you’re monetizing the value being delivered through the API. “You could monetize your data and content, but if you have poor data, you can’t necessarily sell that,” he comments. “So you need to think about what to charge on: Is it high-quality data versus low-quality data? That’s a really important piece.”

Zakariasy adds that you also need the marketing team to work with the IT team to package that experience and sell it as a product.

By monetizing the API experience, you can optimize revenue based on outcomes and value as opposed to the volume of calls. You can also set quality premiums where pricing is based on the caliber of the data the API provides.

Evolve API Monetization for AI

The dawn of AI applications means providers need to rethink API monetization models. Traditional API pricing models won’t always work for AI consumers. For example, per-call pricing becomes impractical with millions of requests from AI agents, and most subscription models don’t cover their unpredictable usage patterns.

Customers now expect API pricing options that align with only what they need, like outcome-based or dynamic pricing. Providers need to meet these pricing requirements and have a platform in place for that monetization. They should also consider changing their approaches to API rate limiting to accommodate AI consumers.

“You can only monetize something if you have the operations absolutely worked out,” says Ayers. This requires methods to scale requests, handle pricing, establish and monitor SLAs, and more. “Having that platform, that operationalization all worked out in advance, is key as well,” Ayers explains.

Ayers also thinks that at some point there will be consensus in the industry around agent-based payments. Currently, there are competing protocols that aim to enable payment exchanges through agents. Google released the Agent Payments Protocol (AP2). Stripe and OpenAI have partnered on the Agentic Commerce Protocol (ACP). Monetizing APIs could eventually involve accepting payments from AI agents using one or a combination of these protocols.
Adopting flexible API pricing models allows you to align costs with the specific value delivered, meeting consumers where they are, regardless of their level of usage.

Never Forget About Developer Experience

We’ve been discussing the API developer experience at Nordic APIs for quite a while now. Ensuring a good experience — from initial onboarding and integration to testing calls and integration maintenance — is critical to the success of your API.

“I love developer portals. Putting documentation there that is as simple and straightforward as possible while also making the portal fancy, fun, and interesting is essential for a good experience,” says Ayers. “You also need to put time into making it easy to share stuff, building a community, and having active social channels.” These components make up the basics for product development and marketing, he adds.

Gilling says that for him, one of the biggest things regarding developer experience is solution-oriented thinking, especially when you look at things like documentation and tutorials.

“I can’t tell you how many times I’ve seen a doc website just list out features or specifications, but developers are coming to use a new API for a particular problem that they’re running into,” explains Gilling. “Creating those solution guides and thinking about how your onboarding experience fits into different use cases developers might run into can go a long way to really trying to solve their problems.”

Developers are often involved in the decision process regarding choosing new SaaS or API products. Therefore, the experience with your API can make or break potential sales and impact user growth and retention.

Same Foundation, New Rules

APIs have always been essential to building software products — but the rules are changing. APIs must now meet the needs of both human developers and AI consumers, and that requires a fundamental rethink of how API products are built, documented, and iterated. If you design and build APIs, the principles highlighted in this article are a practical starting point. We’re living in an AI-driven world, and the APIs you build today will form the foundation for the software products you deliver tomorrow.