From REST to Agent-Native: Why Commerce Needs a New Protocol
Traditional REST APIs were designed to power human-driven user interfaces. A frontend developer calls an endpoint, receives JSON, and renders it into HTML that a person reads and clicks. This model has served e-commerce well for two decades. But agent commerce - where AI agents discover, evaluate, negotiate, and purchase on behalf of users - demands something fundamentally different.
This post explains why existing commerce APIs fall short for agent use cases, and how the Agent Commerce Protocol (ACP) addresses each gap.
The impedance mismatch
Consider what happens when you search for a product on a traditional e-commerce site. The API returns a list of results optimized for human browsing:
GET /api/products?q=running+shoes&page=1
{
"results": [
{
"id": "prod_001",
"name": "UltraBoost 23",
"price": "$129.99",
"image": "https://cdn.example.com/shoes/ub23.jpg",
"rating": "4.5 stars",
"reviews_count": "2,341 reviews",
"badge": "Best Seller"
}
]
}This response is designed for a UI. The price is a formatted string, not a number. The rating is presentational. The badge is marketing copy. An AI agent that receives this data has to parse strings, infer semantics, and guess at structure. That is fragile, error-prone, and slow.
Now consider the same query through ACP:
GET /v2/products?query=running+shoes&limit=10
{
"results": [
{
"id": "prod_001",
"name": "UltraBoost 23",
"price": { "amount": 12999, "currency": "USD" },
"attributes": {
"weight_grams": 289,
"drop_mm": 10,
"terrain": ["road", "light_trail"],
"arch_support": "neutral"
},
"comparison_highlights": [
"12% lighter than category average",
"Higher stack height than competing models"
],
"trust_score": 87,
"availability": {
"in_stock": true,
"quantity": 342,
"estimated_restock": null
},
"agent_hints": {
"best_for": ["daily_training", "tempo_runs"],
"not_ideal_for": ["trail_running", "sprinting"]
}
}
]
}Every field is typed, structured, and machine-readable. Prices are integers in the smallest currency unit (cents), eliminating float precision issues. Attributes use standardized keys so agents can compare products across storefronts without mapping proprietary schemas. Agent hints provide explicit guidance that helps the agent make recommendations without interpreting marketing copy.
Five ways REST falls short for agents
1. No semantic product understanding
REST APIs return product data in whatever schema the brand uses internally. One brand calls it weight, another calls it product_weight_oz, a third buries it in a free-text description. An agent querying 50 storefronts for lightweight running shoes would need 50 different parsing strategies.
ACP defines a standardized attribute taxonomy per product category. All running shoes use weight_grams, drop_mm, terrain, and arch_support. Agents can compare products across storefronts using structured queries without any natural language parsing.
The taxonomy is not rigid - storefronts can include additional custom attributes beyond the standard set. But the standard attributes give agents a guaranteed common vocabulary for comparison.
2. No negotiation primitive
REST APIs are request-response: you ask for data, you get data. There is no concept of a multi-turn conversation between an agent and a storefront.
Negotiation is inherently multi-turn. An agent proposes a price, the storefront counters, the agent considers and responds. This requires a protocol with session state, typed messages, and defined state transitions. REST has none of this built in.
ACP's negotiation protocol provides:
INITIATED -> OFFER_SENT -> COUNTERED -> ACCEPTED | REJECTED | EXPIREDYou could build negotiation on top of REST, but you would be reinventing most of what ACP already provides - state management, message typing, timeout handling, and event notification.
3. No trust signals
REST APIs do not have a standard way to communicate reliability, quality, or reputation. An agent calling a REST API has no way to know whether the storefront behind it is trustworthy before making a request.
ACP includes trust scores in every storefront response. Agents can filter, sort, and weight results by trust score before presenting recommendations to users. Trust scores are computed from real transaction data, not self-reported claims.
4. No transaction lifecycle
Most e-commerce REST APIs end at "add to cart." The actual purchase, fulfillment, and post-purchase lifecycle happens through separate systems (payment processors, shipping APIs, customer service platforms) with no unified protocol.
ACP provides a complete transaction lifecycle from creation through fulfillment, with optional escrow protection. An agent can create a transaction, fund escrow, track fulfillment, and handle disputes through a single protocol. This unified lifecycle is essential for agents that need to manage the complete purchase experience.
5. No real-time signals
REST APIs are pull-based. If an agent wants to know when a price changes, it has to poll. If it wants to know when an order ships, it has to poll. Polling at scale (thousands of agents checking thousands of storefronts) is wasteful and still introduces latency between the event and the agent learning about it.
ACP provides 30+ webhook events covering every state change in the discovery, negotiation, transaction, and trust domains. Agents subscribe to the events they care about and receive push notifications in real time. This eliminates polling, reduces latency, and scales efficiently.
Why not extend REST?
A reasonable question is: why create a new protocol instead of extending existing REST conventions?
We considered this approach seriously. The problem is that the gaps are not incremental - they are structural. REST is a general-purpose architectural style. It provides conventions for resource identification (URLs), standard methods (GET, POST, PUT, DELETE), and content negotiation (Accept headers). It does not provide conventions for stateful multi-turn interactions, trust computation, event-driven notifications, or typed domain-specific schemas.
You can build all of those things on top of REST. Many teams have. But when you do, you end up with a protocol-on-top-of-a-protocol, with no interoperability between implementations. ACP eliminates that fragmentation by standardizing the commerce-specific layer that REST intentionally leaves unspecified.
ACP is still HTTP-based. It uses JSON. It uses standard HTTP status codes. It is not a departure from web conventions - it is a domain-specific protocol that builds on them.
The adoption path
We designed ACP to be incrementally adoptable. You do not need to rewrite your commerce stack to support ACP.
Level 1: Read-only discovery. Expose your product catalog through ACP's discovery endpoints. This requires mapping your existing product data to ACP's attribute taxonomy and deploying an ACP-compatible API layer. Many brands accomplish this in a single sprint using our SDK and catalog import tools. Level 2: Negotiation. Add support for the negotiation protocol. This requires building a pricing engine that can evaluate and respond to agent offers. Brands with existing dynamic pricing infrastructure can typically integrate negotiation within 2-3 sprints. Level 3: Transactions. Enable the full transaction lifecycle with escrow support. This requires integration with ACP's payment facilitation layer and fulfillment tracking. The SDK handles most of the complexity - the main work is mapping your existing order management system to ACP's transaction state machine. Level 4: Full ecosystem. Support webhooks, trust score optimization, certification, and advanced features like real-time price streaming. This is the full ACP experience, and most brands reach this level within 2-3 months of starting integration.Each level is independently valuable. A brand at Level 1 is already discoverable by AI agents. Each subsequent level unlocks more capabilities and higher agent preference.
Measuring the difference
In our beta program, we tracked key metrics comparing agent interactions through traditional REST integrations versus ACP:
These numbers reflect the structural advantages of a purpose-built protocol. ACP is not just a convention on top of REST - it is an optimized system designed from the ground up for agent commerce.
The standard matters
Agent commerce is in its early days. The decisions we make now about protocols and standards will shape the ecosystem for years. A fragmented landscape of proprietary integrations will slow adoption and concentrate power among the platforms with the most integration resources. An open standard enables a competitive, interoperable ecosystem where any agent can work with any brand.
ACP is that standard. It is open, documented, and free to implement. The full specification covers every endpoint, every data structure, every state machine, and every error code. We welcome contributions, criticism, and competing implementations.
Questions about ACP's design? Reach out at developers@cresva.ai or join our GitHub discussions.