API quickstart

This walkthrough runs the flow with curl. A key is required (generate one) and the API host:

export BASE="https://openapi.orriven.com"   # local development: http://localhost:3002
export KEY="osk_…"                              # the secret copied at creation

1 — Create an event

curl -s -X POST "$BASE/v1/events" \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"name":"Autumn Summit","timezone":"Asia/Shanghai","startsAt":"2026-09-01T09:00:00+08:00"}'

The event is created as draft — not public until published. Keep the returned id.

2 — Create a ticket type

curl -s -X POST "$BASE/v1/events/$EVENT/ticket-types" \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"name":"General","capacity":100,"priceAmount":12000}'

priceAmount is minor units of the event’s currency — 12000 is ¥120.00 for a CNY event. 0 (or omitting it) makes the ticket free. Keep the returned id.

3 — Open the ticket for sale

Ticket types are also created as draft. Opening is a status change:

curl -s -X PATCH "$BASE/v1/events/$EVENT/ticket-types/$TYPE" \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"status":"open"}'

4 — Read remaining seats

curl -s -H "Authorization: Bearer $KEY" \
  "$BASE/v1/events/$EVENT/ticket-types/$TYPE/availability"

{ "capacity": 100, "confirmed": 0, "waitlisted": 0, "held": 0, "remaining": 100 }

held counts seats inside live order holds from public checkout. The numbers are advisory. The binding check still happens at registration time, so a stale read cannot oversell.

5 — Register an attendee

curl -s -X POST "$BASE/v1/events/$EVENT/registrations" \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d "{\"email\":\"ada@example.com\",\"name\":\"Ada\",\"registrationTypeId\":\"$TYPE\"}"

201 with "created": true — and note the registration’s checkinCode, the badge credential, and passUrl, the hosted entry-pass page the platform has just emailed them (it asks for their email before opening). Registering the same email again returns 200 with "created": false and the existing registration. Repeats are acknowledged, never duplicated.

6 — Approve, if the ticket requires it

On a ticket with approval mode, API registrations land pending. The API records the application. It does not make the admission decision. Decide it explicitly:

curl -s -X POST "$BASE/v1/events/$EVENT/registrations/$REG/approve" \
  -H "Authorization: Bearer $KEY"

7 — Check them in

curl -s -X POST "$BASE/v1/events/$EVENT/checkins" \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"checkinCode":"CHK-…","subjectType":"event"}'

201 records the arrival. Scanning the same badge again returns 200 with "alreadyCheckedIn": true — acknowledged, not an error.

What this covers

Draft-first lifecycles — events and ticket types are invisible until opened, same as the console.
The capacity gate — when confirmed reaches capacity, the next registration returns 412 (or lands waitlisted if the ticket allows a waitlist).
Idempotent repeats — duplicate registrations and duplicate scans acknowledge instead of erroring, so retries are safe.
Automations — if this Business Unit has an “attendee added” or check-in automation, these API calls trigger it.

Endpoint reference

Codes, add-ons, bundles, orders, errors, limits.

Ticket types

Capacity, waitlists, approval mode, and visibility.

Get started

Reference

Endpoints

Storefront endpoints

What this covers

Endpoint reference

Ticket types

​What this covers

​Related

Endpoint reference

Ticket types

What this covers

Related