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 |
Make the next choice on the platform page
Each platform page owns the choices that only apply there:
- Web: the Web SDKs page compares the JavaScript, React,
Vue, and Angular packages and the ready-made
SeatPickeragainst the map-onlySeatingChart. - Native apps: the Native app SDKs page compares Flutter, React Native, iOS, and Android and the four levels of buyer UI you can own.
- Server: the Server SDKs page lists the seven languages and the booking contract they share.
- Several dates in one purchase: choose an Event, Performance Group, or Season first. The Client SDKs page shows which buyer component fits each model.
If you have not yet decided whether your product or SeatLayer owns checkout, start with Choose an integration.
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 REST API overview for the HTTP contract behind every SDK.