---
title: "Choose an integration"
description: "Choose who owns commerce first, then select the buyer and staff surfaces that belong to that product."
---

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

<CardGrid>
  <Card title="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.
  </Card>
  <Card title="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.
  </Card>
</CardGrid>

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.

<Aside type="caution" title="Managed commerce for platform tenants is not a current product">
  One marketplace account cannot silently turn thousands of workspace tenants
  into separate SeatLayer merchants. Workspace-scoped gateways, permissions,
  sites, and commercial ownership require a separate product contract.
</Aside>

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

<FlowDiagram
  label="Platform SDK infrastructure purchase flow"
  steps={[
    {
      actor: "Your CMS",
      title: "Provisions seating inventory",
      detail: "Your product creates the workspace, chart, and inventory Event for the commercial event it already owns.",
      tone: "platform",
    },
    {
      actor: "Buyer SDK",
      title: "Selects and holds",
      detail: "The buyer chooses inventory and receives a temporary opaque hold identity.",
      tone: "seatlayer",
    },
    {
      actor: "Your backend",
      title: "Inspects the hold",
      detail: "It reads the authoritative hold before calculating the order or deciding payment.",
      tone: "platform",
    },
    {
      actor: "Your commerce system",
      title: "Creates the commercial order",
      detail: "Your product applies its own customer, payment, tax, and refund rules.",
      tone: "payment",
    },
    {
      actor: "Your backend",
      title: "Books with bookingRef",
      detail: "The stable commercial order ID is used to make inventory booking safe to retry.",
      tone: "platform",
    },
    {
      actor: "SeatLayer",
      title: "Commits and notifies",
      detail: "SeatLayer commits inventory atomically and emits signed inventory events for reconciliation.",
      tone: "seatlayer",
    },
    {
      actor: "Your commerce system",
      title: "Delivers tickets",
      detail: "Your existing product confirms the order and provides tickets, support, and fulfilment.",
      tone: "outcome",
    },
  ]}
/>

### 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 `SeatManager` as 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_checkout`
      enabled 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](/integrations/platforms), the
[ticketing backend flow](/integrations/ticketing-backend), or the
[booking endpoint](/server-api/booking).