Heads-up: this article can contain traces of technical terms. 

Ensuring a seat is exclusively reserved for one ticket holder is, of course, key.

We're happy to let you know that the seats.io system itself has been has been double-booking free from the start. That's because the API call to change a status is transactional, and we don't just prevent double bookings in our code, but at the database level: booking the same seat twice in the seats.io database is not just unlikely, but physically impossible on our platform.

However, double booking issues might still arise, typically related to the way seats.io is integrated into the ticketing system.

If you are seeing double bookings in your system, it's likely because of one of two reasons:

Let's dive into detail.

Like any API call, an API call to book a seat (or, more generally, changing its status) can either return a 2xx successful response, or it can fail (typically with a 4xx response).

Imagine for instance that Alice chooses a seat A-1, thinking it's free, not realising it's been booked by Bob. This could happen because Alice's poor internet connection prevented her from receiving the live update that the seat was already taken. If Alice continues the booking process, at some point the ticketing system will do an API call to book A-1, and seats.io will respond with a 400 Bad Request response, stating that the seat cannot be booked because it is not free.

This is just one example, there are many others. But the point is that, in general, you cannot assume that API calls will always succeed, even if the user was able to select a seat in their browser. And so that you should handle the possibility of a failed request.

Luckily, that's easy: use one of our server-side SDKs. They're available on our github for e.g. PHP, Java, .NET, python, ruby, go, node, etc).

If you do, then you'll be calling methods instead of issuing raw http calls. Those methods are designed to throw an exception when a booking call fails, so you don't have to check status codes. Just be sure to handle the possible exception.

We don't see any good reason to not use one of those server-side SDKs. But, even if you like pain and decide to construct your own json objects to send them over the wire using your own http client, you'll still need to handle possible failed requests: whether or not a status change call was successful, is indicated by the http response seats.io sends you. We're using standard http status codes, such as 200 OK, 400 Bad Request, etc.

You might be tempted to think: but what if I check the status first using one of the reporting API calls, before booking... Then I'll know the seat is free, and I don't need to handle the case of a possible failure, right?
​

Wrong! While this double checking looks like a great idea at first sight, in fact it's not. Not only is it unnecessary, it's actually harmful, as it will give you a false sense of security. 

That's because you'll be issuing two API calls - one to check the seat status, and one to change the seat status - and anything can happen with the seat in the time between. Meaning that, at the time you issue the call to change the status, you're not sure anymore of the status in seats.io anyways.

Furthermore, the reporting API endpoints are not part of the rate limit priority lane, and as such you should not use them as part of your ticketing flow; you'll quickly hit the rate limits if you do.

In short: don't pre-check the status of a seat before attempting to change its status. Instead, you should just issue the status change call, and carefully handle both the success and failure case.

A second way to get double bookings in your system is by releasing seats for which a ticket has been issued, without actually revoking the ticket.

One common scenario is where you're using a seats.io session. Alice selects a number of seats (which will hold them automatically, making them unavailable for other ticket buyers), but then decides to not buy the tickets after all. The seats Alice selected will be released automatically after a while (15 minutes by default), but we see that many of our customers prefer to release the seats as soon as possible to make them available again. Sometimes, however, it seems that this releasing call is issued too soon for some reason. If Alice is still able to continue in the ticketing flow (but her seats have been released), then Bob will be able to book the seats, and you end up with tickets issued for the same seat.

In any case, it's a good idea to not release the seats, but rather issue a call to expire the hold token instead.