Glossary
Restaurant vocabulary the rest of this site uses without stopping to explain it. Each entry is short on purpose: where a concept has a page of its own, the entry points at it rather than repeating it.
Card guarantee
Section titled “Card guarantee”A payment card held against a booking. Service takes an imprint — the card is
saved and an amount is authorised, and nothing is debited at booking time. Which
services ask for one, and from what party size, is on the service in GET /v1/availability (guarantee_from_party_size); a booking that triggers one
waits on the card before it is published. See Take a
deposit.
One seated guest. A party of four is four covers, and party_size is the cover
count. Every capacity number on this API is denominated in covers:
available_covers on a slot, max_covers_per_slot, and the caps under shift
limits.
Date override
Section titled “Date override”A change the restaurant makes to one service on one date — different hours, a
different covers cap, a different floor plan, or the service dropped for that day
altogether. GET /v1/availability returns the date as it will actually run, with
any override already applied, so you never combine the two yourself.
It is not the override array on a create, which waives a booking rule for a
single request. That one is in Book past the
rules.
A slot taken off sale while a guest pays or decides. It is not a reservation, it
has no guest, and it lives on /v1/holds until you convert it, release it, or
its deadline resolves. See Hold a
slot.
Identity assertion
Section titled “Identity assertion”A short signed token a host page hands the booking widget to prove which guest is
looking at it, so the form arrives filled in and the booking attaches to the right
profile. It belongs to the widget: on this API your server is already the trusted
party, so you name the guest yourself with guest_id or a guest object. See
Identifying the guest.
Published booking
Section titled “Published booking”A booking you can reach. It is listed by GET /v1/reservations, it resolves by
id, it appears in the updated_since feed and in the events feed, and its
reservation.created fires.
Two kinds of booking are not published yet: one waiting for a card
(awaiting_guarantee from a create on a guaranteed slot) and one waiting for a
waitlisted guest to answer (awaiting_guest). Neither reaches you, and no event
about either does — changes included. Publication is the moment the booking
becomes yours to read, and what it says then is what happened, not what was first
requested.
Service
Section titled “Service”The sitting a restaurant runs: lunch, dinner, brunch. In code it is a shift,
and the two words name the same thing: GET /v1/availability returns the day’s
services as shifts[], each with an opaque shf_… id, and the booking widget
takes one as the shiftId hint. Its opening and closing times, its last seating,
its slot grid and its shift limits all belong to
it.
A service that exists only as a date override has no shf_…
id of its own, so shifts[].id is null for it.
Capitalised and without an article, Service is the product instead. When a sentence could go either way, this site writes the Service API.
Shift limits
Section titled “Shift limits”Three covers caps a service carries, all of which a booking has to pass:
| Cap | What it limits | Published as |
|---|---|---|
| Per seating time | Covers arriving at one time on the grid, which paces the kitchen. | max_covers_per_slot on each slot |
| Per service | Covers across the service as a whole, the night’s budget. | Not published |
| Concurrent | Covers seated at the same moment, the room’s occupancy. | Not published |
You read the answer rather than the three inputs: available_covers on a slot is
whichever of the caps binds first. It is null when the restaurant sets none of
them, and null there means unlimited rather than nothing left.
A booking created with excluded_from_shift_limits: true does not count against
any of them. That flag and the scope it needs are in Book past the
rules.
Slot grid
Section titled “Slot grid”The seating times a service offers on a date: from the service’s start, at the
interval the restaurant sets for it (15, 30 or 60 minutes), up to its last
seating. The interval is not a field you can read; GET /v1/availability returns
the resulting grid itself, and no time between its steps. A create at 19:10 on a
service that seats every half hour is refused with
start_time_off_grid even though the service
is open, and that refusal’s message names the interval and the first and last
seating.
A background pass that runs on a fixed schedule and settles what a deadline on its
own does not. The one you can observe is the hold sweep, every five minutes: it
expires a commitment hold whose deadline has passed, which is why the
hold.expired you receive is stamped with the sweep’s moment rather than with
expires_at.
Walk-in
Section titled “Walk-in”A party seated without a booking, recorded by staff at the door. It reaches you as
an ordinary reservation carrying source: "walk_in", listed with the other source
values in the reference.