SeatDataDocs
API DocumentationAPI Referencev1

Get sales data

GET/v1/events/{event_id}/sales

Returns validated sales records for a single event - each row is a real transaction that was observed. quantity is inferred and may be 0; price reflects the listing price at the time of observation. Rows are ordered by timestamp descending, then by id descending (a stable tiebreak for paging).

The v1 equivalent of GET /v0.3/salesdata/get. Same data, same billing - plus cursor pagination, a JSON response envelope, an integer listing_id on every row, and structured JSON errors. Responses are plain application/json (not gzip encoded). See the migration guide.

Billing rules

ScenarioCharged a pull?
First page returns at least one saleYes - 1 pull
Follow-up paginated page (cursor present)No (continuation)
Event has no salesNo (empty result, free)

Fetching an event's full history through pagination costs the same single pull as one GET /v0.3/salesdata/get call.

Pagination

Cursor-based. The first page response includes total_count; subsequent paginated pages omit it. next_cursor is opaque - pass it back verbatim via starting_after; don't parse it. Cursors are scoped to the event they were issued for and expire after 1 hour.

Authorization

AuthorizationBearer <token>

Pass Authorization: Bearer <api_key>. Preferred for new integrations.

In: header

Path Parameters

event_id*integer

SeatData Event ID (from /v1/events/search) by default. To pass a Marketplace Event ID instead, add ?id_type=marketplace.

Query Parameters

id_type?"marketplace"

Set to marketplace to interpret the path id as a Marketplace Event ID. Omit to interpret it as a SeatData Event ID.

Value in

  • "marketplace"
limit?integer

Max sales rows per page (default 100, max 200)

Rangevalue <= 200
Default100
starting_after?string

Cursor from a previous response's next_cursor

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

application/json

curl -X GET "https://example.com/v1/events/225220/sales" \  -H "Authorization: Bearer YOUR_API_KEY"
{  "event_id": 225220,  "total_count": 4213,  "data": [    {      "timestamp": 1624060468,      "quantity": 2,      "price": 44.46,      "zone": "Field Outfield",      "section": "109",      "row": "2",      "listing_id": 987654321    }  ],  "has_more": true,  "next_cursor": "string"}

Get event stats GET

Returns the historical event_stats time series for a single event. Each snapshot row includes event-level aggregates (avg/median price, get-in price, listing fill rate) AND inline zone-level breakdowns for every zone in that snapshot. ## Billing rules | Scenario | Charged a pull? | |---|---| | First request for an event (no cursor, snapshots exist) | Yes - 1 pull | | Follow-up paginated page (cursor present) | No (continuation) | | Repeat first-page request, no new snapshot since last paid pull | No (freshness rule) | | Repeat first-page request, new snapshot logged in between | Yes - 1 pull | | Event has no event_stats rows yet | No (empty result, free) | The freshness rule means polling for "is there fresh data?" only costs when there's actually new data to consume. ## Pagination Cursor-based. The first page response includes `total_count` and `available_zones`; subsequent paginated pages omit them. Cursors expire after 1 hour.

Get sales data (batch) POST

Returns validated sales records for up to 100 events per request, combined across both id lists after deduplication. Rows carry the same fields as `GET /v1/events/{event_id}/sales`, including `listing_id`. The v1 equivalent of `POST /v0.3/salesdata/batch` - same request body, same response shape, same billing. Differences: responses are plain `application/json` (not gzip encoded), rows include `listing_id`, and a malformed body returns a JSON error envelope instead of plain text. See the [migration guide](https://docs.seatdata.io/docs/api/migrating-to-v1/). There is no pagination and no `id_type` parameter here - the two id lists in the body drive the request, and all rows are returned for each event. `results` and `errors` are keyed by the exact identifier string you sent: Marketplace Event IDs appear under the marketplace id, SeatData Event IDs under the SeatData id (a SeatData ID and a Marketplace ID that resolve to the same event are echoed under both keys). ## Billing rules | Scenario | Charged a pull? | |---|---| | Event in the batch returns at least one sale | Yes - 1 pull per such event | | Event in the batch has no sales | No (free) | | Balance runs out mid-batch | Events already affordable are served and charged; the rest come back as `payment_required` in `errors` | | No event in the batch is affordable | No data - the request returns 402 |