REST API (v1)
Read orders, line items and the accounting journal with an API key.
Everything under /api/v1 is authenticated by an API key alone — no session, no cookies. Create one at Dashboard → Integrations → API keys; a group issues keys for all its venues from its organisation settings instead.
GET /api/v1/me
Authorization: Bearer at_live_…What a key can read
| Endpoint | Returns |
|---|---|
GET /api/v1/me | What this key is, and every venue it reaches. |
GET /api/v1/locations | Those venues, with currency and timezone. |
GET /api/v1/orders | Orders, newest first, cursor-paginated. Filter by locationId, from/to, status, paymentStatus. |
GET /api/v1/orders/:id | One order with its line items at the prices actually charged. |
GET /api/v1/accounting/journal | Balanced double-entry journals for a period, with a reconciliation against Revenue. |
Four things that will bite otherwise
- Follow
nextCursor; never page by offset. The cursor is the last row’s position and is stable while the venue keeps trading. An offset is not: orders arriving mid-walk shift every later page, and the rows you lose are invisible — your totals just come out short. - Dates are the venue’s own days.
fromandtoare interpreted in the timezone/locationsreports, not UTC. Over a group you must name alocationId, because a date is not one instant across several clocks. - No guest personal data is returned, ever. An order says what was sold and how it was paid, never who ate it — the same promise the webhook payloads make.
- A
404means “not yours or not real”, and the two are deliberately indistinguishable. Nothing about other venues is discoverable here.
402 — authentication is not entitlement.