SeatDataDocs
API DocumentationAPI Referencev1

Get sales data (batch)

POST/v1/events/sales/batch

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.

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

ScenarioCharged a pull?
Event in the batch returns at least one saleYes - 1 pull per such event
Event in the batch has no salesNo (free)
Balance runs out mid-batchEvents already affordable are served and charged; the rest come back as payment_required in errors
No event in the batch is affordableNo data - the request returns 402

Authorization

AuthorizationBearer <token>

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

In: header

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

curl -X POST "https://example.com/v1/events/sales/batch" \  -H "Authorization: Bearer YOUR_API_KEY" \  -H "Content-Type: application/json" \  -d '{    "event_ids_sh": [      105294241,      105288127    ],    "event_ids": [      225220    ]  }'
{  "results": {    "property1": [      {        "timestamp": 1624060468,        "quantity": 2,        "price": 44.46,        "zone": "Field Outfield",        "section": "109",        "row": "2",        "listing_id": 987654321      }    ],    "property2": [      {        "timestamp": 1624060468,        "quantity": 2,        "price": 44.46,        "zone": "Field Outfield",        "section": "109",        "row": "2",        "listing_id": 987654321      }    ]  },  "errors": {    "property1": "not_found",    "property2": "not_found"  }}

Get sales data GET

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](https://docs.seatdata.io/docs/api/migrating-to-v1/). ## Billing rules | Scenario | Charged a pull? | |---|---| | First page returns at least one sale | Yes - 1 pull | | Follow-up paginated page (cursor present) | No (continuation) | | Event has no sales | No (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.

Get sales data GET

All responses are gzip encoded. You must pass either a **SeatData Event ID** (from the `/v0.3.1/events/search` or `/v1/events/search` endpoints) or a **Marketplace Event ID** (obtained separately).