This guide will help you migrate from API v1 to the new v2.
Since 1 March 2018 the v1 API is deprecated and will be shut down by the end of October 2018. It is important that you migrate to v2 before then, so that your application continues to work.
There's a new API version, aptly named v2, which is publicly available since 1 March 2018.
If you are new to seats.io, or just starting the integration, we recommend you to use v2 directly and avoid calling v1 endpoints.
Feb 2017: When we started porting the API.
To avoid a big bang release, we've been gradually migrating all API endpoints one by one. That's right: the v2 code has been running in production, some of it for over a year.
If you're interested in a more detailed explanation, please refer to this blog post.
15 Dec 2017: the day on which v2 was feature complete. Since then, all of the API calls to v1 were proxied to the v2 instance running in production.
1 March 2018: v2 is publicly available. This is the start of the migration window.
31 Oct 2018: v1 is switched off. This is the date by which you should have migrated your code to use the new API calls. We kept the migration window extremely large, so that you can choose the best moment to make the switch.
For a whole number of reasons, both functional and technical. In summary, we wanted and needed to consolidate the insights we've gathered, and to pay off some of the technical debt we'd been accumulating over the past few years.
The result is a cleaner, better, faster, nicer-to-use API.
We've dedicated a whole blog post to this question, which you can read here.
Here is an overview of the biggest changes between V1 and V2:
the base URL changed from
the secret key is sent in a basic authentication header instead of being part of the URL (docs)
the calls to list charts, events and subaccounts are paginated (docs)
we've removed support for UUIDs when booking or releasing seats. Apart from the fact they were not UUIDs anyway, they did add an unnecessary layer of complexity, and frequently led to inconsistencies and hard-to-explain situations.
response compression behaviour is consistent across the API: payloads are uncompressed by default, but can be gzipped if requested (docs).
we've renamed '(temporary) reservations' to 'holds'. The term reservation regularily caused confusion, because it can mean many different things.
Note that this is just a terminology change: functionally, a hold is exactly the same as a reservation, and a holdToken is exactly the same as a reservationToken.
we've created API client libraries for PHP, Java, C# and Python to make integration super-easy.
Other languages to follow.
Below is an overview of each of the API endpoints v1 provides, and its the corresponding v2 counterpart.
Change general admission object status
Change reservation token expiration date
(note that it's a POST and not a PUT anymore)
Retrieve chart linked to an event
Archive a chart
Unarchive a chart
Retrieve chart thumbnail
Publish draft chart
Retrieve object status
Change book whole tables
List status changes