Overview
The Spektrix Queue
Spektrix has queueing built in, providing customers with live updates on their position and - critically - moving them securely from website to purchase pathway, with no risk of losing their place in line.
Once an event is on sale and the queue enabled, customers will enter a queue prior to reaching the purchase flow. This applies whether the integration uses the ChooseSeats.aspx iframe or the API to add tickets to the basket. As customers at the front of the queue place their orders, more customers will be allowed to select seats.
Things to remember with the queue:
- There is only one queue per client - all events that have queueing enabled are diverted through this one queue. If there are any events that do not have queueing enabled, customers purchasing for these events are unaffected.
- Customers only queue once. When they reach the front of the queue they are able to purchase tickets for all events and instances that have queueing enabled without having to re-queue. If they confirm a transaction and visit the purchase path again, they go to the back of the queue.
- Customers with items in their basket prior to joining the queue will be asked whether they want to checkout and confirm these items, or empty their basket. If entering the queue is dependent upon these items (e.g. a priority booking period activated by a membership) then the same options still apply. Customers must have empty baskets before entering the queue.
Implementation Paths
| Feature | Iframe Integration (ChooseSeats.aspx) | API Integration |
|---|---|---|
| Activation | Automatic once the queue is enabled for an event. | Requires manual handling of specific error codes. |
| User Interface | Spektrix provides the progress bar and position updates. | You must build a custom UI to display queue position and countdowns. |
| Polling | Handled automatically by the iframe. | Handled by your application (typically every 10 seconds). |
Queueing and the chooseats.aspx iframe
The queueing page kicks in automatically prior to customers seeing the ChooseSeats.aspx iframe. It is made up of four elements, shown below:
- Custom Message for Customers in the Queue: This message is set by the Spektrix team, so the client can get in touch with Spektrix if they wish to update it. Good advice is to include a message explaining why a queue is being used, what the customer can do once they reach the front of the queue, and that they will be automatically redirected without refreshing the page.
- Progress Bar: The progress bar will show the customer’s progress as they wait in the queue. The closer to the right hand side the bar, the closer to the front of the queue the customer is.
- Position in the Queue: The customer’s position in the queue, and also the estimated waiting time, if enabled. This number will decrease as customers reach the front of the queue (we do not display the length of the queue).
- Next Update: A countdown to the next update to the queueing page. It is usually 10 secs and set by the Spektrix team who are monitoring the onsale. Once the customer reaches the front of the queue the page needs to update before Choose Seats is displayed.
The queueing page inherits the CSS styling uploaded to the Spektrix system, although web developers can change the styling should tweaks be needed.
You can view the queueing iframe without switching the queue on, just go to:
https://<customdomain>/<clientname>/website/QueueingPage.aspx?testing=true
Additional Customer Communication
The message displayed above the progress bar can be changed by the Spektrix team as an onsale progresses, to reflect new information the customer might need (for example, that the event is sold out, selling out or there is a problem). The system checks for any changes to the message at the end of each polling period, and displays the changes automatically. It is also possible to have a custom message to display when a customer arrives at a sold out instance via the queue. This might instruct them to select another instance, or apologise for their disappointment.
Queueing and the Spektrix API
When queuing is triggered, the API intercepts attempts to add tickets to a basket via POST v3/basket/tickets requests, returning specific HTTP status codes—primarily 403 (Must Join Queue) and 429 (Must Wait).
Unlike the standard Spektrix iframe, which handles the queue UI and polling automatically, the API implementation requires the developer to catch these errors, call a dedicated POST /basket/queue endpoint to join the line, and implement a polling loop (typically every 10 seconds) to check the user's progress. This architecture allows you to maintain the integrity of the sale while providing a fully customized, brand-aligned waiting experience for your users.
See for guidance on how to handle the queue if you are using the API to add tickets to the basket.
Website Performance & Caching
Spektrix manages the complex logic of the purchase path and keeps pace with online demand effectively.
As the web developer, you are responsible for the performance of the website.
Leveraging CDNs for Optimal Performance
To ensure your website performs seamlessly during peak traffic times like ticket onsales, utilizing a Content Delivery Network (CDN) is highly recommended. CDNs cache your website's static content, so the use of a CDN on top of providing benefits under heavy load (onsale), also improves the customer experience under normal traffic patterns by reducing significantly page response times.
Since Spektrix handles most dynamic content related to customer transactions (via iframes or our client-side API), you can focus on optimizing the delivery of your static content for maximum performance.
Caching Strategies for Dynamic Elements
While CDNs excel at caching static content, certain elements on your website (outside of the Spektrix iframes/web components) might need to change dynamically during an onsale. This could include call-to-action buttons that transition through states like "On sale at x," "Priority Booking Open," "Book now," "Limited Availability," and "Sold out."
To handle these dynamic elements effectively, consider the following strategies:
- Dynamic Content within Static Pages: Fetch dynamic elements (like button states) using calls to a lightweight service on your end. This service can periodically retrieve the latest status from Spektrix server-side (e.g., every 10 minutes) and provide it to your webpage. This allows you to update specific sections of your page without requiring a full cache purge or making frequent calls to Spektrix from the browser.
- Strategic Cache Purging: Purge your CDN cache at key moments, such as the exact onsale time. This ensures customers receive the most up-to-date information. However, be mindful of potential issues associated with cache purging, such as temporary inconsistencies or increased traffic to your server while caches are rebuilt. Whenever possible it’s recommended to only purge individual items (such as specific images or javascript files) to avoid triggering unnecessary requests to your website for assets that haven’t changed.
- Prevent Caching of Dynamic Content: Ensure that pages containing customer- or transaction-specific information are not cached and served to other customers. This prevents accidental data leakage and ensures each customer sees the correct information.
- Use a combination of CDN caching and browser caching: Make sure that for all static assets, including JavaScript, CSS, images and HTML where possible you set the correct cache-control header with a max-age value appropriate to the item to control its expiration. This allows both browsers and CDNs to keep objects in cache for as long as possible whilst reducing the risk of serving stale data. Caching in the browser also reduces the need for unnecessary requests improving the customer experience.