Reservations & waitlist

Configure access

Ask the venue administrator to configure and publish the reservation public channel, booking rules, allowed website origins and contact-verification delivery. Use the resulting publicHandle. Supply the allowed Origin for public-channel requests; an absent or disallowed origin can be rejected.

Cabinet route: /venues/:venueId/reservations → Rules → Public channel. Configuration requires reservations.rules.manage. A website origin is the scheme, hostname and optional port, without a path.

• Open Hallify

First successful workflow

Follow these steps in order. Open each method for its exact body, required headers and response schema.

1. Read configuration, then request availability for venue-local date and party size.
2. Create a booking intent for a selected slot, or a waitlist intent. Send an Idempotency-Key.
3. Ask the guest for the delivered contact code and verify the intent before the hold expires. A pending intent is not yet a reservation.
4. Keep the returned manage capability and revision. Read, confirm, change or cancel only the owned reservation; notified waitlist entries can be claimed within the claim window.

• Get the public booking projection
• Get publicly bookable slots
• Create a verified public booking intent and hold
• Verify and atomically convert a public intent
• Read an owned reservation or waitlist entry

State, retries and recovery

Resend verification only within channel limits. After hold expiry, refresh availability and start a new intent. On a revision conflict, reload the guest-owned record. A public handle never grants access to the restaurant’s full reservation list.

• Errors and limits
• Access and authentication