There is one seating inventory model, but two current products. Decide who owns commerce and fulfilment before choosing a framework, embed, link, or Website. For the full list of ready-made surfaces and their boundaries, read product surfaces and their purpose.
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 self-serve 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
Pick the buyer SDK for where your code runs (web, native app, or both) on Choose an SDK or API. That page and the platform pages it links to compare the ready-made picker, the map-only chart, and the native SDKs.
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. Hosted Ticketing is self-serve: events created in the dashboard use SeatLayer checkout, and the organizer connects their own Stripe or Razorpay account on the Payments page, with no access request or approval. SeatLayer owns the managed hold-to-payment-to-Order-to-ticket lifecycle on all three routes. A free event skips payment and uses one Hosted Ticket per confirmed ticket. Platform/SDK Events are created with a secret key instead. 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 Hosted Ticketing. Choose an existing website, a SeatLayer-hosted page, or private access; create the event in the dashboard, connect a gateway (not needed for a free event), 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 Hosted Ticketing before choosing placement.
- Managed events are created in the dashboard, and each paid event has a connected payment gateway assigned before sales open.
- 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.