At the door
A guest management API —
the list fills from your systems.
Every call is HMAC-signed and leaves your own backend: check whether registration is open, then create the guest. And if you'd rather not write code, one script tag embeds the form.
At the door
Registration happens on our own site, and the event system's list is always a step behind it.
The list gets refreshed once a day by hand — usually after you have already sent something based on the old numbers.
Signed requests
Every call is HMAC-SHA256 signed from your server, inside a five-minute window around the timestamp.
A key per event
Minted in the settings screen; the key identifies the event itself, and the secret is shown once.
Status, then register
GET status returns whether registration is open and, when a quota is set, how many seats are left; POST register creates the guest on free events. On events that sell paid tickets, registration finishes on our own checkout page and the guest row is created once payment clears.
Fields at runtime
Custom form fields come back on the status response, so adding one needs no deploy on your side.
Lookup by phone
An account-wide key reads a guest's records by phone number across your active events that have the WhatsApp assistant switched on, and writes an RSVP back on them — except on paid-ticket events, where payment itself is the confirmation.
Embeddable form
One script tag drops the registration form into any site, resizing itself to its content.
How it works
Four steps.
Mint a key
Settings → API keys. The secret is shown once.
Sign
HMAC-SHA256 over timestamp, method, path and raw body.
Call
Status before you render the form, register on submit.
Watch
The console shows when each key was last used.
FAQ
What people ask before wiring the two systems together.
Can we push guests from our own system into the list?
It depends on the event's mode. On an open-registration event, yes — POST /api/v1/register, one signed request per guest, capped at 10 requests per hour from the same IP. On an approved-list event a phone that isn't already on the list comes back as not_on_list and waits for manual approval in the console. For a one-off load of an existing list, an Excel upload in the console is the better route — there is no bulk endpoint. On a free event the same phone twice returns already_registered instead of a duplicate, so a retry after a network failure is safe. On a paid-ticket event a repeat call is deliberately treated as a second purchase and opens a new order, so check the previous call's result before retrying.
Are there webhooks, or a way to pull the list?
There are no outbound webhooks, and no endpoint that returns the whole list. An account-wide key can read a guest's records by phone number and write an RSVP back. A full export is done from the console.
Can we embed the registration form in our own site?
Yes — one script tag carrying the event identifier loads the form in an iframe on any domain, sizing itself to its content. Picking a paid ticket leaves the frame for a full-page checkout. Styling is set in the form builder — text, field and button colours are stored on the event, and the embedded form renders exactly what the hosted registration page renders, so it can never drift from your design.
What do we do if a key leaks?
Disable or delete it in the settings screen and mint a new one — a request signed with a disabled key is rejected. The secret is shown once at creation, so re-issuing is also how you recover it. Signing always happens on your server, never in the browser.
Related
More in the system
Ready to wire it up?
Open an account, mint a key and test it against a real event — no commitment.
