Endpoint reference

All paths live under $BASE/v1 and require Authorization: Bearer <secret>. This page is the map. Detail lives in two places:

The Endpoints group in this tab documents every operation — full request and response schemas, field by field, with a Try it playground that accepts a key.
The API also describes itself: GET $BASE/openapi.json is the OpenAPI 3.1 spec (generate a client from it), and $BASE/docs serves the same interactive reference from the deployment.

This page covers the secret-key Developer API. The browser-facing Storefront API has its own reference: the Storefront endpoints group in this tab, GET $BASE/storefront/openapi.json, and $BASE/storefront/docs.

Events

Method & path	Does
`GET /v1/events`	List the Business Unit’s events, all statuses
`POST /v1/events`	Create as draft; `name`, `timezone`, optional `startsAt`/`endsAt`, `siteUrl`
`GET /v1/events/{eventId}`	One event, `siteUrl` included
`PATCH /v1/events/{eventId}`	Update name, dates, timezone, `status` (`draft`/`published`/`archived`), `currency`, `siteUrl` (https, or null to clear)
`POST /v1/events/{eventId}/archive`	Archive — events are never deleted

Console rules apply unchanged: publishing needs a start time (400); the currency locks once the event has taken an order (412); moving the start date clears the agenda — the first attempt returns 412, restate with "confirmAgendaReset": true to confirm.

Ticket types

Method & path	Does
`GET /v1/events/{eventId}/ticket-types`	List with `counts` (confirmed / waitlisted)
`POST …/ticket-types`	Create as draft: `name`, `capacity` (null = unlimited), `priceAmount`, `allowWaitlist`, `isPublic`, `requiresApproval`, `opensAt`/`closesAt`
`GET …/ticket-types/{typeId}`	One type
`PATCH …/ticket-types/{typeId}`	Any of the above plus `status` — the lifecycle is `draft → open ⇄ closed → archived`
`GET …/ticket-types/{typeId}/availability`	`{ capacity, confirmed, waitlisted, held, remaining }`

Repricing never rewrites sold orders — amounts on an order are purchase-time snapshots. Perk bindings, registration forms and refund policies are configured in the console, not over the API.

Registrations

Method & path	Does
`GET /v1/events/{eventId}/registrations`	List, newest first; `?status=` and `?email=` (exact) filter
`POST …/registrations`	Register: `email`, optional `name`, `registrationTypeId` (required when the event uses ticket types)
`GET …/registrations/{id}`	One registration
`POST …/registrations/{id}/approve`	Decide a `pending` application
`POST …/registrations/{id}/reject`	Decide it the other way; optional `reason`
`POST …/registrations/{id}/cancel`	Release the seat (and the code use, if a code admitted them)
`POST …/registrations/{id}/rotate-access-token`	Regenerate the person’s entry-pass link — every earlier `passUrl` stops working at once
`GET …/registrations/{id}/perks`	The person’s effective perks: ticket ∪ code ∪ individual grants

Behaviour to design for:

Approval-mode tickets land pending when created over the API — unlike a console operator, the API is not an admission decision. Approve explicitly.
Full ticket → 412 (or the registration lands waitlisted if the ticket allows it).
Repeat email → 200 with "created": false and the existing registration — never a duplicate, never an error.
Approve/reject only move pending rows; anything else returns 412.
Every registration carries a checkinCode (CHK-…) — the badge credential for check-in — and a passUrl, the hosted entry-pass page (QR, wallet passes, certificate, surveys) that asks the person for their email before opening.

Redemption codes

Method & path	Does
`GET /v1/events/{eventId}/redemption-codes`	List with live `uses` counts
`POST …/redemption-codes`	Create: `registrationTypeId`, optional `count` (batch), `code` (custom, forces count 1), `label`, `maxUses` (default 1, null = unlimited), `expiresAt`
`GET …/redemption-codes/lookup?code=`	Validate a buyer’s code: the ticket it unlocks (hidden ones included), the admission’s perks, the discounted price. Every invalid form is the same 404
`POST …/redemption-codes/{codeId}/disable`	Disable — codes are never deleted

A custom code that already exists in the event returns 409.

Add-ons and bundles

Method & path	Does
`GET/POST /v1/events/{eventId}/addons`, `GET/PATCH …/addons/{id}`	Add-on configuration; the sellable lifecycle (`draft → open ⇄ closed → archived`)
`GET/POST /v1/events/{eventId}/bundles`, `GET/PATCH …/bundles/{id}`	Bundle configuration
`PUT …/bundles/{id}/items`	Replace the bundle’s whole contents: `[{ itemType: "registration_type" \| "addon", itemId, quantity }]`

Every bundle item must be a real ticket type or add-on of the same event (400 otherwise).

Orders and checkout

Method & path	Does
`POST /v1/events/{eventId}/checkout-sessions`	Create a checkout session: `items`, optional `email`, `name`, `responses`, `redemptionCode`, `promotionCode`, `returnUrl`, `locale`. Returns `{ id, url, expiresAt }`. Send the buyer to `url`, orriven’s hosted checkout. Holds nothing until the buyer places
`GET …/checkout-sessions/{id}`	`{ id, url, expiresAt, orderId }` — `orderId` once the buyer placed from it
`GET /v1/events/{eventId}/orders`	List with line items; each carries `orderUrl` (its hosted page), `checkoutUrl` while open, `returnUrl`
`GET …/orders/{orderId}`	One order
`POST …/orders`	Place: `email`, optional `name`, `items` (`registration_type` / `addon` / `bundle`), optional `redemptionCode`, `promotionCode`, `responses`, `returnUrl`. Holds places 15 minutes; a buyer already registered returns `alreadyRegistered: true`
`POST …/orders/{orderNumber}/confirm`	Free order → settles and fulfils (`status: "paid"`). Paid order → `status: "awaiting_payment"` + `paymentUrl` (hosted Stripe); `successUrl`/`cancelUrl` optional (https; localhost http allowed). When omitted, Stripe returns the buyer to the hosted order page
`POST …/orders/{orderNumber}/cancel`	Releases the hold now; idempotent

Settlement of paid orders arrives by the platform’s Stripe webhook — poll the order until paid. Refunds stay a console decision. The whole flow, end to end: Checkout from your backend.

Check-ins

Method & path	Does
`GET /v1/events/{eventId}/checkins`	List; filters `?subjectType=`, `?subjectId=`, `?registrationId=`
`POST …/checkins`	Record: `registrationId` or `checkinCode`, plus `subjectType` (`event` / `session` / `venue`), `subjectId` for session or venue doors, optional `method` (`scan` / `manual`)

Only a confirmed registration can check in (412). A second scan at the same door returns 200 with "alreadyCheckedIn": true.

Program and venues

Method & path	Does
`GET /v1/events/{eventId}/sessions`	The agenda in time order: title, times, `venueId`, and the session’s own gate as `perkIds` (empty = open to all)
`GET /v1/events/{eventId}/speakers`	The line-up: name, title, bio, `registrationId`, `sessionIds`
`GET /v1/events/{eventId}/venues`	The rooms, each with its own gate as `perkIds` — a session inherits its venue’s gate on top of its own

Attendees

Method & path	Does
`GET /v1/events/{eventId}/attendees`	Read-only: one entry per person with their registration ids and standing status

Exhibitors

Method & path	Does
`GET /v1/events/{eventId}/exhibitors`	Read-only list: each company with its profile, status, staff roster (`members[]` — `registrationId` and role) and booth allocations (`booths[]` — number, type, venue). `?registrationId=` narrows to the company that registration staffs — at most one per event
`GET …/exhibitors/{exhibitorId}`	One exhibitor, roster and booths included

Read-only by design: confirming a company, editing the roster and allocating booths are console decisions. The registrationId filter returns the company that registration staffs — for example after a badge scan resolved to a registration.

The error envelope

Every error, whatever the status, uses the same shape:

{
  "error": {
    "code": 404,
    "status": "NOT_FOUND",
    "message": "Event not found.",
    "details": []
  }
}

HTTP	`status`	When
400	`INVALID_ARGUMENT`	Malformed body or parameters; `details` carries field-level issues
401	`UNAUTHENTICATED`	Missing, unknown, revoked, or expired key. The response is the same in each case
404	`NOT_FOUND`	The resource is not in this key’s Business Unit. A foreign id and a nonexistent id return the same response. The API does not confirm what exists elsewhere
409	`ALREADY_EXISTS`	A custom redemption code that already exists
412	`FAILED_PRECONDITION`	A business rule blocks it: sold out, currency locked, not pending, not confirmed, agenda reset unconfirmed
429	`RESOURCE_EXHAUSTED`	Rate limit — see below

Rate limits and retries

Each key may make 120 requests per minute. Beyond that, requests return 429 until the window resets. Back off on 429. Repeat registrations and repeat scans acknowledge rather than fail, so retrying writes is safe.

Quickstart

The same flow, end to end.

Orders

How those orders appear in the console.

Get started

Reference

Endpoints

Storefront endpoints

Events

Ticket types

Registrations

Redemption codes

Add-ons and bundles

Orders and checkout

Check-ins

Program and venues

Attendees

Exhibitors

The error envelope

Rate limits and retries

Quickstart

Orders

​Events

​Ticket types

​Registrations

​Redemption codes

​Add-ons and bundles

​Orders and checkout

​Check-ins

​Program and venues

​Attendees

​Exhibitors

​The error envelope

​Rate limits and retries

​Related

Quickstart

Orders

Events

Ticket types

Registrations

Redemption codes

Add-ons and bundles

Orders and checkout

Check-ins

Program and venues

Attendees

Exhibitors

The error envelope

Rate limits and retries

Related