Skip to content
Cresva
Developers
ProtocolRelease

Introducing the Agent Commerce Protocol v2.0

Today, we're releasing Agent Commerce Protocol v2.0 - the most significant update to the open standard that connects AI agents to brands.

This post covers the motivation behind v2.0, the major new capabilities, the technical design decisions we made along the way, and a practical guide to getting started.

Why ACP exists

AI agents are becoming the primary way people discover and purchase products. ChatGPT, Claude, Gemini, and dozens of specialized shopping agents handle millions of product queries every day. But until now, there was no standard way for these agents to interact with brands.

Every AI platform built their own integration. Every brand had to build separate connectors. The result was fragmentation - exactly the opposite of what both platforms and brands need.

Consider what happens when a user asks an AI agent to "find me a lightweight running shoe under $120." The agent needs to query multiple brands, compare structured product data, understand pricing and availability in real time, and potentially negotiate on the user's behalf. Without a shared protocol, each of those steps requires custom plumbing for every brand-platform pair. With N platforms and M brands, you end up with N x M integrations - a combinatorial explosion that benefits no one.

ACP changes that. One protocol, every agent, every brand.

The design principles behind v2.0

Before diving into features, it is worth explaining the principles that guided this release:

Agent-first, not human-first. Traditional commerce APIs were designed to power web UIs. ACP is designed to power autonomous agents that make decisions on behalf of users. Every response is structured for machine consumption - no HTML, no presentation-layer concerns, no ambiguity. Stateful where it matters, stateless where it doesn't. Product discovery is stateless - agents can query any storefront at any time without prior context. But negotiations and transactions are inherently stateful, so ACP provides explicit state machines with well-defined transitions for those flows. Trust as a first-class primitive. In human commerce, trust is implicit - you see a brand's website, read reviews, make a judgment. In agent commerce, trust must be computable. ACP v2.0 makes trust scores a core part of the protocol, not an afterthought. Progressive complexity. A brand can go live with read-only product discovery in an afternoon. Negotiation, transactions, and advanced trust features are opt-in layers that brands adopt when they are ready.

What's new in v2.0

Negotiation Protocol

Agents can now negotiate prices on behalf of users. The negotiation protocol supports typed offers, counter-offers, and alternative deal structures like volume discounts and bundles. A full state machine tracks negotiation status from initiation through acceptance or rejection.

The negotiation lifecycle looks like this:

INITIATED -> OFFER_SENT -> COUNTERED -> ACCEPTED | REJECTED | EXPIRED

Each transition emits a webhook event, so your backend systems can react in real time. For example, when an agent sends an offer, your pricing engine can evaluate the request against your margin rules and respond with a counter-offer automatically - no human in the loop.

A typical negotiation request looks like this:

POST /v2/negotiations 
{
  "storefront_id": "sf_abc123",
  "product_ids": ["prod_shoe_001"],
  "offer": {
    "type": "price_reduction",
    "proposed_price": 9500,
    "currency": "USD",
    "justification": "bulk_purchase",
    "quantity": 3
  },
  "agent_id": "agent_claude_shopping",
  "user_context": {
    "loyalty_tier": "gold",
    "purchase_history_signals": ["repeat_buyer", "low_return_rate"]
  }
}

The user_context field lets agents pass anonymized behavioral signals that your pricing engine can use to make better decisions. A repeat buyer with a low return rate might warrant a deeper discount than a first-time visitor.

Transaction Protocol

Complete purchase lifecycle management. Agents can create transactions, confirm orders, and track fulfillment - all through structured API calls. Escrow support enables conditional purchases with timed release.

The transaction state machine covers the full lifecycle:

CREATED -> CONFIRMED -> ESCROW_FUNDED -> FULFILLED -> RELEASED | DISPUTED

Each state transition is atomic and idempotent. If a network failure occurs during confirmation, the agent can safely retry without risk of double-charging. Every transaction gets a unique idempotency_key that the protocol enforces.

Escrow is particularly important for agent commerce. When an AI agent commits funds on behalf of a user, the user needs assurance that their money is protected if something goes wrong. ACP escrow holds funds in a neutral state until fulfillment conditions are met - the brand ships the product, the user confirms receipt, and only then are funds released.

Trust Scores

Every storefront now has a composite trust score based on seven quality signals: product accuracy, fulfillment reliability, pricing transparency, customer satisfaction, response time, dispute resolution, and data freshness. Agents use trust scores to weight recommendations.

The trust score is not a single number - it is a structured object:

{
  "composite_score": 87,
  "signals": {
    "product_accuracy": 92,
    "fulfillment_reliability": 85,
    "pricing_transparency": 90,
    "customer_satisfaction": 88,
    "response_time": 95,
    "dispute_resolution": 78,
    "data_freshness": 81
  },
  "sample_size": 14280,
  "last_updated": "2026-03-27T00:00:00Z"
}

Agents can read individual signals to make nuanced decisions. For example, an agent handling a time-sensitive purchase might weight fulfillment_reliability and response_time more heavily, while an agent focused on finding the best deal might prioritize pricing_transparency.

Trust scores are computed using a Bayesian averaging model that accounts for sample size. A storefront with 10 perfect reviews does not outrank one with 10,000 reviews averaging 4.7 stars. The math is described in detail in the protocol spec.

30+ Webhook Events

Real-time notifications for every state change. From negotiation.countered to transaction.completed, your systems stay in sync. All webhooks include HMAC-SHA256 signatures for verification.

The full event taxonomy is organized by domain:

  • Discovery events: storefront.updated, product.created, product.updated, product.deleted, catalog.synced
  • Negotiation events: negotiation.initiated, negotiation.offer_sent, negotiation.countered, negotiation.accepted, negotiation.rejected, negotiation.expired
  • Transaction events: transaction.created, transaction.confirmed, transaction.escrow_funded, transaction.fulfilled, transaction.released, transaction.disputed, transaction.refunded
  • Trust events: trust_score.updated, trust_score.recalculated, review.submitted, dispute.opened, dispute.resolved
  • System events: webhook.test, api_key.rotated, rate_limit.approaching, certification.status_changed

    • Every webhook payload includes a timestamp, event_id, idempotency_key, and signature header. Your webhook handler should verify the HMAC-SHA256 signature before processing any event - this prevents spoofed events from reaching your systems.

    Enhanced Product Cards

    Product cards now include comparison highlights, brand voice summaries, and richer metadata - everything an agent needs to make informed recommendations.

    A v2.0 product card includes:

  • Structured attributes with typed values (not just strings) so agents can compare products programmatically
  • Comparison highlights that summarize how the product differs from similar items in the same category
  • Brand voice summary - a short paragraph in the brand's tone that agents can use verbatim when presenting products to users
  • Availability signals including real-time stock levels, estimated restock dates, and regional availability
  • Agent hints - metadata that helps agents decide when to recommend this product (e.g., "best for: trail running, wet conditions")

    • Performance characteristics

    We invested heavily in performance for v2.0. Product discovery queries resolve in under 150ms at the 95th percentile across our production fleet. Negotiation round-trips complete in under 300ms. Transaction creation, the most latency-sensitive operation, resolves in under 200ms with escrow funding.

    These numbers matter because agents operate in conversational contexts. A user waiting for a product recommendation expects a response within the same turn. If the underlying commerce calls take seconds, the agent experience degrades noticeably.

    Getting started

    If you're an AI platform developer:

  • Install the SDK: npm install @cresva/sdk
  • Get an API key from the dashboard
  • Make your first query in 5 minutes with our quickstart guide

    • If you're a brand:

  • Sign up at cresva.ai
  • Connect your product catalog
  • Your storefront is automatically ACP-compatible

    • For platform developers who want to go deeper, the SDK supports typed clients for every protocol domain:

    import { ACP } from "@cresva/sdk";

const client = new ACP({ apiKey: process.env.CRESVA_API_KEY });

// Discovery
const results = await client.products.search({
  query: "lightweight running shoe",
  filters: { price_max: 12000, currency: "USD" },
  limit: 10,
});

// Negotiation
const negotiation = await client.negotiations.create({
  storefront_id: "sf_abc123",
  product_ids: ["prod_shoe_001"],
  offer: { type: "price_reduction", proposed_price: 9500 },
});

// Transaction
const transaction = await client.transactions.create({
  negotiation_id: negotiation.id,
  escrow: true,
});

    Read the spec

    The full ACP v2.0 specification is available at developers.cresva.ai/protocol/spec. It covers discovery, queries, product cards, negotiation, transactions, trust scores, webhooks, authentication, errors, and versioning.

    We built this spec to be thorough enough that anyone can build an ACP-compatible client from the spec alone. If something is unclear, open an issue - we'll fix it.

    Migration from v1.x

    If you are already integrated with ACP v1.x, migration is straightforward. All v1.x endpoints continue to work under the /v1/ prefix. The v2.0 endpoints live under /v2/ and are additive - nothing was removed, only added.

    The key changes to be aware of:

  • Product card responses now include the new comparison_highlights, brand_voice_summary, and agent_hints fields. These are additive and will not break existing parsers.
  • Trust scores are now included in storefront responses by default. If you were previously ignoring unknown fields, no action is needed.
  • Webhook payloads now include an api_version field. Filter on this field if you need to handle v1 and v2 events differently.

    • We recommend migrating to v2.0 endpoints at your own pace. The v1.x endpoints will remain supported for at least 12 months after v2.0 GA.

    What's next

    Sprint 59-60 brings ACP Certification - a quality seal for storefronts that meet accuracy, reliability, and transparency standards. Certified brands will get priority in agent recommendations.

    We're also working on real-time streaming responses, multi-language support, and a plugin marketplace.

    The future of commerce is agent-driven. ACP is the foundation.

    Questions? Reach out at developers@cresva.ai or join our GitHub discussions.