For Developers · Guide
Choosing a Commerce API for Your AI Agent
You built an agent that gives genuinely good shopping advice. Then a user says "okay, buy it" and you realize your agent has no way to do that. This is the gap a commerce API fills, and most of the APIs you already know were never built for it.
Start with what your agent actually needs to do
Picture a skincare advisor app. A user describes their skin, their budget, the fact that everything they own breaks them out, and asks for a moisturizer. Your agent reasons beautifully and lands on a recommendation. Now what? To finish the job, the agent has to do four concrete things, and a commerce API has to support all four or the experience falls apart.
It has to find real products that match a messy natural-language request. It has to compare them on the attributes the user actually cares about, like whether the formula is fragrance-free. It has to know live price and stock, because recommending a sold-out product is worse than recommending nothing. And it has to let the user buy without bouncing them to a website. Hold those four jobs in your head, because they are the lens for judging any commerce API.
Why the APIs you already know fall short
The instinct is to reach for the tools you have. A platform's storefront API. A search API. An affiliate feed. Each was designed for a world where a human sits in front of a screen, and that assumption leaks into every response they return.
Classic ecommerce APIs return data shaped for rendering, not reasoning. You get a title, a marketing blurb, maybe a category, and a pile of HTML. That is enough to paint a product page. It is nowhere near enough for an agent to answer "is this safe for sensitive skin" with confidence. Search APIs are tuned for keyword matching against a query box, so they choke when the input is a paragraph of intent rather than two words.
Affiliate feeds deserve their own paragraph because they are the trap most builders fall into first. A feed is a periodic export: a big file you pull on a schedule. By the time your agent reads it, prices have moved and items have sold out. There is no checkout in a feed, so the only thing you can do is hand the user a redirect link, which is exactly the move that loses the sale. Industry estimates put average cart abandonment around 70 percent, and every extra step you add after a user has decided makes that worse. We dig into the mechanics in adding native checkout to your AI app.
The seven things to evaluate
Here is the checklist I would run any commerce API through before wiring it into an agent.
1. Intent-native search
Can you send a full sentence of intent and get back products that actually fit? "Noise cancelling headphones for travel under 3,000 with good battery life" should resolve to real matches, not a keyword soup of "headphones." Good commerce APIs fan a request out into price-bounded, attribute-bounded, and use-case-bounded sub-queries and match those against structured data. That fan-out is the heart of agentic commerce.
2. Structured, comparable attributes
An agent reasons by comparing fields. Depending on the category, a single product needs anywhere from 15 to 40 structured attributes before an agent can line it up against alternatives: fabric, ingredients, dimensions, compatibility, certifications. If the API gives you a name and a paragraph, your agent is guessing, and a guessing agent recommends the wrong thing.
3. Live price and stock
This is non-negotiable and it is where feeds die. The price and availability your agent sees must be the price and availability at the moment of the conversation. Anything stale will eventually recommend something a user cannot buy, and that breaks trust instantly.
4. In-conversation checkout
The API has to expose the actual transaction primitives: building a cart, applying offers and discounts, linking identity, and running checkout. If the only "buy" path is a URL, you do not have a commerce API, you have a link generator. Standards like OpenAI's Agentic Commerce Protocol and Google's Universal Commerce Protocol exist precisely to make in-chat buying real.
5. Attribution you can trust
If your agent drives a sale, you need credit for it. Redirect-based attribution is famously fragile: it breaks across app boundaries, cookie resets, and copied links. Look for transaction-level attribution, where the sale is tied to your agent at the point the purchase executes, not inferred from a click that may or may not have survived the round trip.
6. Selective surfacing
You rarely want to expose an entire catalog. A gifting agent should surface gift-appropriate products, not industrial supplies. The API should let you hand-pick what shows up and when, triggered by your app's events and the user's behavior, so you stay in control of the experience.
7. Two integration paths
Your agent might discover tools through the Model Context Protocol, or you might prefer to build against plain API documentation. A good commerce layer supports both, so you are not locked into one framework. If MCP is new to you, start with what a shopping MCP server is.
What a call looks like in practice
Concretely, here is the rough shape of an agent completing a purchase. No real endpoints, just the flow you want the API to make possible.
User: "I need a gift for my sister, she is into pour-over coffee, around 4,000."
Agent calls a product search with the intent and budget. It gets back three real products with live price, stock, and structured attributes (grind type, capacity, material).
Agent compares them, surfaces two as cards, and answers a follow-up about whether one is dishwasher safe using the attribute data.
User picks one. Agent builds a cart, applies an available offer, collects the address, and runs checkout in the conversation. The order confirmation lands in the same chat.
Notice that the user never left. That is the whole point, and it is the thing a feed plus a redirect can never give you.
How the options stack up
Put the three kinds of integration side by side against the four jobs your agent has to do, and the gap is obvious.
| Capability | Affiliate feed | Classic ecommerce API | Agent commerce API |
|---|---|---|---|
| Search by intent | No | Keyword only | Yes, natural language |
| Structured attributes | Sparse | Built for rendering | 15 to 40 fields per SKU |
| Live price and stock | Stale export | Usually yes | Yes, real time |
| In-chat checkout | No | No | Yes |
| Attribution | Redirect cookie | None | Transaction level |
Give your agent real products to sell
Ziffi's MCP server and commerce APIs hand your AI agent a structured product graph with live price and stock, native in-chat checkout, and revenue share on every sale it drives. One free integration, two paths in: MCP or open API docs.
The bottom line
A commerce API for an AI agent is not a fancier version of an ecommerce API. It is a different shape, built for a model that reasons over structured data and completes a purchase inside a conversation. Judge any option on the four jobs your agent has to do and the seven checklist items above. If it cannot search by intent, compare on real attributes, show live price and stock, and close the sale in the chat with clean attribution, it is not the right tool, no matter how familiar it feels. For the money side of all this, read how to monetize your AI agent.