Search K
Appearance
When using our Get tickets endpoints with a set of query params, for example ?event_id=some_event_id&ticket_status=available&stock:gt:0 to grab all the tickets for a specific event. You will notice that there are tickets that appear to be overlapping.
This is correct; we often have multiple suppliers for the 'same' tickets.
These supplier could be actual resellers, but also other customers who have decided to 'relist' their ticket on our platform.
The following fields in the ticket response are important when grouping tickets;
event_id is the identifier of the EVENTcategory_id is the identifier of the CATEGORYsub_category identifies a ticket for a specific ticket validity and targetgroup (note: we currently only have regular)The last one is a combination based on ticket_validity and ticket_targetgroup.
Note: To guarantee your clients sitting together, stick to ONE ticket_id.
For multi-day events, we sometimes have tickets for specific days or the whole weekend for one category. These all share the same event_id and category_id identifiers. But they will all have their own specific sub_category
| Ticket valid for | sub_category value |
|---|---|
| Friday | fri_regular |
| Saturday | sat_regular |
| Sunday | sun_regular |
| Saturday + Sunday | satsun_regular |
| Whole weekend | weekend_regular |
With this knowledge, you now know you should group tickets based on:
event_idcategory_idsub_categorySome combinations will have just one ticket, others might have several. Then it really depends on your (customer) needs;
For example the cheapest ticket might only have 2 left, while you need 4. Then perhaps the 2nd cheapest is a better fit.
Do remember; Each ticket_id implies a different supplier and means we cannot guarantee sitting together if you buy several tickets with different ticket_id.
To find out, you can fetch the category information of all the categories for the whole event via: /v1/categories?event_id:some_event_id
The category_id in response can then be matched to category_id on the ticket.
This category object in the response has a party_size_together field which gives the number of seats that are guaranteed together.
Note: Yes, you can fetch each category separately but this is inefficient for bigger events due to roundtrips and latency for each call.
For football, the only sub_category will be singleday_regular. Applying the same grouping as for formula 1 makes it easier and will give the proper result as well.
Tickets may include a flags array that contains special constraints affecting how tickets can be purchased. These flags enforce business rules and must be respected when processing bookings.
| Flag Value | Description | Impact on Booking |
|---|---|---|
pairs_only | Tickets can only be sold in pairs | Only even quantities (2, 4, 6, etc.) are allowed |
no_max_minus_1 | Prevents leaving exactly 1 ticket remaining | Certain quantities are blocked to avoid single-ticket remainder |
package_rate | Tickets must be sold as part of a package | Individual ticket sales are not permitted |
no_awayteam_nationality_allowed | Blocks guests from away team's country | Guest nationality validation will reject matching countries |
no_awayteam_province_allowed | Blocks guests from away team's province | Guest province validation will reject matching provinces |
1. Check flags before purchase:
{
"ticket_id": "123",
"available_quantity": 8,
"flags": ["pairs_only"]
}2. Validate quantities:
pairs_only is present, only allow even quantitiesno_max_minus_1 is present, avoid quantities that would leave 1 ticket3. Handle validation errors: The API will return error responses when flag constraints are violated:
4. Example response with flags:
{
"ticket_id": "abc123",
"event_id": "evt456",
"available_quantity": 6,
"flags": ["pairs_only", "no_max_minus_1"],
"ticket_status": "available"
}In this example:
no_max_minus_1)pairs_only)When submitting guest data for tickets with no_awayteam_nationality_allowed or no_awayteam_province_allowed: