Set up a box office

Ticketlayer has two ways to sell without writing a website, and a way to scan what was sold.

The hosted box office#

Every sales channel can have a hosted storefront: a complete ticket shop (events, dates, tickets, cart, checkout, account, confirmation) served by Ticketlayer on a hostname you point at it. It is the same code that renders the embedded checkout on your own site.

1. In Backstage create a sales channel and list the events it sells.
2. Give the channel a storefront domain. Channels are served at <slug>.checkout.ticketlayer.com; a custom domain is a CNAME to the same place, registered on the channel so the storefront can resolve which channel a request is for (it resolves by Host, so there is no key in the page).
3. Assign a theme to the channel (logo, colours, fonts). The storefront and every Element on your own site read the same theme.

There is nothing to deploy: the storefront is live when the channel is.

Selling at the counter#

Staff sales go through the Backstage API's cart operations rather than Live's customer-facing sales surface, so a staff member can sell on a customer's behalf, take cash, and print. An operator is a named person, so the credential is their staff token; the box office channel travels as the X-Ticketlayer-Channel header, because a staff token names an organisation and not a channel:

• POST /v1/cart with X-Ticketlayer-Channel: <box office slug> creates a staff cart on that channel, POST /v1/cart/{cartId}/items adds tickets, POST /v1/cart/{cartId}/checkout completes it.
• POST /v1/orders/{orderId}/payments initiates the payment and GET /v1/orders/{orderId}/payment-status reports it.
• GET /v1/orders/{orderId}/passes/{passId}/ticket.pdf and POST /v1/orders/{orderId}/passes/{passId}/print produce the tickets; ticket templates (/v1/ticket-templates) control the layout.

Box office staff sell at channel scope: the app reads GET /v1/my/sales-channels at sign-in, offers a picker, and sends the chosen slug on every request. An organisation owner or an event manager holds the same permissions at organisation scope and needs no header. The whole sequence, with the credential on every call, is Staff at a box office or a till; the operations are in the Backstage API reference under Carts and Orders.

A seated date sells from the seat map: the keypad and Next best choose the best seats for a party, a tap takes one seat, and a held seat or a single seat gap is sold only after a confirm. Sell seats in Box Office is the help article for the counter.

Scanning at the door#

Entry is a device paired to the organisation (a phone or a handheld scanner running the scanning app):

1. Pair the device: POST /v1/devices/pairing starts a pairing, a staff member claims and confirms it (POST /v1/devices/pairing/claim, POST /v1/devices/pairing/{pairingId}/confirm), and the device receives its credential.
2. Configure scanning: a scan config (/v1/scan-configs) says which events and occurrences a device admits and is assigned to devices.
3. Pick the channel: a device credential names the organisation, not a sales channel, and the Scanner roles read events per channel. The device asks GET /v1/my/sales-channels which channels it may work and sends the chosen slug as X-Ticketlayer-Channel on GET /v1/events and GET /v1/events/{id}; without it those answer 400 CHANNEL_REQUIRED. The list includes the channel's hidden events (invitation-only, comps-only), flagged, so the door can choose them. A channel created later grants the Scanner role nothing until someone grants it access. Scanning itself needs no channel.
4. Scan: the device fetches its manifest (GET /v1/scan/manifest) so it can work offline, and submits scan operations (POST /v1/scan/operations) which redeem passes. Every redemption emits a ticket.redeemed webhook and can be reversed (POST /v1/redemptions/{redemptionId}/reverse).

The full device model (pairing, credentials, commands, events, locations) is under Devices in the Backstage API reference.