When the buyer never visits your website.
People are starting to ask an AI assistant what to do this weekend and expecting to book it in the same conversation. Here is what genuinely has to be true for that to work, what we already ship, and what we do not.
Status
Live — assistants can complete a purchase against our API
Everything described below runs against the published API. The contract is at /openapi.yaml.
Agentic commerce means an AI assistant completing a purchase for someone inside the conversation, instead of handing them a link. For ticketing, the protocol is the easy half. What an assistant actually needs is live availability, a price it is not allowed to guess at, a hold that survives a slow conversation, a sale recorded on real inventory, and a ticket the gate will accept — and on this platform all five already exist as a documented API, because they shipped for marketplaces and ticket agents first. The assistant adapter is a translation layer on top of that, which is a very different starting position from a platform that has to build the whole thing.
What actually happens, step by step
Someone asks an assistant for something to do this weekend. Nine steps to a person walking through the door — with what is genuinely live today marked on each.
| Step | What happens, and what is live |
|---|---|
| 1. Someone asks an assistant a question | "What family-friendly shows are on this weekend near me, and are any of them any good?" Not our surface, not our software — this is the part that already happens millions of times a day. |
| 2. The assistant has to FIND the event | PARTLY OURS, AND THE REAL BOTTLENECK. Every event page we publish carries complete Event structured data — dates, the venue with coordinates, the organizer, the ticket offer — which is what makes an event legible to a machine. That earns eligibility, not selection. See the honest limits below. |
| 3. The assistant checks what is actually available | LIVE TODAY — GET /events/{id}/availability. Real remaining counts computed the same way the buyer site computes them, including admin-blocked inventory and live holds. An assistant quoting stale availability sells seats that are gone. |
| 4. The assistant asks what it really costs | LIVE TODAY — POST /quote. The authoritative total in integer cents, fees and tax included, from the same pricing engine that charges a buyer. An assistant must never compute the price itself. |
| 5. The seats are held while the person decides | LIVE TODAY — POST /events/{id}/holds. A ten-minute hold on the same transactional lock the buyer checkout uses, so the same seat cannot be sold twice. Conversations are slow; holds are what make that survivable. |
| 6. The person authorizes payment inside the assistant | NOT OURS — this is the protocol’s job, and the part the standards bodies are actually arguing about. The emerging shape is a cryptographically signed authorization the merchant can verify, with a tokenized payment credential (a saved card, a wallet) attached. |
| 7. The sale is recorded and tickets are issued | LIVE TODAY — POST /orders. Prices are re-derived server-side (an agent’s claimed price is discarded), inventory is verified under the hold, real tickets are minted, the buyer is emailed, and the order is idempotent on the agent’s own order id so a retry can never double-sell. |
| 8. They walk in and the ticket scans | LIVE TODAY — POST /orders returns each ticket’s qrValue, which is exactly the value the promoter’s gate scanner reads. No separate redemption integration, no special case at the door. |
| 9. On the day, food and merch | LIVE TODAY, as a SECOND order. Concessions are deliberately their own order and their own payment — never folded into the ticket charge. Worth knowing before anyone promises an assistant one combined cart. |
Five things that have to be true
Most of what is written about AI commerce skips these. They are the difference between a demo and a venue that can actually sell this way.
Discovery is the hard part, not checkout
It is tempting to picture the assistant naturally surfacing your event. It has to find it first, and that is the genuinely unsolved half. Checkout is an engineering problem and it is largely solved here; being chosen by an assistant is a distribution problem that structured data, catalogs and plain reputation decide over months. Anyone selling you a protocol integration as an audience is selling you the easy half.
Nobody has won the standard yet
There are several competing agentic-commerce efforts in flight, backed by the largest AI and commerce companies, and none of them has settled. Building to one and calling it done is how you buy a rewrite. The defensible position is one internal machine-buyer API with thin adapters on top — which is the position we are already in, because that API shipped for human resellers first.
An agent needs the truth, live
A human tolerates a stale page and a sold-out message at checkout. An agent that quotes a price it computed itself, or availability it cached, produces a confidently wrong answer and a buyer who blames you. This is why the authoritative quote and the live availability endpoint matter more than the protocol does.
The money still has to land somewhere
Paying inside an assistant does not change who the merchant of record is. On this platform that is the promoter’s own account, or ours if they use our gateway — and the agent sale is recorded on the same rails as every other sale, so refunds, disputes and reporting work the way they already do rather than through a separate pipe nobody owns.
Someone has to answer for a bad purchase
When an agent buys the wrong night, or two tickets instead of four, the person complains to whoever is named on the confirmation email — which is the promoter. Verifiable authorization and a clean refund path are not paperwork here; they are the reason a venue can risk selling this way at all.
What is already shipped
Not roadmap. Each of these is live, in production, and the API contract is public — check it before you believe us.
A documented machine-buyer API
Key-authenticated JSON with an OpenAPI 3.1 contract: the event catalog, live availability, an authoritative quote, holds, recorded orders and refunds. It shipped for marketplaces and ticket agents, and it is the same surface an assistant needs.
Tickets that work at the door
An order recorded through the API mints real tickets and returns the QR value the promoter’s own gate scanner already reads — including offline, where the phone validates against a downloaded manifest with no signal at all.
Per-promoter control, not a platform switch
Access is granted by each promoter, per event, with their own commission rate and optional caps — so a venue decides which events reach an agent and how many seats it may sell, rather than the platform deciding for them.
Events built to be read by machines
Every event page publishes complete Event structured data and sits in an hourly sitemap. That is the layer assistants and search engines actually read, and it is switched on for every event without anyone configuring anything.
Concessions on the same rails
Food, drink and merch already sell through their own ordering flow with live stock, per-variant availability and pickup codes — so the cross-sell an agent would make is a real order in a real queue, not a coupon.
Change notifications, signed
Registered endpoints receive signed webhooks when availability or assignment changes, so an integrator is not reduced to polling — the same mechanism an assistant needs to avoid offering something that just sold out.
What we have not built
We cannot make an assistant choose your event. Publishing correct structured data makes you eligible to be surfaced and is genuinely more than most platforms do. It is not the same as being picked, and no integration sold by anyone changes that. Treat any vendor promising AI-driven demand as selling you the half nobody controls.
The standards may change under everyone. Several protocols are competing and the winner is not obvious. Our answer is to keep the internal API stable and treat each protocol as an adapter, so a shift costs us a translation layer instead of a rebuild — but anyone claiming certainty about which standard wins is guessing.
If it matters to your programming, the honest thing to do is ask us where it stands on the day you ask, and read the API contract for what exists right now rather than what a page promises.
Questions worth asking anyone about this
Not yet, and anyone telling you their ticketing platform does this today is worth checking carefully. What exists today is the machine-buyer API an assistant needs — live availability, an authoritative price, holds, recorded orders that issue real scannable tickets — documented publicly with an OpenAPI contract. The remaining piece is the adapter that speaks whichever agentic-commerce protocol settles, and that is in build.
Be ready before the traffic arrives
If agent-led buying matters to your season, we will walk you through exactly what exists today, what is in build, and what it would take to connect your events — including the parts we told you we have not finished.