Your Menu Needs an API

I argued in The Interface Was the Moat that the delivery marketplaces sold merchants an interface rather than logistics, and that agentic commerce removes the need for the interface. The economics of that are brutal in the merchant's favour: marketplace commission runs 15% to 30% of order value, while ordering through the merchant's own page costs roughly 3% in payment processing.

The obvious response is: fine, so why has nobody moved?

They have tried. Direct ordering has existed for years and most independents still send the majority of their off-premise volume through the marketplaces anyway. There is a reason, it is a good one, and understanding it is the whole point of this piece.

The objection that actually mattered

Direct ordering made you responsible for your own demand.

The marketplace was never only a payment page. It was a place customers already were, with a recommendation engine, a promotions budget and a slot on a home screen. Going direct meant keeping 15 to 30 points of revenue and also inheriting a marketing job you had no staff for.

For most operators that trade was not obviously good. A high-margin channel nobody uses loses to a low-margin channel that is full.

The agent breaks that trade, and this is the part worth sitting with. When a customer tells an assistant to order from your restaurant by name, the demand routing is already done. The agent is not browsing a marketplace and picking you out of a grid. It is looking for an endpoint that can take the order.

If you have one, it goes there. If you do not, it falls back to whoever does, which today means the marketplace, which means you keep paying the commission for demand you had already earned.

Direct ordering stops being a marketing problem and becomes an integration problem. Integration problems are tractable. Marketing problems, for a restaurant with four staff, mostly are not.

What "agent-ready" actually decomposes into

Here is the honest build list. It is longer than a website and shorter than people fear.

1. A catalogue as structured data. Items, modifiers, option groups, prices, tax treatment, real availability, prep time, allergens. Machine-readable and current. Not a PDF, not a photo of a menu, not a page whose prices are eighteen months stale. An agent cannot order what it cannot parse, and it will not guess.

This sounds trivial and is the single most common blocker. Most independents do not have an accurate machine-readable menu anywhere, including inside their own point of sale.

2. A quote endpoint. The agent needs to ask what a specific basket costs, including tax, fees and any delivery charge, and get an answer it can rely on for long enough to pay. A price with a short time-to-live. This is not the same as publishing a menu, and it is where most naive integrations break, because tax and fee calculation is genuinely fiddly.

3. Payment acceptance in whatever the agent is carrying. Two competing standards are live, both built on HTTP 402: x402 from Coinbase, stablecoin-native and currently carrying the most volume, and MPP from Stripe and Tempo, which handles stablecoins and also routes card payments through Shared Payment Tokens.

You do not get to pick which one your customer's agent speaks. The practical answer for a small merchant is not to implement either directly. It is to sit behind a processor that already speaks both, which today mostly means Stripe, and let them offramp into an ordinary balance.

4. Order injection into the system you already use. This is the expensive part and nobody mentions it. A paid order that arrives in an inbox nobody watches during a Friday rush is worse than no order at all. It has to land in the point of sale, print in the kitchen, and enter the existing flow exactly like every other ticket.

Toast, Square and Clover all have APIs. They are all different. This is where the real hours go, and it is the reason "just add an ordering page" is not the same project as "become agent-ready."

5. A status channel back to the agent. Accepted, rejected, prep time, ready, collected, delivered. The agent is a piece of software that needs to report back to a human who is waiting, and it cannot do that by staring at your front door.

6. Discoverability in whatever registry agents consult. Early ones exist: x402scan and MPPscan, both maintained by Merit Systems, who also run AgentCash as a payment and discovery layer. Which of these matters in three years is not knowable today, which is an argument for an abstraction rather than a bet.

The part nobody has built yet

Items one through six are engineering. This one is not, and it is where I would expect the first real failures.

Exceptions.

A human ordering a pizza handles exceptions conversationally without noticing. They are out of pepperoni, is sausage acceptable? The delivery is forty minutes, is that still fine? The order arrived cold and the customer wants something done about it.

With an agent in the middle, every one of those needs a defined protocol. Who is authorised to approve a substitution, and for how much of a price difference? What happens to a payment that has already settled when the merchant cannot fulfil? Does the agent have standing authority to accept a partial refund, or does it have to go back to a human who has now walked away from their phone?

Nobody has good answers to this and the standards do not specify it. Payment protocols solve payment. The commercial relationship around a failed or altered order is being left to implementations, which means it will be inconsistent, which means the first wave of agent orders will produce a set of disputes nobody has a process for.

If you are evaluating anyone offering to make you agent-ready, this is the question to ask them, because it separates people who have thought about operations from people who have read a protocol spec.

Delivery is already solved, today, and most operators do not know it

The thing that makes this immediately actionable rather than speculative: you can already buy the driving without buying the marketplace.

Uber Direct and DoorDash Drive are white-label courier services. Orders come through your own channel, their driver network delivers, and you pay a flat per-delivery fee instead of a percentage commission. DoorDash's own direct online ordering starts at 0% commission with standard payment processing on top. You keep the customer relationship and the data.

Run the arithmetic against a 3% to 5% net margin and it is not close. A flat fee is a flat fee whether the ticket is 20 dollars or 90. A 25% commission is not.

The strategy that has emerged in 2026 is three layers, and it is a sensible thing to be doing already:

• Marketplaces for discovery, accepting the commission as a customer acquisition cost.
• Direct ordering for repeat customers, who already know your name.
• White-label couriers for anything that arrives through your own channel.

Two honest caveats. Per-delivery pricing is quoted on distance, order value and volume rather than published, so you need an actual quote to compare properly. And a commission-free storefront run by a marketplace still leaves you inside that marketplace's ecosystem.

But the direction is clear, and every part of it works right now. Agents make the middle layer much larger, because named-intent orders route straight to it.

Build, rent, or wait

Three options, stated plainly.

Wait. Defensible for another year or so, and the adoption numbers support it. The agentic payment rails were processing tens of thousands of dollars a day in early 2026 against an ecosystem valued in the billions. The narrative is well ahead of the volume.

The risk of waiting is not that you miss the first month. It is that the gap gets filled by an aggregator again, on their terms, while you were waiting for certainty. That is exactly how the last thirty points of margin left the building.

Rent. Somebody will sell you an agent-ready storefront as a subscription, and for many operators that will be the right answer. The question to ask is who owns the customer record and the order history. If the answer is not you, you have re-signed the same deal in a new font.

Build. Sensible for a group with multiple locations, an in-house developer, or unusual requirements. The catalogue and the point-of-sale integration are the bulk of the work; the payment layer is comparatively thin if you sit behind a processor that speaks both protocols.

How to evaluate anyone who offers to do this for you

Five questions. They are ordered so that the answers get more revealing.

1. Where does the order land? If it does not print in the kitchen alongside everything else, it will be missed during a rush. Ask to see it happen on the actual point of sale you run.
2. Who owns the customer record? Name, order history, contact. If the vendor owns it, you are renting your own customers again.
3. What happens when you are out of an item mid-order? The exceptions question. Listen for whether they have an answer or a shrug.
4. Which payment protocols does it speak, and what happens when a third one wins? The correct answer involves an abstraction layer, not a bet on x402 or MPP.
5. What does it cost as a percentage of a 40 dollar order? Then compare that honestly against what the marketplace takes. If the number is not obviously and dramatically lower, the entire exercise is pointless.

The actual point

The delivery apps did not win because they were clever. They won because they solved a problem merchants could not solve individually, and then charged for it forever.

The identical gap is opening again. The merchant side of agentic commerce is a real integration project that a pizzeria owner cannot and should not attempt personally, and there is a version of the next five years where that gets solved by another intermediary who takes another permanent cut.

There is also a version where it gets solved as ordinary implementation work, the merchant owns the endpoint and the customer record, and the saving stays split between the operator and the person buying dinner.

The difference between those two outcomes is whether somebody builds the merchant side as infrastructure the merchant owns, or as a platform the merchant rents. That is a choice being made right now, mostly by people who are not restaurants.

Your menu needs an API. The question is who holds the keys to it.