venuery for ticketing platforms

Seating for your ticketing platform

Your venues design their own seating charts, buyers pick seats on a map you embed, and the inventory API makes sure no seat is sold twice. You keep your checkout, your customers and your fees.

How it fits together

1. A venue draws its chart in the venuery designer, or you import one from seats.io. Publishing makes an unchangeable version.
2. You create events on a chart. Each event gets its own inventory: every seat, table and general admission place.
3. Buyers pick seats on the embedded seat map, which holds them as they pick.
4. Your server books the hold when they pay, under your order reference.
5. Webhooks keep you in sync: expired holds, releases, refunds and chart changes (webhooks).

Keys

Create keys in the dashboard under Settings → API keys. There are two kinds, each in live and test mode:

Test keys work on your organization's test data: their own venues, charts and events, never billed. A key can be limited to some venues. Send it as a bearer token, or as the username in HTTP Basic auth:

curl https://www.venuery.com/v1/me \
  -H "Authorization: Bearer sk_test_…"

curl https://www.venuery.com/v1/me -u sk_test_…:

Sell your first seat

With a test key, from an empty account to a booked seat:

curl https://www.venuery.com/v1/venues -u sk_test_…: \
  -d '{"name":"Brooks Field","timezone":"America/New_York"}'

# from a seats.io drawing (or leave out "document" and draw it in the designer)
curl https://www.venuery.com/v1/charts -u sk_test_…: \
  -d '{"venue":"ven_…","name":"Baseball","document":'"$(cat drawing.json)"'}'

curl -X POST https://www.venuery.com/v1/charts/cht_…/publish -u sk_test_…:

curl https://www.venuery.com/v1/events -u sk_test_…: \
  -d '{"chart":"cht_…","key":"2027-05-28","name":"Opening Night","starts_at":"2027-05-28T19:05:00-04:00"}'

curl https://www.venuery.com/v1/holds -u sk_test_…: \
  -d '{"event":"2027-05-28","objects":["204-C-12","204-C-13"]}'

curl https://www.venuery.com/v1/events/2027-05-28/book -u sk_test_…: \
  -d '{"hold":"hld_…","order_ref":"ORD-1042"}'

In production the seat map makes the hold (step 3) as the buyer picks; your server only books it. See the API reference for everything else.

Conventions

Ids, keys and labels

Every object has an id with a prefix (ven_, cht_, evt_, hld_). Give events your own key and use it wherever an event id goes. Seats and tables have ids that stay the same across chart versions, and labels people read (204-C-12); requests take either. Store ids: a venue can relabel a row, but the id stays.

Errors

Errors share one shape, and every response carries a request-id header. Quote it if you write to us.

{
  "error": {
    "type": "conflict",
    "message": "2 of those seats aren't available.",
    "request_id": "req_Xk2…",
    "conflicts": ["s_4k9q2m8f1x7c", "s_8f1x7c4k9q2m"]
  }
}

Retries

Send an Idempotency-Key header (any unique string, up to 255 characters) with POSTs. Retrying with the same key in the next 24 hours replays the first response instead of doing it twice. Reusing a key for a different request is refused (422).

Lists

Lists return { "object": "list", "data": [...], "has_more", "next_cursor" }. Pass limit (1–100, default 25) and the previous page's next_cursor as cursor.

Limits

• Holds last 15 minutes unless you say otherwise, and at most two hours from when they were made.
• 500 objects per request; 100 changes per batch; 100 events per bulk create.

Pricing

You pay for booked seats: a seat, table or booth booked through the API counts once per event, however often it's released and booked again, and once per season for seats booked for a season. General admission counts per place. Holds, selections and test mode are free, and seats sold through venuery Ticketing are never counted.

Choose a plan under Settings → Seating API plan. GET /v1/usage shows the month so far.