API Reference

Authentication

One header, one account. There is no OAuth and no user-delegated flow.

auth.sh

curl https://events.vihaya.app/api/v1/events \
  -H "x-api-key: $VIHAYA_API_KEY"

How keys work

Scoped to one account. A key can only ever see the events its own account owns. No uid or email is read from a request body, so there is nothing to widen.
Revocation is immediate. A revoked key returns 403 on the very next call.
Origin pinning is optional. Restrict a key to your own domains and a browser request from anywhere else is refused. Server-to-server calls send no Origin and are unaffected.
Stored hashed. We cannot show you a key again — rotate it instead.

Two kinds of key — pick the smaller one

When you create a key you choose what it can do. If you are building a checkout into your own product, take the Checkout only key.

Checkout only

For a client integration.

Can

Read an event and its tracks
Create registrations and take payment
Read seat counts and capacity

Cannot

Read attendee names, emails or phones
Create, edit or publish events
Email attendees

Full access

For your own dashboards and scripts.

Everything above, plus attendee lists, event management and broadcasts. Treat it like a password — it can read every attendee you have, so it should not live in a third party's codebase.

A key you give to someone else ends up in their codebase, their CI and their error logs. A checkout key means a leak costs spam registrations rather than your whole attendee list. A refused call returns 403 naming the scope.

Publishing needs organiser access

Creating, editing and reading all work immediately. Publishing requires the account to have been granted organiser access. Check canPublish on /api/v1/me first — without it a publish returns 403 while everything else keeps working.

Unpublishing is never blocked. Taking a broken event down must never depend on a permission check.