Spektrix Connect

Early Access

This functionality is available under early access. Its behavior or response format may change before general availability and it may require additional configuration by the Spektrix team to access it. Contact us if you plan to use it in a production integration.

Spektrix Connect lets a Spektrix client sell tickets for events that are held in another ticketing system. The client's box office staff and website customers choose seats in Spektrix as normal. Behind the scenes, every seat is held and sold in the other system, which stays the single source of truth for availability, prices and barcodes.

Spektrix doesn't talk to the other ticketing system directly. Instead, it talks to an HTTP Connector: a small web service that you build and host. The connector implements the Spektrix Connect interface as a fixed set of HTTP endpoints, and translates each call into whatever the other system's API needs.

This section is for developers who are building a connector.

Key terms

Term	Meaning
Agent	The Spektrix client selling the tickets. Their Spektrix system is the "agent" system.
Source system	The third-party ticketing system that owns the events, seats and prices. Spektrix uses this name for any system it imports inventory from.
Agency API	The API the source system exposes so that other parties (agents) can sell its tickets. Every ticketing system's agency API is different.
HTTP Connector	The web service you build. It exposes the Spektrix Connect endpoints to Spektrix and calls the source system's agency API to fulfil them.

How it fits together

The connector sits between Spektrix and the source system. Spektrix only knows the Spektrix Connect contract, and the source system only knows its own agency API. The connector is the only part that knows both.

Every request follows the same pattern:

1. Something happens in Spektrix. For example, a customer selects a seat on an imported event.
2. Spektrix calls the matching Spektrix Connect endpoint on your connector. In this example, that's add reserved tickets.
3. Your connector translates the request into one or more calls to the source system's agency API, such as "hold seat A1 in this cart".
4. Your connector translates the source system's response back into the Spektrix Connect format, and returns it to Spektrix.

Example: selecting a seat

The diagram below shows what happens when a customer selects a seat on an event that has been imported from a source system.

If the seat has been taken in the source system in the meantime, your connector returns a tickets unavailable error. Spektrix then tells the customer the seat is no longer available.

The lifecycle of a connection

1. Connect. The Spektrix client adds your connector as a source system, entering its base URL and the credential Spektrix should send it. See Authentication and setup.
2. Import. Staff run an import. Spektrix calls the catalogue and seating plan endpoints to copy the source system's events, instances (performances), venues and seating plans. Imports can be re-run to pick up new, moved and cancelled instances.
3. Map. Staff match the source system's ticket types, price bands and seat allocations to their own Spektrix equivalents. Spektrix uses these mappings to translate each sale in both directions.
4. Sell. When a seating plan is shown or a ticket is added, changed or removed, Spektrix calls the availability and basket endpoints. Availability and prices are always read live from the source system, never from the import.
5. Confirm. When the customer pays, Spektrix sends the customer details and confirms the basket. The source system creates the order and returns a barcode for each ticket. Spektrix prints those barcodes on its tickets so they scan at the source system's venue.

What Spektrix stores and what it doesn't

Spektrix keeps a copy of the structure it imports: events, instances, venues and seating plans, along with the connector's ids for each. It doesn't keep a copy of availability or prices. These are read from your connector every time they're needed, so the source system stays in control.

All ids are owned by your connector. Spektrix stores them and sends them back to you unchanged, so they must stay stable over time.

Next steps

• Authentication and setup: the two sets of credentials involved, and how the connection is configured in Spektrix.
• Building a connector: the rules every endpoint follows, error handling, timeouts and an example.
• Endpoint reference: every endpoint your connector must implement, with request and response examples.