A reseller API that shows sellers exactly what a promoter assigned — and nothing else.
Marketplaces, ticket agents and community partners read events, venues, tiers, prices and live availability through a key-authenticated JSON API. Every response is scoped to the promoter's grant, and the quote endpoint keeps your totals identical to ours.
The BoxOfficeTech Reseller API lets verified third-party sellers list and sell a promoter's events. A promoter grants a seller access on their own account and assigns the events it may sell; the seller reads those events, tiers, prices and live availability through a bearer-key JSON API, holds inventory while its own buyer pays, and records the completed sale — the platform re-derives the price, issues the tickets and emails the buyer. Keys are issued by the platform after verification, test keys reach only test tenants, and an event outside a seller's grant does not exist as far as the API is concerned.
Endpoints
The catalog, the quote, holds and orders, and your webhook.
GET /me
Your seller account, key mode, quota, and the promoters that granted you access with their event counts.
GET /events
The assigned, live events across your grants. Poll with updatedSince for a delta; the response includes tombstones for events that stopped being live.
GET /events/{id}
One event with tiers, prices, fee configuration, portal URLs carrying your attribution — and, for reserved seating, the seat layout your picker needs.
GET /events/{id}/availability
Live counts through the same computation the buyer site uses. Reserved seats come back as one merged unavailable list.
POST /quote
The exact total the platform will charge for a cart, in cents. Authoritative — never re-implement the fee formula.
GET /venues/{id}
Address, type, capacity and coordinates for a venue backing one of your assigned events.
POST /events/{id}/holds
Hold tiers or seats for ten minutes while your buyer pays — the same transaction the buyer site runs, so nothing can be sold twice.
POST /orders
Record a sale you completed on your own checkout. Prices are re-derived, inventory is verified under your hold, the buyer is emailed their tickets, and you get the QR values back. Idempotent on your order id.
POST /orders/{id}/cancel
You refunded your buyer; the platform records it, cancels the tickets and returns the inventory. Money never moves through us on API orders.
PUT /me/webhook
Register one https endpoint and receive signed change notifications — availability changes on assigned events, assignment and grant changes, key revocations. Polling stays the contract; this is the hint.
How scoping works
Three grants, nested.
The platform vouches for a seller. A promoter opens their own door to that seller. Then the promoter names the events the seller may see. Your key resolves to the union of those assignments, and only while each event is live. There is no way to enumerate other promoters or their events, and an unassigned event id answers 404 rather than 403, so the API never confirms what exists outside your grant.
Availability is the same computation the buyer site uses: capacity minus sold, minus admin-blocked, minus seats currently held in a checkout. Holds expire within minutes, so poll rather than cache. Reserved seats come back as one merged list of unavailable seat ids; whether a seat is sold or merely held is not yours to know.
Verifying a webhook
The Stripe shape, so what you already have works.
Every delivery carries X-BoxOfficeTech-Signature: t=<unix seconds>,v1=<hex>. Compute HMAC-SHA256 with your signing secret over the string t + . + the raw request body, compare it to v1 with a constant-time comparison, and reject anything whose t is more than five minutes from your clock. The body is{ id, type, createdAt, data }; deliveries can repeat, so dedupe on id. Answer 2xx within five seconds and do the work afterwards.
A webhook is a hint that something changed, never the data itself: on availability.changed, fetch /events/{id}/availability. If your endpoint fails fifty times in a row the platform switches it off and says so on GET /me/webhook; a fresh PUT turns it back on.
Specifications
| Detail | Specification |
|---|---|
| Base URL | https://www.boxofficetech.com/api/resellers/v1 |
| Authentication | Authorization: Bearer bot_<mode>_<keyId>_<secret> — keys are issued by the platform after verification and shown once |
| Key modes | live, and test (reaches only the platform's flagged test tenants, so you can integrate end to end without touching a live customer's inventory) |
| Format | JSON; success responses are { data, meta }, errors are { error: { code, message } } |
| Quota | Per-key requests per minute (default 120), reported on every response in X-RateLimit-Limit / -Remaining / -Reset; 429 with Retry-After when exceeded |
| Scope | Only events a promoter assigned to you, and only while they are live; anything else is a 404 |
| Money | Integer cents. Face price and the promoter's configured fees; your own disclosed fee, if any, sits outside our figures |
| Availability | capacity − sold − admin-blocked − held for GA; GA zones carry no holds; reserved seats merged (sold, held, blocked) |
| Change notifications | Signed webhooks (X-BoxOfficeTech-Signature: t=<unix>,v1=<HMAC-SHA256 hex over "t.body">, 5-minute tolerance) with retries at 1m/5m/30m/2h/6h for 24 h; polling remains the contract |
| Selling through the API | You collect the money on your own checkout; POST /orders records a completed order at the platform-derived price, issues the tickets, and emails the buyer. Refunds are recorded through /orders/{id}/cancel — the money is yours to return |
| Holds | 10 minutes; tiers and reserved seats; the buyer site's own transactional oversell guard. GA zones carry no holds and are verified when the order is recorded |
| Idempotency | externalOrderId on POST /orders — a retry returns the same order, never a second one |
| Tickets | Each ticket returns a qrValue (its ticket id) — encode that in your own QR; the promoter's gate scanner reads it |
| Specification | OpenAPI 3.1 at /openapi.yaml |
Questions from integrators
The platform verifies sellers (legal entity, contact, tax id, and for marketplaces the Google Event Ticket Seller Certification) and issues the key. Then each promoter decides, on their own account, whether to grant you access and which events to assign. Contact us to start verification.
Selling tickets for organizers on this platform?
Tell us who you are and which promoters you work with. Verification takes a short conversation; a test key follows the same day.