Only accounts created after 2021-05-17 are rate limited. Older accounts don't have a limit (for now).
The seats.io API is rate limited, to keep the servers running smoothly when they receive an extremely high number of requests.
This limit is set to 100 concurrent requests per seats.io account. That means that 100 requests can be active at any given time (per account).
When you send more simultaneous requests, the API answers with status code
429 - Too Many Requests.
Note that this is not a limit on the number of concurrent ticket buyers (see below).
Also, we don't enforce a maximum on the number of requests per second. It's perfectly fine to do hundreds of fast calls per second, as long as you respect the limit of 100 concurrent requests.
In-browser calls by rendered charts (e.g. to fetch object statuses, or to create a hold token) also count towards the rate limit - not just API calls from your server to seats.io.
100 concurrent requests corresponds to about 100 renderings and 200 booked places per second. In other words: 100 ticket buyers can enter your site every second and book 2 places, without hitting the concurrent requests rate limit.
Be aware: this depends on a number of factors, such as the size of the chart, whether social distancing rules are in place, the number of already booked places etc. So it's very important to do proper load testing before you go live.
Calls to book best available seats take a little longer than normal booking calls, meaning you'll be able to do only about 100 requests per second instead of 200, before hitting the rate limit.
429 should be handled by a retry mechanism.
So if you use one of these, then you don't have to do anything: the client library will automatically and repeatedly retry requests that fail with status 429.
Expecting a higher load than what we allow on our shared instance? A dedicated seats.io server might be an option. Please get in touch.