Skip to content
cresvaDevelopers
All posts
Updated September 16, 2026ProtocolArchitecture

From REST to Agent-Native: Why Commerce Needs a New Protocol

Update, 16 September 2026. Two things in this post were corrected. A

section headed "Measuring the difference" quoted four comparisons from a beta

programme. There was no beta programme and the figures were not measured;

that section is removed and the note where it stood says so. The sample

responses used a product schema and a path that do not exist, and both are

now the real ones. The argument of the post is a design argument and it is

unchanged.

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 Open Storefront Protocol (OSP) 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 optimised for human browsing. This example is illustrative, written to show the shape rather than copied from any particular vendor:

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 OSP:

GET /api/storefront/{brandId}/products?limit=1

{
  "products": [
    {
      "title": "The Complete Snowboard",
      "price": { "amount": 699.95, "currency": "USD" },
      "availability": "in_stock",
      "rating": null
    }
  ]
}

Correction, 16 September 2026. This example used to show

GET /v2/products, a price as an integer number of cents, and three fields

that do not exist: trust_score, agent_hints and comparison_highlights.

The block above is the live response, trimmed, captured 16 September 2026.

A product card carries id, title, summary, price, availability,

rating, attributes, purchase_url and images, and the price amount is

a decimal, not cents.

Every field is typed and machine readable. The price is a number with a

currency beside it rather than a formatted string. Availability is an enum, not

prose. And rating is null rather than 0, which is the single most useful

thing in the response: it says the rating could not be established, where a

zero would have said the product is rated badly.

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 a dozen storefronts for lightweight running shoes would need a dozen parsing strategies, one per storefront, and a new one each time a storefront changed its schema.

A product card carries an attributes map, so a storefront can publish the

facts an agent needs to compare on rather than burying them in a description.

The keys in that map are the storefront's own.

Correction, 16 September 2026. This paragraph described a standardised

attribute taxonomy per product category, with weight_grams, drop_mm,

terrain and arch_support as guaranteed keys for running shoes. There is

no such taxonomy. Those keys appear nowhere in the OpenAPI document and

attributes is a free map. A shared vocabulary per category is a reasonable

thing for the specification to define and it does not define one today.

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.

OSP's negotiation protocol provides:

  • Typed message schemas for offers, counter-offers, and deal structures
  • A state machine with well-defined transitions: INITIATED -> OFFER_SENT -> COUNTERED -> ACCEPTED | REJECTED | EXPIRED
  • Session-scoped context that persists across turns
  • Timeout handling so stale negotiations do not block resources

You could build negotiation on top of REST, but you would be reinventing most of what OSP 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.

OSP publishes a trust score per storefront, at GET /api/storefront/{brandId}/trust. It is a composite from 0 to 100 across seven components, and the response says how much of itself was measured: a component with no evidence comes back null, and below half the weight measured no tier is published at all. A score is not attached to a product card.

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.

OSP defines a transaction lifecycle from creation through fulfillment. An agent can open a checkout session, track it, and record a dispute through one protocol. Direct transaction creation at POST /api/storefront/{brandId}/transactions is withdrawn and returns 410 Gone; the live path is a checkout session. Payment happens directly between the buyer and the merchant, on the merchant's own rails; OSP does not hold or move funds at any point. 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 is wasteful and still introduces latency between the event and the agent learning about it.

OSP defines 36 webhook events, counted from lib/webhook-events.ts on 16 September 2026, covering state changes 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. OSP eliminates that fragmentation by standardizing the commerce-specific layer that REST intentionally leaves unspecified.

OSP 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 OSP to be incrementally adoptable. You do not need to rewrite your commerce stack to support OSP.

Level 1: Read-only discovery. Expose your product catalogue through the discovery and catalogue endpoints. This requires mapping your existing product data to the product card shape and serving it.

Level 2: Negotiation. Add support for the negotiation protocol. This requires a pricing engine that can evaluate and respond to agent offers.

Level 3: Checkout. Enable checkout sessions. This requires wiring your own payment processor, because OSP never sits in the payment path, and mapping your order management system to the transaction state machine.

Level 4: Everything else. Webhooks, the conformance suite, offers and bundles.

Each level is independently valuable and each is optional. A storefront that publishes only discovery and catalogue is a conforming storefront.

Measuring the difference

Retraction, 16 September 2026. A section here reported four comparisons

between OSP and REST integrations, attributed to "our beta program": query

accuracy 94 percent against 71, transaction completion 89 against 62,

average response time 140ms against 340ms, and median integration time 3 days

against 2 weeks.

There was no beta programme and none of those numbers was measured. They are

removed rather than softened, because a softened version of an invented

figure is still an invented figure.

The measurements that do exist are on

the performance post, which is itself

retracted and now carries the real production figures in place of the ones it

originally published.

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.

OSP 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 OSP's design? Reach out at developers@cresva.ai or join our GitHub discussions.