The Server API is the trusted control plane for inventory provisioning, hold inspection, booking, operational changes, reports, and webhook configuration. Call it from a backend or another environment where buyers cannot inspect your secret key.
If you have not yet separated inventory, audience access, pricing, and SDK choice, read the SeatLayer product model first. This landing page groups the same contracts by backend workflow.
Choose REST or a server SDK
| Surface | Choose it when | Start here |
|---|---|---|
| Official server SDK | Your backend uses Node.js, Python, PHP, Java, Go, Ruby, or .NET | Choose a server SDK |
| REST API | You want direct HTTP control or use another language | Authentication and OpenAPI 3.1 |
Both surfaces operate on the same public contracts. The operation support matrix records exact REST and server-SDK coverage without requiring narrative pages to duplicate it.
Find a workflow
Events and inventory
Create and update Events, manage inventory rules, and use blocks for operational holds.
Hold and book
Understand seat holds, inspect or create holds, then book inventory.
Sales channels and private access
Allocate one Event with the Sales Channels API and authorize an eligible browser with a Buyer Access Session.
Multi-event inventory
Coordinate one atomic run with the Performance Groups API, or publish renewable Plans and Seat Rights with the Seasons API.
Operations and reconciliation
Handle idempotency and conflicts, cancellations and box office, and reports.
Machine-readable contracts
- OpenAPI 3.1 describes public HTTP operations and schemas.
- Operation support JSON records REST and server-SDK implementation and release evidence.
- SDK catalog records current package, source, registry, documentation, and stability information.
Treat generated contracts as exact operation truth and these guides as workflow explanation. Keep secret keys server-side, use test-mode resources while integrating, and follow each mutation’s documented retry boundary.