Skip to main content

Rate limit

The seats.io API is rate limited, to keep the servers running smoothly when they receive an extremely high number of requests.

API calls are either part of the priority lane or the regular lane. The ones in the priority lane are limited to 100 concurrent requests per seats.io account. That means that 100 requests in the priority lane can be active at any given time (per account).

Priority calls can be used during ticket sales:

  • creating a session token
  • rendering a chart
  • booking or holding objects
  • ...

Other calls (in the regular lane) are limited to 10 concurrent requests per account. Those are calls not directly related to selling tickets. For example:

  • reporting calls
  • creating events
  • retrieving workspaces
  • ...

API calls belong to the regular lane, unless otherwise noted in the documentation.

What happens when I hit the rate limit?​

When you make too many 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.

How many ticket buyers can enter my site?​

In-browser calls by rendered charts (e.g. to create a hold token, or to hold a seat) 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 new ticket buyers can enter your site every second and book or hold 2 places, without hitting the concurrent requests rate limit.

Since not all ticket buyers will be holding or releasing places at exactly the same time, 1.000s of people will be able to simultaneously look at the same chart without hitting the rate limit.

Be aware: this depends on a number of factors, such as the size of the chart, other API calls you're doing 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.

An example

As a practical example, suppose 2.500 ticket buyers are simultaneously looking at the same chart.

If we assume they select 4 places on average, and sessions are enabled, that amounts to 5 API calls per user: 1 call to create the hold token + 4 calls to hold the places.

Furthermore, suppose each user takes about a minute to select his places.

That means 5 x 2.500 API calls per minute, or about 200 per second - which we'll be able to handle without hitting the rate limit.

Handling rate limited requests​

Status 429 should be handled by a retry mechanism.

You could build that yourself (e.g through exponential backoff), or just use our server-side SDKs. They have exponential backoff built-in.

  • PHP: since v74.0
  • Java: since v64.0
  • Ruby: since v32.0
  • Python: since v60.0
  • JS: since v63.0
  • C#: since v81.0
  • Go: since v0.0.1

So if you use one of these, then you don't have to do anything: the SDK will automatically and repeatedly retry requests that fail with status 429.

Rate limit on test accounts​

If you haven't yet subscribed to a paid plan, you're on a test account. In that case, your API rate limit is 10 concurrent requests instead of 100.

A word about batch jobs​

The rate limiting, as described above, is tailored to allow the largest possible throughput without compromising the overall system performance. It is not tailored to giving all seats.io users all capacity at all times.

That's why it's important to avoid running high-frequency batch jobs that call endpoints in bulk against our API. Your account may be suspended if such jobs compromise our system or its performance.

When you find yourself implementing a batch job that will call the seats.io API at regular intervals, you should first ask yourself whether you really need it. In 99% of the cases, there's a better, more elegant solution. Feel free to reach out to support if you need help with this.

Second, it's absolutely crucial to carefully consider the volume and frequency of API calls before implementing them in a batch job. The batch size should be small (< 10) and the execution frequency should be low (expressed in terms of hours, not in terms of minutes or seconds).

TL;DR - Don't run high-frequency batch jobs against our API. Your account will get suspended.