Skip to main content
GET

​
Get Catalog Event

Agents: no API key needed. Register a credential yourself in two requests and send it as Authorization: Bearer. See For agents: get a credential yourself.
Returns a single catalog event, resolved with everything needed to sell it.
Requires catalog: read. This is the only endpoint that populates ticket_types and registration_questions — both are null on the list endpoint.
Resolving ticket types costs one availability read per event, and for externally supplied inventory one upstream call per event. Doing that for a whole page would multiply the cost of a list by its size, for data a list view does not use. The intended pattern is: page the list, then read the detail for what you intend to sell.

​
Path Parameters

​
string
required
The event identifier, from data[].id on the list endpoint. Always a string.

​
Response

Every field from the list response, plus the two resolved arrays below.
​
array
The buyable ticket types.
​
array
Questions the organizer asks every attendee.
An empty array and null mean different things. [] means we asked and there is nothing — no ticket types on sale, or no registration questions. null means not loaded on this endpoint. An agent that reads [] as “sold out” on a list response would skip every event in the catalog.

​
Availability is a boolean, not a count

available is deliberately a boolean, and no remaining-stock number is published anywhere on this surface. This feed crosses organizations. A remaining count sampled twice reconstructs both an organizer’s inventory and their sell-through, and publishes it to every approved integrator — including their competitors. Your only question is “can I sell this right now”, which the boolean answers.

​
Buying without a payment token

Most agents cannot complete an ACP checkout session. Completing one needs a delegated payment token, and minting a Stripe Shared Payment Token requires a browser-based Payment Element plus a registered agent account with Stripe — which a personal assistant, a CLI, or an MCP client structurally does not have. checkout_url is the path for everyone else, and it is the pattern the industry settled on: the agent does discovery and cart-building, then hands the buyer a link. The card never leaves the browser.
The link opens Gomry’s normal checkout with that tier preselected. It carries utm_campaign=catalogApi, so a sale that started in your agent is attributed to the catalog rather than to Gomry’s own discovery. It is always present — including on a tier that is sold out or not yet on sale, because the page is still worth linking and available already says whether it will sell. If your agent holds any checkout credential (a self-registered token, or a person’s OAuth sign-in granting checkout:write), build the cart through ACP checkout as usual and finish it by sending the buyer the session’s continue_url instead of paying with a token. The buyer gets a page priced to the exact session total, prefilled with their email, and pays with a card, Apple Pay or Google Pay without a Gomry account or a sign-in code. The tickets are issued when they pay, and the session reports completed. Prefer it to checkout_url, which asks the buyer to sign in to Gomry.
Use ACP complete when you are an agent platform that can hold a delegated payment token. Use a payment link when you have a credential but no token, and checkout_url when you have neither. Nothing needs to be onboarded to use either link.

​
Why you must read the questions

Roughly 30% of events ask something at registration, and most of those mark at least one answer required. An agent that ignores them sells a ticket the organizer considers incomplete. Collect the answers from your buyer and send them on POST /checkout_sessions as attendee_answers. A session with unanswered required questions stays not_ready_for_payment and reports them as blocking messages[].