There is one inventory model and several ways to present it. Choose the smallest surface that gives your product the control it actually needs.
Fast decision
Fastest buyer embed
Use the hosted iframe when you want a responsive picker with minimal JavaScript for a no-payment or direct-booking flow.
Guided checkout
Use SeatPicker when SeatLayer should manage selection, the cart summary,
hold lifecycle, and checkout handoff in your page.
Custom cart and UI
Use SeatingChart when your application owns cart presentation and calls
hold methods itself.
React application
Use @seatlayer/react. Its components wrap the same browser SDK and expose
imperative handles for advanced flows.
Ticketing backend
Use the Server API alongside any buyer surface. Server calls own event creation, hold inspection, booking, cancellation, reports, and webhooks.
Embedded platform tools
Use EmbeddedDesigner for chart creation and SeatManager for live
operator workflows inside a workspace-scoped platform.
Compare buyer surfaces
| Surface | Best fit | UI ownership | Hold control | Integration cost |
|---|---|---|---|---|
| Hosted iframe | No-payment registration, internal use, rapid preview | SeatLayer hosted page | Built in; direct booking | Lowest |
SeatPicker |
Standard reserved-seat checkout | Shared: SeatLayer picker and your checkout | Built in, with lifecycle callbacks | Low |
SeatingChart |
Custom cart, bundles, unusual checkout | Your application | Explicit methods | Medium |
@seatlayer/react |
React products using either buyer model | Same as the wrapped component | Same as the wrapped component | Low to medium |
The iframe, SeatPicker, and SeatingChart all display the same event inventory,
but the hosted iframe currently completes a direct booking. Use an SDK surface when
your own server must run payment or order logic before booking.
Choose step by step
Decide who owns the buyer UI
Choose the iframe for the hosted experience, SeatPicker for a complete
in-page picker, or SeatingChart when your application must own the cart.
Place the server boundary
Add a backend route that receives only the opaque holdId, inspects the hold,
calculates the trusted order, and books using an immutable bookingRef.
Add platform surfaces only when needed
Platforms that let customers create venues need workspaces and
EmbeddedDesigner. Operator tools that change event inventory use
SeatManager with a short-lived manage session.
Add reconciliation
Use signed webhooks for downstream records and realtime inventory for open buyer and operator surfaces. Do not replace the synchronous checkout response with a webhook wait.
Common combinations
A commerce site with a normal checkout
Use SeatPicker or its React wrapper in the product page, then call your own
checkout endpoint from onCheckout. The server inspects and books the hold.
A highly customized ticketing application
Use SeatingChart for selection and explicit holds, your existing cart for
presentation, and the Server API for inventory and booking.
A no-bundler or CMS page
Use the hosted iframe only when direct booking without an external payment step is
the intended behavior. Add the documented postMessage helper for responsive
height and fullscreen. For a paid checkout, use the hosted script build of
SeatPicker instead; it does not require a bundler and exposes onCheckout.
A multi-tenant ticketing platform
Create workspace-scoped charts and events, embed the Designer with a short-lived
session, use a buyer surface for sales, and use SeatManager for box-office and
operator workflows.
An agent-assisted venue workflow
Use the Designer MCP only when an authorized coding agent needs to inspect a private reference and propose chart geometry. This surface is Preview and still requires deterministic validation and human review before publishing.
What not to combine
- Do not mount
SeatPickerandSeatingChartfor the same buyer interaction. - Do not expose a secret key because a browser integration needs more control.
- Do not use
SeatManageras a buyer picker; it grants operator capabilities. - Do not treat the iframe as less authoritative—the event inventory is identical.
- Do not use the current iframe for a paid flow that requires host checkout logic.
- Do not let an agent publish reference-derived geometry without review.
Selection checklist
- We chose the buyer surface based on UI ownership, not framework fashion.
- We know which backend route inspects and books the hold.
- The secret key exists only in a trusted environment.
- Platforms have an explicit workspace and short-lived session boundary.
- We have an intentional
409, expiry, and retry experience. - The next page for this integration is clear.
Continue with install the Buyer SDK, the platform integration guide, or the complete checkout example.