Get sales data

Returns sales records for up to 100 events per request, combined across both id lists after deduplication. Each row is a real sale transaction. Rows have the same shapes as on `GET /v1/events/{event_id}/sales`, including the per-source key differences described there. The v1 equivalent of `POST /v0.3/salesdata/batch` - same request body, same response shape, same billing. Differences: responses are `application/json` with no forced gzip, 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. ## Sources The optional `source` parameter behaves exactly as it does on `GET /v1/events/{event_id}/sales`: `sh` (the default), `vs`, or `all`. Send it on the URL - it is a query-string parameter, not a body field: ``` POST /api/v1/events/sales/batch?source=all ``` The response carries a top-level `sources` object, keyed by the same client-sent event ids as `results`. Each value lists both marketplaces, `sh` first, regardless of the `source` filter. `results` and `errors` are unchanged in shape. An invalid `source` returns `400` `invalid_param` with `param` set to `source`, free of charge. `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). ## Quantity and price `sh` sales often reach us unenriched, without a quantity or price. For those we derive both from the listing data we hold for that listing; a `quantity` of `0` means it could not be reliably determined. `vs` sales carry both as reported. ## 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 |