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 seats.io 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 seats.io 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 seats.io 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 seats.io 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 seats.io, 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 seats.io 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 seats.io 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 seats.io 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.
☑️ 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 seats.io will crack under the load, but because you want to avoid frustrated ticket buyers as much as possible.
Conclusion
In this article, we've looked at a number of ways to check your seats.io 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
✓ Queue your users in very small batches