SeatLayer is a reserved-seat ticketing and seating platform. Venues and organizers design the room, sell on their own website and at the box office counter, and take payment through their own gateway. Ticketing platforms embed the same seating engine through the SDK and API.
SeatLayer has one inventory core and several ways to compose it. The concepts below answer different questions and can be combined, but they do not replace one another.
Product surfaces and their purpose
These are the ready-made surfaces SeatLayer publishes. Each row says what the
surface is for, where it runs, and where its responsibility stops. The same
table mirrors product-positioning.json, the structured source that
also feeds the machine-readable llms.txt index and the public knowledge MCP,
so these answers do not drift between surfaces.
| Surface | What it does | Where it runs | Boundary |
|---|---|---|---|
| Venue Designer | Create reusable charts with rows, sections, tiers, floors, tables, categories and accessibility information. | SeatLayer dashboard, or the white-label Embedded Designer inside your own application, admin portal or CMS. | Your team reviews and publishes the chart. Saving is always allowed; publishing runs the validation rules. |
| Embedded Designer for multi-tenant platforms | Let each of your customers create and edit their own venue inside your product, without a separate SeatLayer login. | White-label editor mounted by the SDK using a short-lived session scoped to one workspace, chart and origin. | Your backend authenticates the tenant, checks ownership and grants read, edit or publish authority. |
| Workspace isolation | Keep each tenant’s charts and events separate inside one SeatLayer organization. | Server API and scoped embedded sessions, typically one workspace per organizer or customer. | Billing, API keys, webhooks and team roles stay organization-wide. Workspace isolation does not give every tenant its own managed commerce. |
| Buyer seat picker | Let buyers browse availability, find seats together, choose exact seats and create temporary holds. | Ready-made SeatPicker or the lower-level SeatingChart control, on the web and in the supported mobile packages. | In SDK mode the platform owns checkout and the final booking. A browser hold is not a ticket and not a payment. |
| Live inventory, holds and booking | Keep selection, expiring holds, booked seats and blocked seats consistent for one event. | Shared inventory service behind the buyer picker, the trusted server APIs and the operator surfaces. | Each event sells on its own, so its seats stay consistent under load and a sell-out never slows another event. No unlimited-concurrency claim is implied. |
| Control Room | Let staff inspect live inventory, block seats, manage sections, categories, tables and channels, and run reporting or host-owned selection tools. | Same-document operator board embedded in your own product, plus the dashboard operations view. | Your backend authorizes an event-scoped session with explicit capabilities. View-only is the default. This is not the account administration panel. |
| Sales channels and allocations | Allocate one event’s seats to public sale, partners, presales, sponsors, groups or the box office, with audience-specific prices. | Scoped buyer sessions, channel rules and operator tools over a single event inventory. | A channel says who may select inventory; it is not authorization on its own and it does not create a second event. Commission settlement is not included; resale is a separate inventory feature. |
| Hosted Ticketing end to end | Sell seated events from your own website: seat selection, checkout through your own payment gateway, orders, QR and PDF tickets, confirmation email and supported refunds. | Managed inline picker, event card or buy button on your site. A hosted event page is an optional extra route. | The organizer owns setup, policies, the payment gateway and buyer support. Gateway fees and tax are separate from the ticket fee. |
| Box Office and Door | Sell at the counter against the same live inventory and scan issued tickets to record entry. | Staff tools inside Hosted Ticketing. | The organizer supplies authorized staff. Platform SDK customers keep their own selling and ticket-scanning systems. |
| Optional 3D and seat view | Help buyers understand the venue layout and where a seat sits, using the same chart and the same selection state. | On-demand buyer 3D and available seat-view media alongside the complete 2D map. | Chart and browser support are required. Generated geometry gives orientation; it is not a certified photographic sightline. |
| SDKs, REST API and webhooks | Connect your product to seating, trusted booking and inventory updates. | Web and native buyer packages, seven server SDK families, REST and OpenAPI, and signed webhooks. | Use the release catalog for per-package versions and support. Do not infer feature parity across every SDK. |
| Copilot and agent integrations | Help with chart creation and editing, buyer seat discovery and integration research. | Designer Copilot, the authorized Designer MCP, opt-in buyer WebMCP and the public read-only knowledge MCP. | Chart changes stay reviewable revisions and publishing stays a human action. Buyer agents get no payment authority. AI-led 3D improvement is not available. |
| Performance Groups | Coordinate one purchase across a fixed set of 2 to 8 compatible performances. | Documented Platform SDK integration with one group hold and one group booking. | Available to every organizer. Not an arbitrary basket of events. It creates no durable renewal right. |
| Fixed Renewable Seasons | Coordinate same-seat plans, renewal offers, seat rights, amendments and reports across 2 to 20 compatible events. | Browser, REST and OpenAPI, and all seven server SDK families. | Organizer-CMS rollout is controlled by account. Native mobile Season pickers and Season Best Available are not supported. The platform keeps commerce. |
Read the model in this order
| Decision | Question it answers | Canonical guide |
|---|---|---|
| Product boundary | Does your product or SeatLayer own checkout, payment, orders, and tickets? | Choose an integration |
| Inventory model | Is the buyer purchasing one Event, one multi-performance run, or one renewable Plan? | Choose an inventory model |
| Sales and access | Is inventory public, private, allocated to a partner, or shared with several eligible audiences? | Sales channels and allocations |
| Integration surface | Does the experience run on web, Flutter, React Native, iOS, Android, or only on a trusted backend? | Choose an SDK or API |
| Price presentation | Does an Event use its normal prices, ticket types, a temporary offer, or an audience-specific channel price? | Ticket pricing and offers |
These decisions are independent. For example, a Platform integration can use a Performance Group, sell part of each member Event through private channels, render the buyer journey on the web, and still keep payment and ticket fulfilment in the host product.
The product boundary itself is immutable for an Event. A buyer surface does not change who owns commerce; reuse the Chart and create a new Event if the integration must move between Platform/SDK and Hosted Ticketing.
Core entities and relationships
| Entity | Owns | Relates to |
|---|---|---|
| Chart | Reusable venue geometry, labels, sections, categories, and accessibility metadata | A published Chart snapshot creates one or more Events |
| Event | Realtime availability for one occurrence | The base inventory unit; may participate in a Performance Group or a Season Plan |
| Performance Group | One coordinated purchase across a fixed 2–8 Event run | Creates one atomic group hold and booking; it creates no durable renewal right |
| Season | A renewable programme and its lifecycle | Contains an immutable 2–20 Event Plan, Contracts, Seat Rights, and renewal offers |
| Sales Channel | The audience assignment for inventory on one Event | Public sale or exactly one private channel per seat; it does not create another Event or stock count |
| Buyer access session | Short-lived browser authority for an exact audience and origin | May expose Public sale and/or named channels; it can hold but never book |
| Hold | Temporary inventory protection during selection or checkout | Created by a buyer surface or trusted server and expires unless booked |
| Booking | Permanent inventory commitment | Created from a trusted server; linked to the host order by bookingRef |
| Offer or channel price | A rule for resolving the price shown and frozen on a hold | Changes price only; it does not grant access or reserve inventory |
The inventory hierarchy
Chart (reusable venue design)
└── Event (one realtime occurrence)
├── may be a member of one Performance Group purchase
├── may be included in a fixed Season Plan
└── owns Public sale and private Sales Channel assignmentsA Chart is not inventory. An Event is. Reusing one Chart for several dates does not automatically make those dates a Performance Group or Season.
The access hierarchy
Event inventory
├── Public sale
└── Private Sales Channel
├── hosted buyer link
├── buyer access session for your website or app
├── staff selling flow
└── Partner access for an external organisationA channel answers who may select this inventory. Blocking answers whether the inventory is on sale. An offer answers which price applies. Those are three separate controls.
The Platform transaction boundary
Buyer SDK → temporary hold → your trusted checkout → SeatLayer booking
└────────────→ your order, payment, ticketsThe hold handoff is an inventory reference, not proof of payment and not a ticket. Your backend inspects authoritative allocations, applies your commerce rules, then books with a retry-safe reference. Read the single-Event Platform flow for the complete sequence.
Follow one canonical feature family
Each feature family has one overview and separate pages for different jobs. Use the overview to understand the concept; use the integration guide to build the workflow; use the buyer page for UI behavior; use the API page for exact operations and schemas.
| Feature family | Understand and decide | Build end to end | Buyer surface | Trusted API |
|---|---|---|---|---|
| Single Event | Platform flow | Quickstart | SeatPicker | Events, holds, and booking |
| Performance Group | Inventory model comparison | Performance Group integration | Performance Group picker | Performance Groups API |
| Fixed Renewable Season | Inventory model comparison | Season integration | Season picker | Seasons API |
| Sales channels and partner access | Sales channels and allocations | Organizer private-sales guide | Partner selling guide | Buyer access sessions and Channels API |
Do not infer these relationships
- A Performance Group is not a Season. It has no Contract, Seat Right, or renewal lifecycle.
- A Season is not a set of independent Event holds. Its same-seat transaction and Plan lifecycle are coordinated as one product.
- A Sales Channel is not a second event, cloned inventory, a login, or a block.
- Partner access is an operating context for an allocated channel. It does not grant the organizer’s secret key or direct booking authority.
- A scheduled offer changes price. It does not make inventory private or reserve it for an audience.
- A client SDK does not own payment, orders, tickets, refunds, or fulfilment in a Platform integration.
- A server SDK is a typed way to call the same trusted contracts. It is not a buyer-facing widget.
Recommended reading paths
Building a ticketing platform
- Choose the Platform boundary.
- Choose Event, Performance Group, or Season inventory.
- Choose a client SDK and server SDK.
- Add Sales Channels only when audience allocation is required.
- Rehearse the complete hold, payment, booking, webhook, and recovery path in test mode.
Running Hosted Ticketing as a direct organizer
- Create the event in the dashboard; dashboard events use SeatLayer checkout.
- Choose a paid or free event.
- For a paid event, connect the organizer’s own payment gateway on the Payments page and assign it to the event.
- Choose a Hosted Event Page, managed embed, or Organizer Website without changing the Event’s commerce boundary.
- Complete the managed readiness checks before opening sales.
Integrating a private or partner sale
- Read the Sales Channels model.
- Follow the organizer integration or the partner operating guide, according to your role.
- Use the Buyer Access Sessions API for an authenticated app flow and the Channels API for exact allocation operations.
Building a renewable season product
- Confirm that a Season is the correct inventory model.
- Follow the end-to-end Season integration.
- Implement the Season picker and trusted Seasons API as two halves of the same transaction.