There is one seating inventory model, but two current products. Decide who owns commerce and fulfilment before choosing a framework, embed, link, or Website.
1. Choose the product boundary
Platform / SDK infrastructure
Choose this when your marketplace or ticketing product owns the event catalogue, buyer, checkout, payment, commercial order, tickets, delivery, refunds, scanning, and support. SeatLayer supplies seating inventory and operational tools.
Managed ticketing
Choose this request/staff-approved product when a direct organizer wants SeatLayer to run hosted checkout, Orders, ticket/QR/PDF delivery, email, refunds, and Door/check-in through the organizer’s connected gateway.
Commerce ownership is fixed for each Event. Embedding a different buyer surface does not switch products; reuse the Chart and create a new Event when commerce ownership must change.
2. Platform / SDK infrastructure
For a marketplace or existing ticketing backend, a SeatLayer Event is only the authoritative inventory occurrence. It can be created from a chart with minimal metadata. It does not imply a public SeatLayer event page or ticket fulfilment.
Your CMSProvisions seating inventory
Your product creates the workspace, chart, and inventory Event for the commercial event it already owns.
Buyer SDKSelects and holds
The buyer chooses inventory and receives a temporary opaque hold identity.
Your backendInspects the hold
It reads the authoritative hold before calculating the order or deciding payment.
Your commerce systemCreates the commercial order
Your product applies its own customer, payment, tax, and refund rules.
Your backendBooks with bookingRef
The stable commercial order ID is used to make inventory booking safe to retry.
SeatLayerCommits and notifies
SeatLayer commits inventory atomically and emits signed inventory events for reconciliation.
Your commerce systemDelivers tickets
Your existing product confirms the order and provides tickets, support, and fulfilment.
Choose the buyer seating UI
| Surface | Best fit | Your product owns |
|---|---|---|
SeatPicker |
Standard seating step with built-in selection summary and hold handoff | Checkout, payment, order, tickets, and every step after onCheckout |
SeatingChart |
A custom cart or unusual selection workflow | Cart UI, explicit hold lifecycle, checkout, and fulfilment |
@seatlayer/react |
React applications using either SDK model | The same responsibilities as the wrapped component |
| Native SDKs | Mobile buyer applications | The surrounding app, commerce, and fulfilment |
The browser never receives a secret key and never confirms a permanent booking
on its own. Your trusted backend inspects the opaque holdId and books with one
stable bookingRef after its payment/order decision.
Add staff surfaces when needed
- Use a Workspace per platform customer or organizer.
- Use Embedded Designer for workspace-scoped chart creation.
- Use the embedded Control room for live inventory, blocking, safe booking cancellation, booking history, sell-through, and reports.
- Mint short-lived, exact-origin Designer/Control room sessions from the platform backend after authenticating the platform user.
The SDK Control room is not the platform’s Orders, ticket-delivery, refund, or door-attendance system.
3. Managed ticketing
For a direct organizer, choose where buyers should arrive before working through
the setup below it. Managed Ticketing is not enabled automatically: request
access, wait for SeatLayer staff approval, and confirm Hosted Checkout
(hosted_checkout) is enabled for the organization. SeatLayer can then own the
managed hold-to-payment-to-Order-to-ticket lifecycle on all three routes. The
organizer’s connected provider controls processing fees, applicable taxes, and
payout timing.
| Route | What to choose | Access requirement |
|---|---|---|
| My existing website | Copy an inline picker, event card, or Buy button into WordPress, Wix, or HTML | This is a public route. Visitors need public buyer access; no backend is required |
| SeatLayer-hosted page | Share the event booking page and optionally add Organizer Website discovery | Anyone with the enabled page URL can open it; Website listing is a separate public-discovery choice |
| Private access | Use a scoped Channel link, or the authenticated website/app setup | A Channel link grants its bearer scoped access; a private website needs a backend-authenticated, short-lived session |
Public website code can be generated and installed before gateway or payment setup is complete. Installation does not publish the event or open sales: visitors still need public buyer access, and checkout cannot complete until payment readiness is satisfied and sales are open.
The inline picker reads its map, seat and category colours, logo, and brand from the published floor plan attached to the event. Sell & Share can add explicit buyer-control theme, accent, button-label, and height overrides to the copied markup; it does not duplicate the venue design into HTML. Wix Embed HTML is framed, so its generated card/button opens the SeatLayer booking page before any seat hold instead of attempting redirect-based payment in the iframe.
Every generated block contains a normal buyer-page link. It stays useful when JavaScript or the widget cannot load, and non-production blocks carry their matching API and buyer origins rather than falling through to production.
These routes do not change who owns checkout. Publishing page content, listing an event on an Organizer Website, and opening sales remain explicit actions.
Common combinations
A multi-tenant ticketing platform
Create one Workspace per organizer, create or duplicate reusable charts, create minimal inventory Events, embed the buyer SDK, and confirm inventory from the platform backend. Add Designer and Control room sessions only for authorized organizer staff.
A commerce site with its own checkout
Use SeatPicker or its React wrapper and receive holdId in onCheckout.
Inspect the hold, run your own order/payment flow, then call /book.
A direct organizer without a commerce backend
Use Managed Ticketing. Choose an existing website, a SeatLayer-hosted page, or private access; first obtain approval and Hosted Checkout enablement, then connect a gateway, finish event readiness, and open sales.
Do not cross the boundaries
- Do not create SeatLayer Orders, tickets, email, PDFs, refunds, or attendance records from a Platform/SDK inventory booking.
- Do not expose an account secret because a browser needs more control.
- Do not use organization-wide dashboard membership as workspace-specific organizer access.
- Do not use
SeatManageras a buyer picker; it grants operator capabilities. - Do not assume an Event ID makes a Hosted Event Page or Website public.
- Do not describe configured booked value as money collected or settled.
Selection checklist
- We chose Platform/SDK or Managed Ticketing before choosing placement.
- A Managed organization is staff-approved and has
hosted_checkoutenabled before event setup or sales planning. - We wrote down which system owns payment, commercial Orders, tickets, refunds, and check-in.
- Platform integrations store their own order ID as
bookingRef. - Platform-created Events remain inventory-only and have no implicit hosted public surface.
- The secret key exists only in a trusted environment.
- Embedded staff sessions are workspace/event scoped and short lived.
- Inventory reports and financial reports are labelled and reconciled as separate authorities.
Continue with the platform integration guide, the ticketing backend flow, or the booking endpoint.