Skip to main content

Ticket buyer IDs

The Ticket Buyer IDs feature allows you to manage and enforce a list of allowed ticket buyers for your events. Each ticket buyer is identified by a unique UUID.

When should I use this?​

Using this feature is optional and primarily intended for setups with tight security requirements, especially when using hold tokens.

You only need this feature if:

  • You want to validate that only known, trusted users (identified by a ticketBuyerId) can create hold tokens and hold seats or release holds.
  • You want to prevent abuse or misuse of hold tokens, for example, by stopping bots from creating many hold tokens or from holding large numbers of seats and locking out real buyers.
Note

You can - and should - safely ignore this feature if you're not using hold tokens or if you trust all users who interact with the chart.

How it works​

  1. Register ticket buyer IDs
    Use the API to tell seats.io about the UUIDs representing valid ticket buyers. These can be your user IDs or any other UUIDs you assign.

  2. Render charts with the ticketBuyerId
    When rendering a chart in the frontend, include the ticketBuyerId in the configuration. Seats.io will automatically add it to any direct request from the browser, i.e. the calls to create hold tokens, to hold objects and to release holds.

  3. Enable the feature
    This feature must be enabled in your workspace or company settings.

  4. Server-side enforcement
    Seats.io will validate the ticketBuyerId against the provided list of valid UUIDs to determine whether the user is allowed to create hold tokens, or hold/unhold objects. If the ID is not present in your list of allowed IDs, the request will be rejected with a 400 Bad Request response.

  5. Limit on the number of hold tokens per ticket buyer ID
    To prevent abuse, Seats.io enforces a limit on the number of hold tokens that can be created for a single ticketBuyerId. You can set this limit in your workspace or company settings. This ensures that, even if a malicious actor manages to obtain a valid ID, they cannot flood your system with hold tokens and lock up large numbers of seats.

Example flow​

  1. You add UUIDs like d2e8e3d1-4f3c-4f50-8c7d-52e654bb2cd1 via the Add Ticket Buyer IDs endpoint.
  2. Your frontend passes this UUID to the SeatingChart renderer.
  3. A user renders the chart for an event, with session: 'start' (or continue). While rendering, the chart will issue a request to create a new hold token. This request will include the ticketBuyerId, which is validated on the seats.io server.
  4. If the ID is present in your list of Ticket Buyer IDS, the creation will succeed. If not, the request is rejected with an error and the seating chart will fail to render.

The same happens when the user tries to hold or unhold objects on the chart: the ticketBuyerId is included in the request, and the server checks if it is valid.

Why UUIDs?​

Only UUIDs are supported as ticket buyer IDs.

To ensure security, it's important that you generate these UUIDs using a secure and truly random generator — not just a string that looks like a UUID. This prevents attackers from guessing or predicting valid ticket buyer IDs, which is critical if you're using this feature to restrict access.

Avoid using sequential or deterministic UUIDs. Each ticket buyer ID should be unpredictable and unique.

Scope​

This feature can be enabled on a global (company-)level, but also per workspace.
However, the list of ticket buyer UUIDs is managed at the company level only, not per workspace.

Important note

If you enable this feature, you must provide a valid ticketBuyerId when rendering the seating chart.
If not, chart rendering will fail because the underlying requests (e.g. for creating a hold token) will be rejected.