For sale / not for sale
Sometimes you don't want ticket buyers to be able to choose from all seats in a venue.
For example:
- The event organizer decides to sell tickets through multiple ticketing companies. You're selling tickets for Section A, and your competitor is selling tickets for Section B. You want all seats in Section B to be visible but unselectable for your customers.
- You don't want to sell all sections in a large venue right away, but only after a number of seats have been sold in other sections.
In those cases, you can use the 'for sale' and 'not for sale' API calls to mark seats, areas, tables or categories as for sale or not for sale, without having to change the status of those objects. Doing so is much more convenient and faster than sending status changes in batch.
You can also specify the for sale configuration when you create an event or a top-level season.
You can embed the event manager to allow your admin users to modify the for sale configuration.
Note that ’for sale and ‘not for sale’ do not replace seat bookings. Each time you assign a seat to someone, you must also use our status change API, otherwise the availability management will not work properly.
In effect, it is a condition of use of Seats.io that there is a strict mirroring between assigning a seat and a /change-object-status or /book API call. Breach of this would constitute a breach of our terms of use.
There’s a rate limit of 10 calls per event per day on the for sale/not for sale API calls, which means you’ll get an error if you try more often. See below for more info.
Seats.io accounts created before March 11 2024 can mark whole sections or rows not for sale. Newer accounts can't.
We removed this functionality because it had a confusing side-effect: it you marked a booth called 'A' as not for sale, all seats in row 'A' became not for sale as well.
Rate limiting
The API endpoints that modify the for sale config are rate limited: you can only call it 10 times per 24 hours.
Of course, this rate limit applies per event: If you have used up all 10 saves for event A, you will still be able to change the for-sale configuration for event B.
If that limit of 10 is reached, a 429 (Too Many Requests) is returned.
The Retry-After header indicates how many seconds you have to wait before trying again.
If you only mark seats as for-sale, that were previously marked as not-for-sale, the call is not counted for the rate limit.
In other words: you can always change the for-sale configuration of an event to open up more seats for sale.
This allows you to start sales with just a portion of your floor plan as available, and then to gradually open up the rest of the seats.
So this operation will count for the rate limit:
And this will not count for the rate limit:
