Choose the surface that matches where your code runs and how much of the buyer experience your product should own. Client SDKs select and hold inventory; trusted server code inspects the hold and confirms booking.
Choose by runtime
| Your code runs in | Start here | Best when |
|---|---|---|
| Browser or web framework | Web SDKs | JavaScript, TypeScript, React, Vue, or Angular owns the buyer page |
| Native mobile application | Native app SDKs | Flutter, React Native, Swift, or Kotlin owns the app screen |
| Trusted application server | Server SDKs | You want an idiomatic client for Node.js, Python, PHP, Java, Go, Ruby, or .NET |
| Any HTTPS-capable backend | REST API and OpenAPI | You want direct HTTP control or generated clients for another language |
Choose the client control level
Use the complete buyer flow
Start with SeatPicker. SeatLayer supplies the
selection experience and returns an opaque hold to your checkout.
Build a custom web cart
Use SeatingChart when your application owns
the cart, controls holds explicitly, or needs a non-standard layout.
Build a native app experience
Compare the native app SDKs before choosing a drop-in picker, composable native widgets, or the lower-level map surface.
Model multiple performances
Choose an Event, Performance Group, or Season before selecting the corresponding buyer and server APIs.
Keep the trust boundary fixed
The browser or mobile app may select inventory, create a temporary hold, and
send its opaque holdId to your backend. Only trusted server code should hold a
secret key, inspect authoritative hold contents, calculate the charge, and book
with a stable bookingRef.
Continue with the client SDK overview, the server SDK overview, or the REST API overview.