The configuration object

Configuration is the restaurant’s booking policy: the limits a request can break, plus the locale and currency every other payload is expressed in. It comes back from Configuration and nowhere else.

Fields

objectstring

Possible values: configuration

The object type: always configuration.

namestring

The restaurant this API key resolves to. There is no other way to confirm it.

public_booking_urlstring

The restaurant’s hosted booking page on our side, absolute and per-environment.

Two uses, and the second is the one that matters: it is a booking page for this restaurant you can send a guest straight to, and it is the BASE of the guest self-service page — append /{modification_token} (from POST /v1/reservations?expand=modification_token) and the guest can view, modify or cancel that booking with no credential of yours.

⚠️ Absolute on purpose: a relative path would resolve against whatever origin your funnel is served from and 404. Read it from here rather than hard-coding a host — it differs between environments, and it moves if the restaurant’s slug is changed.

countrystring

ISO-3166 alpha-2. Phone numbers sent without a country code are normalised against this country.

timezonestring

IANA zone. Every service_date and every HH:MM on this API is wall-clock in this zone — never UTC, never the caller’s.

currencystring

ISO-4217. The currency every minor-unit amount on this API is denominated in, guarantee quotes included.

primary_languagestring

Possible values: fr en de es it nl pt da sv no fi

The language restaurant-authored text — shift names, guest messages, closure messages — is rendered in when you send no ?locale=. It is also the language a guest created without guest.language is given.

guest_languagesarray of string

The languages this restaurant maintains guest-facing content in, primary first. This is the exact set ?locale= accepts on GET /v1/availability and GET /v1/availability/months; anything else is a 400 with param: "locale", because a locale the restaurant holds no strings for would silently answer in the primary language instead.

⚠️ It also bounds what a guest can actually be WRITTEN to in: guest.language on a create accepts any language the platform supports and records it on the profile, but the message goes out in the first of that language and primary_language that appears in this list. Sending one outside it is not refused and changes nothing today.

min_party_sizeintegernullable

Smallest party the restaurant accepts online — policy, not a promise of a table (party_sizes on GET /v1/availability/months is what can be seated). A smaller one is refused with party_size_too_small — overridable, so a key carrying reservations:write:override can still place it. Null means the restaurant sets no floor and the rule never fires.

max_party_sizeintegernullable

Largest party the restaurant accepts online — policy, not a promise of a table (party_sizes on GET /v1/availability/months is what can be seated). A larger one is refused with party_size_too_large — overridable, so a key carrying reservations:write:override can still place it, which is how a partner books the large party the restaurant agreed to by phone. Null means no ceiling.

default_party_sizeintegernullable

The restaurant’s own suggested party size: preselect it. Always between min_party_size and max_party_size.

current_datestring (date)

Today, in timezone — the date date_in_past is measured against, not the caller’s. An earlier service_date is refused and, unlike the party and window limits, date_in_past can NOT be overridden: a service that has happened cannot be sold. One exception, and it is not an override — a service that started yesterday and is still seating past midnight remains bookable on yesterday’s date.

max_advance_daysintegernullable

How many days ahead of current_date the restaurant sells. Beyond it, both availability and create answer advance_window_exceeded, which is overridable on the create. Null means the restaurant has no booking rule and the window is not enforced.

last_service_datestring (date)nullable

current_date + max_advance_days — the last date worth offering, pre-computed so a calendar can be bounded with a string comparison. Null whenever max_advance_days is.

default_cutoff_minutesintegernullable

The house default for how many minutes before a service starts online booking closes; 0 means bookable until the start time, -1 means bookable during the service, and null means the restaurant has no booking rule at all.

⚠️ A DEFAULT, not the enforced value: an individual service, or one date of it, may set its own, and cutoff_passed is decided on that. Read the ENFORCED value from effective_cutoff_minutes on each shift of GET /v1/availability, which resolves the same cascade the create path checks. Use this one only where no shift is in hand — a settings screen, a default in copy.

Availability remains the authoritative answer either way: a slot past its cutoff is simply not listed.

show_seating_preferenceboolean

Whether the restaurant wants guests asked to choose a seating area. Render the seating step from GET /v1/sections when true; skip it and send no section_id when false.

⚠️ ADVISORY, not a rule: section_id is accepted on availability and on a create either way, and nothing is refused for sending one. It is the restaurant’s preference about its own booking flow, and it is the only place that preference is stated.

require_guest_emailboolean

Whether the restaurant asks for a guest e-mail address on its own booking form.

⚠️ ADVISORY, not a rule: this API does NOT enforce it, and a create with no e-mail is accepted whatever it says — see required_guest_fields for what is actually demanded. Use it to mark the same field required in your funnel rather than contradict the restaurant in either direction.

One refusal does involve the address and it is not this flag: a slot carrying a card guarantee always needs one, however this reads, or the create is refused with email_required_for_guarantee — the guest is sent a pay-link by e-mail and cannot complete the booking without it.

require_guest_phoneboolean

Whether the restaurant asks for a guest phone number on its own booking form.

⚠️ ADVISORY, not a rule, exactly like require_guest_email: this API does not enforce it.

⚠️ Sending NEITHER an e-mail nor a phone number is accepted and costs the restaurant two things worth knowing: nobody can reach that guest when a service is cancelled, and the booking can never be matched to an existing guest profile, so it creates a new one every time. Send whichever you hold, or identify the guest with guest_id.

card_guarantee_from_party_sizeintegernullable

Whether this venue asks guests for a card imprint at all, and from which party size.

null is a promise: no booking made now, on any service or date, is asked for a card — skip the card step entirely for this venue. Either the restaurant uses no card guarantee, or it cannot currently take one.

A number N is only a maybe: some service, on some date, may ask a party of N or more, and no service asks a smaller party. Build the card step, then read guarantee_from_party_size and guarantee on the service in GET /v1/availability for the date the guest picks — that is the exact answer.

It can go from null to a number whenever the restaurant turns guarantees on, with no change on your side: if you keep it for longer than a session, revalidate with the ETag. No amounts or cancel window here; those are per service.

required_guest_fieldsarray of string

Guest fields a create must carry, or it is refused with guest_fields_required. Not required when the create identifies an existing profile by guest_id. This is the ENFORCED list, and it is not the widget’s form policy: require_guest_email / require_guest_phone above are published as advice about the restaurant’s own form and do not bind this API. Only what appears in this array is refused.

Two fields the whole API depends on

timezone is the zone every date and time on this API is expressed in — a service_date, a starts_at, a waitlist window. currency is what every amount is denominated in, and amounts are in its minor unit. Read both once and apply them everywhere rather than inferring a zone from an offset.

Policy is not inventory

min_party_size and max_party_size are the range the restaurant accepts online, and a request outside it is refused with party_size_too_small or party_size_too_large. A size inside the range can still be refused with no_table_available, because the table inventory decides what can actually be seated. The sizes that can be seated on a given day are party_sizes on availability.

When it changes

It changes whenever a manager changes a setting. Read it at start-up, hold it, and revalidate with If-None-Match, which is cheap. No webhook announces a change.