Endpoints

Resolves the key to an account: name, email, phone on file, organiser status, whether it can publish, and how many events it owns.

Start here. `canPublish` is false until the account has been granted organiser access — publishing will 403 until then.

Every event this key's account owns, newest first, undated events last.

Scoped to the caller. You can never see another organiser's events.

Creates an event. It is always created as a DRAFT — it has no public page and cannot sell until you publish it.

The required date field is `startDate`. Sending `date` returns 400 — the response object echoes both, which misleads on a second read. `sendTicketEmails` is accepted by the schema but NOT written: switching Vihaya's ticket email off is a platform-staff action (it is fixed in Firestore rules so an organiser cannot silence their own attendees' tickets). Ask support. Until they do, sending your own ticket email means the attendee receives BOTH.

The full event document, including its tracks.

Change any editable field. Send `{ "status": "published" }` to put it on sale, `"draft"` to take it down.

Publishing is refused with 403 if the account has no organiser grant. Unpublishing is never blocked.

Permanently removes an event you own, and every registration under it.

⚠️ THIS ONE DOES NOT ACCEPT AN API KEY. Unlike every other endpoint here it requires a signed-in session — `Authorization: Bearer <Firebase ID token>` — and answers 401 "Missing Authorization Bearer token" to `x-api-key`. Deletion is recursive and irreversible, so it was deliberately left on the dashboard's own auth. An event still holding PAID registrations is refused with 409 — refund them first. `?force=true` is honoured for Vihaya staff only; test events skip the check, since their payments are not real.

Every track on the event, in order.

Tracks are addressed by ARRAY INDEX, not by an id — they do not have one.

Appends a bookable session to the event.

Edits one track by its zero-based index.

An out-of-range index returns 404 rather than creating a track.

Files a registration. On a free event it confirms immediately. On a paid event this is a two-step call — see “Taking payment” above.

A paymentId alone is not proof of payment — it is verified against Razorpay and bound to both the order and the registration before anything is confirmed.

The attendee roster for one event.

This returns attendees' names and email addresses. Treat the response as personal data.

Capacity, seats taken and what is left — for the event, or for one track via `?subEventId=`. Per-tier counts come back too.

`remaining` is null when capacity is unlimited, never 0 — a `0` here genuinely means sold out. These are the same numbers the confirm transaction enforces, so a picker built on this can never promise a seat that is about to be refused. Reachable by a `checkout` key.

Counts and revenue without pulling the whole roster.

Prefer this over listing registrations when you only need a number.

Sends one message to an audience resolved from the event's own registrations. Previews by default; a real send takes two calls.

`to`, `emails`, `bcc`, `cc` and `recipients` are refused with 400. Recipients are always the event's own attendees — this is not a mail relay.

Every membership plan on this account, in this key's mode.

Defines what a member pays. `fixed_term`: paid once, valid for `termMonths`. `recurring`: billed every period on UPI AutoPay (creates the matching plan at Razorpay).

⚠️ (Recurring plans) ₹15,000 IS A HARD CEILING, AND IT IS REFUSED HERE ON PURPOSE. A UPI AutoPay mandate can be registered up to ₹1,00,000, but only debits at or below ₹15,000 go through without the member authenticating EVERY time — which is not a subscription, it is a recurring reminder to pay. A plan priced above it registers perfectly at Razorpay and then fails as a product on the first real renewal, so this refuses it rather than letting you discover that later.

Recurring plan: creates the subscription a member authorises with a UPI AutoPay mandate. Fixed-term plan: creates a one-time Razorpay order (`orderId`, `amount`, `keyId`) to open Checkout on; paying again in the last 30 days or after expiry renews. Reachable by a `checkout` key.

⚠️ A 201 HERE IS NOT A MEMBER. Razorpay answers `created`: nothing is charged and nobody has joined until they approve the mandate in their UPI app, which arrives as `subscription.authenticated` on your webhook. Treat this response as "ask them to authorise", never as success — otherwise every person who opens the UPI app and changes their mind is recorded as a paying member. Enrolling the same email on the same plan twice returns the existing membership instead of registering a second mandate.

Cancels the mandate. By default at the end of the current billing period, so the member keeps the time they have paid for.

Cancelling twice is not an error — it returns `alreadyEnded: true` and changes nothing, because the money has already stopped, which is what the caller wanted. If Razorpay refuses the cancellation the local record is deliberately left ALONE and the call fails: telling you billing had stopped while the mandate kept debiting is the one lie this endpoint must never tell.

Your members, in this key's mode. Pass `email` (and optionally `planId`) to check one person — read `goodStanding` on the row.

A fixed-term member stays `active` in storage after their date; `goodStanding` and `displayStatus: "expired"` are worked out when you ask. Not available to a `checkout` key — a roster is personal data. There is no API to add a member: a member pays through the join link or `/memberships/subscribe`. Only a Vihaya admin can add one by hand, from the dashboard; those rows carry `source: "manual"`.

Resolve a scanned QR WITHOUT admitting it: who is at the door, whether they may come in, and how many of their party have already arrived.

Use this for the operator's confirmation screen. Checking whether somebody is already in must never be the thing that marks them in — that is what this endpoint is for.

Marks a booking — or one member of a team booking — as arrived. Send `undo: true` to reverse it.

RE-SCANNING IS SAFE. A repeat scan returns 200 with `changed: false` and `alreadyCheckedIn: true`, writes nothing and does not move the timestamp — a gate re-scans constantly, so that is normal traffic, not an error. A refunded or cancelled ticket is refused with 409 and a `refusalReason` you can put on the screen. The OLD QR of a transferred ticket is refused with 409 and `reason: "transferred"`.

The configured URL, whether it is enabled, and the event types it receives.

The signing secret is never returned here. It is shown once, on the PUT that created or rotated it.

Creates the webhook, changes its URL, or pauses it. Returns the signing secret only when one is generated.

SAVE THE `secret` FROM THIS RESPONSE — it cannot be read back. The secret is always generated by us and never accepted from the caller: a caller-chosen one can be weak or reused, and the whole value of the signature is that only we and your receiver could have produced it.

Removes the endpoint and its secret together.