Changelog
What's new in the Ticketero API. New endpoints, fields, webhooks and breaking changes, most recent first.
Idempotent ticket orders
- New
POST /orders/createaccepts an optionalIdempotency-Keyheader. Retrying with the same key never creates a second order: if the first request created the order you get the original response back, with anIdempotent-Replayed: trueheader. Keys are scoped to your account and kept for 24 hours. - New
409responses with adata.codewhen a key clashes:IDEMPOTENCY_IN_PROGRESS(the first request is still running, retry with the same key),IDEMPOTENCY_KEY_REUSED(same key, different ticket, event or quantity) andIDEMPOTENCY_OUTCOME_UNKNOWN(do not retry, contact support). See Retry safely. - Heads-up when you lock first and send no header, the
requestIdof the lock is used as the key. ThatrequestIdmust be a real lock: an invented value can be rejected, so send the header instead. - Heads-up
POST /orders/statustakes asconfirmationtherequestIdreturned byPOST /orders/create, not the one from the lock. Earlier guides suggested reusing the lockrequestId.
Tickets lock during a sale
- New every ticket payload now carries a
lockedboolean (GET /broker/tickets,GET /broker/tickets/{ticket_id}). It istruewhile a buyer checkout is holding that listing. - Breaking writes on a locked ticket are rejected with
409and{ “locked”: true }. AffectsPUT /broker/tickets/{ticket_id},PATCH /price,/stock,/statusandDELETE /broker/tickets/{ticket_id}. The lock clears on its own when the sale completes or the checkout expires. - Heads-up sync jobs should skip listings whose
lockedistrueinstead of retrying in a loop. A queued retry on the next cycle is enough. See Locked tickets.
Attendee address and phone
- New
required_purchase_fieldsnow carries two extra keys on every ticket:address_requiredandphone_required. When either is“1”, sendaddressandphoneon eachpaxesentry ofPOST /orders/create.addressis a single-line text field, andpaxes[].phoneis the attendee’s phone, separate fromdelivery.phone. - Improved
deliveryMethodsandtgDeliveryMethodnow always return standard labels (Direct Transfer,E-Ticket,Mobile Ticket,Mobile Entry,Instant Download,Email,Physical). Tickets that used to expose raw internal keys are mapped to these labels. - Heads-up read
required_purchase_fieldsas an open object. Keys are added over time and unknown keys must not break your parser.
Order checkout grouping code
- New a short 6-character
ordercode identifying the buyer’s checkout is now returned on every order object:GET /broker/orders,GET /broker/orders/{id}and theorder.*webhooks. Orders bought together in one checkout share the same code, so you can group a multi-ticket purchase. May benull. - Improved
POST /broker/webhooks/{id}/testnow sends a full syntheticorder.createdpayload (a complete order shape with fake values anddata.test: true) instead of a bare stub, so you can validate your parser end-to-end.
Ticket category & external IDs
- New optional
categoryfield on tickets. Set it onPOST/PUT /broker/ticketsand read it back wherever a ticket’s seating is returned, including the Buyer APIseatsobject. - New
external_idis now returned on Seller order objects (GET /broker/orders,GET /broker/orders/{id}), in order webhooks, and on each successful row ofPOST /broker/tickets/bulk. - New the
ticket.disabledwebhook payload now carriesexternal_idalongsideticket_id. - New persist the
ticket_idreturned byPOST /broker/ticketsand reuse it as-is on every later call to that ticket.
Richer order details
- New order objects (and the
order.*webhooks) now include the buyerrecipientand the full event/venue snapshot, so you can fulfill straight from the webhook without a follow-upGET.
Seller API launch
- New the Seller API is live. Publish and manage inventory, fulfill orders, track payments and receive signed webhooks.
Buyer API launch
- New the Buyer API is live. Search events, browse tickets, reserve seats and complete purchases.

API