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.
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 Managed 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 Managed Ticketing as a direct organizer
- Request Managed Ticketing access and wait for staff approval.
- Confirm Hosted Checkout (
hosted_checkout) is enabled for the organization. - Create a Managed Event and connect the organizer’s eligible payment account.
- 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.