---
title: "Choose an integration"
description: "Match SeatLayer's buyer, server, designer, and operator surfaces to the experience you need to build."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.seatlayer.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Choose an integration

There is one inventory model and several ways to present it. Choose the smallest
surface that gives your product the control it actually needs.

> **The decision does not change the security model**
>
> Every buyer surface creates a temporary hold. Your trusted server inspects that
> hold, runs your order and payment logic, and books with a secret key.

## 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

1. **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.
2. **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`.
3. **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.
4. **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 `SeatPicker` and `SeatingChart` for the same buyer interaction.
- Do not expose a secret key because a browser integration needs more control.
- Do not use `SeatManager` as 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](/buyer-sdk/install), the
[platform integration guide](/integrations/platforms), or the
[complete checkout example](/examples/complete-checkout).

Source: https://docs.seatlayer.io/start/choose-an-integration/index.mdx