Choosing an API Mode
Our API is available in several modes. For the vast majority of integrations, the choice comes down to two: Web mode and System Owner mode.
This page is a decision guide. It explains what each mode is for, the two scenarios that genuinely justify System Owner mode, and the misconceptions that most often lead partners to pick the wrong one.
Web mode is the standard option. Start there. Only move to System Owner mode if you hit one of the two scenarios described in When System Owner mode is justified.
The two modes at a glance
| Web mode | System Owner mode | |
|---|---|---|
| Where calls are made | Client side or server side | Server side |
| Authentication | None required | Signed request per call using a client-specific API key |
| Acts as | A single web customer, one session at a time | The client organisation, with full system access |
| Data exposed | Public information, mirroring what's available via the iframes | The entire system, including sensitive customer data |
| Infrastructure you run | Static site or CDN. No servers required | Web servers you must secure, scale and monitor |
| Spektrix managed components | Iframes, Web Components, Spektrix Payments components, magic link authentication | Not available |
| Queuing | Supported | Not currently supported |
| Typical use | Client websites, custom booking journeys, listings | EPOS, kiosks, streaming platforms, back-office sync, multi-system SaaS front-ends |
When System Owner mode is justified
There are two scenarios where System Owner mode is the right answer.
You're building a multi-system platform
You're building a SaaS product with a front-end that is deliberately system-agnostic. It sits on top of a translation layer that plugs into Spektrix and other ticketing products, and presents one consistent experience regardless of which ticketing system sits behind it.
In this case a server-side integration is unavoidable: your translation layer is the thing talking to Spektrix, not the customer's browser.
You need restricted actions
You need to perform operations that a standard web customer cannot, for example:
- Overriding tickets
- Applying custom refund rules
- Issuing or redeeming single-use promo codes
- "Pay what you can" and other override flows
These actions are, by design, not exposed to Web mode. If your product genuinely depends on them, you need System Owner mode.
If your integration only needs some of these actions, you don't have to build the whole thing in System Owner mode. Modes can be mixed: use Web mode for the customer-facing journey and a small server-side System Owner component for the restricted operations only. This keeps your security scope as small as possible.
Common misconceptions
Most partners who choose System Owner mode do so for one of the reasons below. None of them require it.
"To build a completely custom, frameless front-end, I need System Owner mode"
You don't. Web mode supports fully custom, frameless booking journeys. You can search and display events, build and amend baskets, manage customer records and take payment — all client side, without embedding a single iframe.
See Adding items to a basket, Custom baskets and Custom checkouts.
"Complex multi-client deployments require System Owner mode"
They don't. Web mode is designed for exactly this. Each Spektrix client has their own system identified by a unique client name, and our API is consistent across all of them, so a single Web mode codebase can serve many clients. Point the requests at the right client name (or their custom domain) and the same front-end works everywhere.
"Server-side calls are more secure"
For public data, the opposite is true. System Owner mode requires you to hold an API key that grants full access to a client's system, including sensitive customer data. Web mode has no key to leak.
In the past it was possible to make some Web mode calls server side. Due to updated security policies these requests are likely to be automatically blocked. See Creating a customer record for details.
Why Web mode is the recommended path
Scalability. A Web mode integration is a static architecture that sits behind a CDN such as Cloudflare. Spektrix handles all the dynamic API content, so you have no web servers to scale when an on-sale hits.
Cost. Serverless and static hosting absorbs any traffic volume for a fraction of the cost of running and scaling your own infrastructure. You can deliver a highly efficient experience more cheaply.
Security. Your security scope shrinks dramatically. There's no API key to protect, no server to harden and patch, and no data exfiltration risk from a compromised credential.
Access to managed components. Web mode integrations can use Spektrix iframes, Web Components, the Spektrix Payments components and magic link authentication — plus any managed components we release in future. You get the benefit of ongoing Spektrix development without changing your code.
Queuing. Queuing is supported in Web mode today. Customers are placed in a queue during high-demand on-sales and your integration handles the queue responses. System Owner mode does not currently support queuing.
What you take on with System Owner mode
If one of the two scenarios above applies to you, be clear about what you're signing up for.
- You manage and scale your own server infrastructure. On-sale traffic is solely your responsibility, not ours. If your servers fall over during an on-sale, the client's sale fails.
- You are responsible for API key security. The key grants access to the client's full system. A compromised key is a data exfiltration vector, so it must never reach the browser and must be stored, rotated and audited accordingly. See Authentication.
- You handle payment flows independently. Note that processing card payments via the API is only possible for clients using Spektrix Payments. Otherwise you'll need to record transactions using Custom Payments.
- You cannot use Spektrix managed components or built-in iframes. Everything customer-facing is yours to build and maintain.
- It costs more to deliver. Building and running the equivalent experience takes more development time, more infrastructure and more ongoing operational effort.
Still not sure?
Read the rest of the API documentation before committing to a mode — in particular the API overview, Authentication and the endpoint pages for the functionality you need, which set out which modes each endpoint supports. Reach out to us if you have any questions.