UCP, ACP, and why I think we’re about to see the “API moment” of commerce

In 2010, most software companies treated APIs as afterthoughts. You built your product for humans, then maybe you added an API so enterprise customers could extract their data or build custom integrations.

Then Stripe launched with a fundamentally different idea: the API was the product. Not a feature, not an add-on. The API was how you accessed payments infrastructure that you could build anything on top of.

Stripe changed the mental model of what infrastructure could be.

The magic wasn’t that Stripe had good documentation or clean endpoints, though they did. The magic was that they built infrastructure that could support use cases they hadn’t imagined yet. When someone wanted to build subscription billing, or marketplace payments, or recurring invoices, Stripe’s infrastructure could handle it without Stripe rebuilding anything.

We’re at that moment again. This time with commerce protocols.

UCP and ACP provide infrastructure that will support commerce applications and agent behaviors we haven’t thought of yet. That’s why this matters more than it looks like on the surface.

What the API moment actually was and why it wasn’t about integrations

Let me rewind to why the 2010-2015 API shift was so significant, because I think we’re misremembering what actually happened.

Before Stripe, Twilio, and AWS popularized the API-first model, most people thought of APIs as plumbing. You built software with a UI, and if customers needed to connect it to other systems, you exposed some endpoints. The API existed to serve the product.

The insight that launched a thousand startups was inverting this: what if infrastructure itself was the product, exposed entirely through APIs, with no assumption about what people would build on top?

Stripe didn’t build payment forms and add an API. They built payment infrastructure and let you build whatever interface you wanted. The API was complete, well-documented, and powerful enough that you could build entire businesses on top of it without ever talking to a human at Stripe.

This created something unexpected: an explosion of use cases Stripe never planned for.

Someone built subscription billing on Stripe. Someone else built marketplace payments. Another team built split payments for platforms. Then crowdfunding. Then recurring donations. Then revenue-share models for content creators.

None of these were Stripe features. They were applications people built on infrastructure that was flexible enough to support them.

That’s the key insight: the infrastructure didn’t know what it would be used for. It just provided reliable primitives – charge a card, move money, store payment methods – and trusted builders to compose those primitives into applications.

This is what future-proofing actually means. Not predicting what people will need. Building infrastructure flexible enough that when needs emerge, the infrastructure can support them without fundamental changes.

Why commerce hasn’t had its API moment yet

Commerce has had integrations for decades. Shopify has an app store. BigCommerce has APIs. WooCommerce has plugins. So why hasn’t commerce had its infrastructure moment?

Because platforms built for control, not composability.

When you build on Shopify, you’re building inside Shopify’s world. Their data models, their workflows, their assumptions about how commerce works. If you want to do something Shopify didn’t plan for, you’re fighting the platform.

Most merchants never hit these limits. Shopify’s assumptions are good assumptions. But when you need custom fulfillment logic, or non-standard inventory tracking, or workflows that span multiple systems, you’re stuck.

The platform model requires platforms to predict what merchants need. Then they build features for those needs. Then they expose APIs so people can extend those features.

Infrastructure-first means building flexible primitives, not predetermined features.

A concrete example of the difference:

Platform thinking: “Merchants need inventory management, so we’ll build an inventory feature with SKUs, stock levels, and locations. Then we’ll add an API so people can sync inventory data.”

Infrastructure thinking: “Merchants need to track quantities of things across locations. We’ll provide primitives for quantities, locations, and state changes. Whatever you need to track – inventory, capacity, resources, time slots – you can build on these primitives.”

The first approach works until someone needs to track something Shopify didn’t plan for. The second approach works for use cases that don’t exist yet.

Commerce hasn’t had its infrastructure moment because platforms optimized for control and feature completeness, not for composability and unknown futures.

Why protocols change everything and why timing matters now

UCP and ACP are significant because they’re the first real attempt to build commerce infrastructure that doesn’t assume a platform hub.

Protocols define a common language for how systems talk about commerce primitives. Products, prices, inventory, orders, fulfillment. Not Shopify’s version or Amazon’s version – a shared version that works across systems.

When systems speak the same language, you can compose them. You can use Shopify for your storefront, a specialized inventory system for stock management, a 3PL for fulfillment, and a custom system for your unique workflow – and they all work together because they speak the same protocol.

No platform hub mediating everything. No custom integration for every connection. No translating between different data models. Just systems speaking a common language.

But timing matters: AI agents are forcing this to happen now.

When humans were the only shoppers, platforms could get away with proprietary APIs and custom data formats. Humans adapt. We learn each platform’s quirks, navigate different checkout flows, mentally translate between systems.

AI agents can’t do that – or won’t do that. They need standardized interfaces.

If an agent has to maintain custom logic for every commerce platform it interacts with, managing all that becomes unworkable. You’d need different code for Shopify versus BigCommerce versus WooCommerce versus custom stores. Different data formats, different availability checks, different order flows.

Protocols solve this: one interface, consistent behavior, predictable responses. Build an agent once, it works everywhere that supports the protocol.

This creates massive economic pressure toward standardization that didn’t exist when humans were shopping. Agents amplify the cost of non-standard systems.

The infrastructure layer commerce has been missing

The protocol-ready commerce stack looks like this – and notice what’s missing today:

Commerce presentation layer: This is Shopify, or your custom storefront, or whatever interface you show to customers (human or AI). This layer handles product display, cart logic, checkout flows.

Payment infrastructure: Stripe has this locked. They built the primitives (charge, refund, transfer, store), and people compose them into any payment flow imaginable.

Fulfillment infrastructure: 3PLs are becoming this, though they’re not quite there yet. The good ones are starting to expose real-time APIs, webhook events, and granular inventory visibility.

The gap: Inventory truth infrastructure.

No one built the inventory equivalent of Stripe. The infrastructure layer that just provides primitives -quantities, locations, movements, reservations – and lets you compose them into whatever workflow you need.

Riikka Söderlund

COO & CMO

Riikka Söderlund is Chief Revenue Officer at Katana, where she works closely with hundreds of product businesses as they move beyond spreadsheets and set up systems that can handle growth. Her writing comes from those conversations and the patterns she’s seen across teams, channels, and locations.