# Reserved seating SDK for ticketing platforms.

One workspace per organizer. Their charts and events live inside your product; your checkout, payments, tickets and customer records do not move.

[Explore live demos](https://app.seatlayer.io/demo/)

[Read the platform guide](https://docs.seatlayer.io/integrations/platforms/)

One isolated workspace per organizer; their charts and events inherit it. Your ids travel as externalRef.

For public sale, the SDK receives chart and inventory directly from SeatLayer, then hands one temporary hold to your application. Your backend is not in the chart-load path.

Your backend rechecks the hold, takes payment, and confirms the sale. Account secrets never reach the buyer browser; one webhook endpoint hears every organizer.

## Reserved seating for multi-organizer platforms.

Your model maps onto SeatLayer's in one table. workspaceId is the enforced isolation boundary; externalRef carries your ids back to you.

| Your product | SeatLayer |
| --- | --- |
| Venue / layout | Reusable chart |
| Performance, departure or timed session | Event with independent inventory |
| Tenant, organizer or customer account | Workspace |
| Cart reservation | Hold |
| Inventory committed for a paid order | Inventory booking |
| Your stable resource id | externalRef |

### Workspace isolation

Charts and events are workspace-scoped; API keys, webhook endpoints, team membership, and billing remain organization-wide.

### Designer and operator sessions

Short-lived, origin-bound sessions open the Designer in your CMS (dse_) or the live seat board in your admin (mse_) — never an account secret.

### One event authority

Buyer holds, bookings, blocks, releases, box office, and [audience allocations](https://seatlayer.io/sales-channels/) operate on the same live seat state.

### One endpoint, every organizer

Verify the HMAC signature, route by the stored event id, check the workspace matches your record, and process each occurrenceId once across retries.

Switching vendors? [Import a chart that is already public](https://seatlayer.io/seats-io-alternative/) and keep the organizer selling. Building counter sales too? [Review the reserved-seating Box Office workflow](https://seatlayer.io/box-office/).

## Your ticketing product stays authoritative.

This integration path adds reserved seating without moving your buyers, money, orders, or support workflow into a second ticketing system.

### Commerce and the customer lifecycle

- Organizer accounts, roles, catalog, and event merchandising
- Cart, checkout, payment, tax, orders, and refunds
- Ticket generation, delivery, scanning, and customer records

### Reserved-seat geometry and inventory

- Embedded Designer sessions and published chart versions
- Buyer SeatPicker, optional 3D, holds, blocks, and releases
- Server-confirmed booking, live deltas, and signed webhooks

Platform/SDK billing is one organization-wide credit pool: 100 free SDK seat credits every month, then prepaid credits from 10¢ down to 5¢ per confirmed sold seat, never expiring, no subscription — [sold-seat pricing](https://seatlayer.io/pricing/). White-label add-ons are priced separately. Review the [security guide](https://seatlayer.io/security/) before moving from test to live mode.

The same platform can add [chart-derived 3D](https://seatlayer.io/3d-seat-map/), compose native buyer controls around the shared map through the [mobile SDKs](https://docs.seatlayer.io/buyer-sdk/mobile/), and opt a compatible browser into [buyer WebMCP](https://docs.seatlayer.io/buyer-sdk/webmcp-agent-tools/) for event lookup, seat finding and visible selection. Buyer tools do not expose checkout or payment; your trusted server still inspects the hold and confirms booking.

## How to integrate a seat map into your ticketing platform

Six calls, two of them in the browser. Steps 04–06 are the same buyer flow the [seat map SDK integration guide](https://seatlayer.io/developers/) walks through in code.

### Provision a workspace

Scope the organizer's charts and events to a workspace. API keys, webhook endpoints, team membership, and billing remain organization-wide.

### Design inside your CMS

Open the Designer with a short-lived session restricted to the workspace, chart, parent origin, and allowed actions.

### Publish and create the event

Publish a chart version and create the reserved-seating event in test or live mode.

### Select and hold exact seats

SeatPicker uses {event, publicKey} to bootstrap public sale directly, creates a temporary hold and follows live seat changes. Private audiences replace publicKey with a backend-backed token provider.

### Inspect, pay, then book

Read current hold status, mode, expiry, and line items before payment. Confirm with a stable bookingRef.

### Verify and reconcile

One endpoint for every organizer: verify each webhook signature, route by workspace, and process its stable occurrence identifier once across retries.

[Open the complete platform integration guide →](https://docs.seatlayer.io/integrations/platforms/)

## Questions teams ask before they embed.

### Does SeatLayer replace our ticketing platform?

Not in this integration path. Your platform keeps organizer accounts, event catalog, checkout, payment, tax, orders, refunds, ticket issuing, scanning, and customer records. SeatLayer supplies the reserved-seating surfaces and live seat inventory inside your product.

### Can organizers create seating charts inside our platform?

Yes. Embed the Designer in your organizer CMS with a short-lived session restricted to one workspace, chart, parent origin, and permission set. No SeatLayer account secret reaches the browser.

### How do we map our tenants to SeatLayer?

One workspace per tenant, organizer or customer account, created when you provision them; charts and events inherit the workspace. Keep your own ids on every object as externalRef for reconciliation. Workspace is the enforced isolation boundary; externalRef is never used as authorization.

### Can we import an organizer's existing seating chart?

Yes. A chart that is already public on another system can be imported into the organizer's workspace, reviewed in the Designer, and published — so a switching organizer keeps selling.

### What can be white-labeled?

The organizer Designer and buyer SeatPicker sit inside your product; white-label presentation is a priced add-on. Your platform remains the surrounding experience and owns the customer relationship.

### How do SeatLayer holds work with our checkout?

SeatPicker gives your application a hold ID. Your trusted server reads the current hold status, mode, expiry, and server-authoritative line items before taking payment, then confirms the seats with a stable booking reference.

### Can we test the integration before going live?

Yes. Test keys let you create sandbox events, holds, bookings, and webhooks with no sold-seat credit usage. Switch to live keys only when your workflow is ready.

## Bring us your tenancy model.

Try the released buyer flow, then bring us your tenancy, checkout, or migration questions when an architecture conversation is useful.

[Open the ticketing platform demos](https://app.seatlayer.io/demo/)

[Discuss your platform architecture](mailto:hello@seatlayer.io?subject=SeatLayer%20platform%20architecture)

---

_Machine-readable site index: [/llms.txt](https://seatlayer.io/llms.txt) · full corpus: [/llms-full.txt](https://seatlayer.io/llms-full.txt)_
_Source page: [https://seatlayer.io/ticketing-platforms/](https://seatlayer.io/ticketing-platforms/) · Questions: [Contact SeatLayer](https://seatlayer.io/contact/) · hello@seatlayer.io_