Integration Checklist

Some pointers to avoid common problems when integrating into your ticketing system

Ben Verbeken avatar
Written by Ben Verbeken
Updated over a week ago

In this article we'll highlight some common issues and questions we encounter on a regular basis. You can use it as a checklist before your going live.

Do not hesitate to contact us in case of questions, these points are important!

☑️ Am I using a server-side SDK?

We provide server-side SDKs for all major languages out there via our GitHub page: PHP, python, java, .NET, ruby, JavaScript, etc. 

These SDKs cover all the functionality our API provides, so there really is no reason to consume the API using JSON over HTTP, even if it's technically possible.

And what's more, you'll get some major benefits for free:

  • Easier to use. Things like pagination and authentication are nicely abstracted away, giving you an idiomatic API to work with. 

  • Code completion in your IDE. you know what to expect even without consulting the documentation.

  • Exceptions if something unexpected happens. This will inform you, and in some cases enforce you, that some behaviors aren't properly handled but should. For example: a failed booking will lead to an exception that you can and should handle, instead of a simple 400 Bad Request response status code that you might forget to check.

  • Automatic exponential backoff. When you send too many concurrent requests, the server returns an error 429 - Too Many Requests. The SDKs all react to this by waiting for a while, and then retrying the request.

☑️ Do I take into account the Response?

This is an absolute must. Do not go into production unless you can check this box.

In your code, you handle both the success and failure cases for each and every call to the API. You should assume that any API call can fail.

Let's take booking a seat as an example.

Like any API call, a call to book some seats can always fail, for many reasons. Even if the ticket buyer selected the seat successfully.

If such a call fails, and your code does not handle that failure, it will register the booking as successful. However, in, the seat is not booked, and so the next ticket buyer will be able to select the seat again

In conclusion: you should only consider a seat as booked after the call to book it was successful, and you should handle any failures in your code.

The best and simplest way to do so is, of course, to use a server-side SDK for your integration. Doing so will force you to catch and handle the exception that is thrown when a call fails.

☑️ Am I double-checking seat statuses? (Don't!)

To know whether a book seats API call will succeed, you might be tempted to first check whether a seat is free via an API call, and only call the book API if that's the case.

That's not only unnecessary, it's also 

  • ineffective: it won't solve the problem you're trying to solve. 

  • harmful: doing a double check will give you a false sense of security, which ultimately may lead to double bookings. 

This article explains why in detail, but the gist of it is: the seat status might have changed in between the two API calls.

The only way to know for sure whether a seat can be booked, is by trying to book it. If that succeeds (200 OK response), then it is guaranteed to get booked. If it fails (anything else than 200 OK), then you're sure it has not been booked, due to been already booked or other reasons.

☑️ Am I exposing my secret key?

Anyone with access to your secret key is able to book seats, change seating charts, even create new events and users.

At the risk of stating the obvious, this means you should never call the API directly from within your ticket buyer code.

The only correct way to book seats, is to send the selected seats to your server, and book them from there.

Extra check list for high load on-sales

Of course, online ticketing is all about on-sale peaks and handling high load. When you add reserved seating to the mix, this makes matters worse: not only are lots of people trying to get into your event, they're also competing for the same few seats.

We recommend the following strategies to handle high peaks with reserved seating.

☑️ Again: be sure to use a client lib

The built-in exponential backoff mechanism will make sure that requests will be automatically retried, even in case you hit the API rate limit.

☑️ Use Best Available instead of choose-your-own seat

To have your system handle lots of ticket buyers, and handle them fast, the simplest way is to book the best available seats for each user, without offering the option to select their own seats. 

This will speed up the throughput of your funnel, and as a bonus, you'll be filling your venue in an optimal way.

Check the documentation for more information.

☑️ Don't use client side Best Available for high load on-sales

This paragraph is only relevant for long-time users (who signed up before 2020). Client-side Best Available is deprecated and not available anymore.

In, you can do best available seat selection in two ways: either via the client side bestAvailable configuration parameter, or via a book API call (

Always use the server-side calculation of best available seats when you expect a high load on-sale.

With the client-side best available seat algorithm, the calculation of which seat is "best" and "available" happens in the browser of the ticket buyer. This means, it will yield the same result for many concurrent users, when they try to determine the best available places at the same time.

Instead, you want to issue an API call to book the best available places - that calculation happens on the servers, and will yield a unique result for each and every ticket buyer.

☑️ If you do need to let people choose, queue them

Queuing systems are being used in ticketing systems everywhere; they're a well-known mitigation strategy to handle load, and to prevent the server from hitting technical capacity limits.

However, when reserved seating comes into play, it's not so much the technical capacity limit that will get hit first, but rather a functional one. Seats will become unavailable too quick, resulting in a frustrating experience for the ticket buyer as they try to snatch a seat for themselves too, sometimes failing to hold one due to someone else "getting it first".

Conclusion: if you do want people to choose their own places, queue them up in very small batches (e.g. per 100 or even less). Not because will crack under the load, but because you want to avoid frustrated ticket buyers as much as possible.


In this article, we've looked at a number of ways to check your integration.

Let's recap in the form of a checklist:

✓ Use a server-side SDK
✓ Don't assume API calls can only succeed
✓ Do not 'double check'
✓ Don't expose your secret key(s)

And if you're expecting high load on-sales, take these into account as well:

✓ Assign the best available seats instead of choose-your-own
✓ Make sure to use the server-side best available seat algorithm
✓ Queue your users in very small batches

Did this answer your question?