White-label ticketing · launch a branded box office in minutes

Developers · API v1

Read your TicketWave data over HTTPS.

Bearer-token authenticated REST API. JSON request + response. One namespace per major version (/api/v1); we never break a public schema inside a major.

Manage keys at /dashboard/settings/api-keys. Keys are shown once at creation — store them in your integration's secret store. Revoke + rotate at any time.

Authentication

Every request needs an Authorization: Bearer header carrying your API key.

curl https://www.ticketwavehq.com/api/v1/events \
  -H "Authorization: Bearer tw_live_xxxxxxxxxxxxxxxx"

Scopes

  • plugin:read — read events, tiers, ticket metadata. Required for every v1 endpoint listed below.
  • plugin:pii — additionally include customer name + email in ticket/order payloads. Opt-in (GDPR-conscious): tenants must explicitly grant this before exposing buyer identities to integrators.
  • plugin:qr — additionally include raw QR scan tokens. Door-access equivalent — only grant to integrations you'd hand a master key to.
  • plugin:write — perform write actions (manual check-in, ticket resend). Not yet wired to /api/v1; lives on /api/plugin/v1 endpoints until then.

Rate limits

120 requests per minute per API key. A separate per-IP limit applies to unauthenticated probes. Hitting the limit returns 429 with a retry-after header.

Endpoints

GET /api/v1/events

List your events, paginated. Filter by status with ?status=published|draft|cancelled|completed.

Scope: plugin:read. Page sizes 1–200 (default 50). Offset capped at 50,000 — beyond that, narrow your filters.

GET /api/v1/events/{slug}

Get a single event by your tenant-side slug, including visible ticket tiers with prices + remaining stock.

Scope: plugin:read. Returns 404 for slugs not owned by your tenant (deliberately avoids leaking other tenants' slug existence).

Versioning

v1 is stable. We never break a published schema inside a major version — additive fields only. When a breaking change is necessary, we ship /api/v2 with at least 12 months of overlap before v1 is sunset.

Existing WordPress plugin integrations use the parallel /api/plugin/v1 namespace which continues to work unchanged. New integrations should point at /api/v1.