Skip to main content
Changes to the Developer API surface — new endpoints, new event types, and behavior changes — are recorded here. The endpoint reference always reflects the current state.
​
Experiences
  • Availability lists experiences (prix fixe, tastings, ticketed seatings) where the location offers them, alongside standard slots in start order. Each booking_slot has an experience (id, name, description, prepayment_required), null for a standard reservation. experience_id narrows a search to one experience. Offered at OpenTable locations; booking_profile.capabilities.experiences says whether a location offers them.
  • An experience slot books through the usual hold and booking flow, and the Booking resource (and its webhook payloads) carries experience (id, name), null for a standard reservation. A change keeps the experience: a slot for a different experience, or between an experience and a standard table, answers 422 capability_unsupported.
  • Holding a slot whose experience asks for payment up front answers 422 payment_instrument_required: Maple can’t take payment yet. See Experiences.
​
Seated reservations at OpenTable locations
  • At OpenTable-managed locations, changing or cancelling a reservation the party is already seated at, or one that is over, now answers 409 not_changeable or 409 not_cancellable (reason in_service or terminal_state) before Maple calls OpenTable, as it already did at Maple-native locations.
​
Venues control guest texts
  • Restaurant managers can now turn Maple’s guest texts off for their location. Where they have, POST /v1/waitlist_entries/{entryId}/notify answers 422 guest_messaging_unavailable, as it already did where guest texts aren’t rolled out. Seat or remove the party instead. See Run the waitlist.
  • Managers can also turn Maple bookings on themselves once a configuration is published, so booking_profile.enabled can change without Maple’s involvement. Keep checking it before offering availability.
​
Configuration revisions
  • The booking configuration carries a revision. Publish with expected_revision to get 409 stale_configuration instead of overwriting a configuration a restaurant manager edited in the Maple dashboard since your read; null expects no configuration yet. Publishing without it still replaces the configuration unconditionally. See Publish without overwriting the venue.
​
Every seating area is bookable
  • Maple-native availability now seats parties in every configured area, not only the first: it tries the first area, then the others in poolId order, and books the first with a free table or combination that fits. A party only another area can seat (a large table on the patio) is now offered. Party-size bounds span all areas. See Publication rules.
​
Find bookings by phone or confirmation code
  • GET /v1/bookings takes phone and confirmation_code to find the booking a guest is asking about. Both require location_id; the phone is normalized first. Without a window a lookup matches bookings at any time, at native and provider-managed locations alike. A lookup without location_id answers 400 location_required. See Find a guest’s booking.
​
Booking blackout dates
  • GET /v1/locations/{locationId}/booking_profile returns the location’s blackout_dates: windows when it takes no reservations.
  • PUT /v1/locations/{locationId}/booking_blackouts replaces the list under bookings:configure, at native and provider-managed locations. Send the profile’s blackout_dates_revision as expected_revision to get 409 stale_blackout_dates instead of overwriting the venue’s newer edits. Invalid ranges answer 400 invalid_blackout_dates. See Blackout dates.
​
Validation errors and the feedback hint
  • A request whose path parameters, query, headers or body fail validation now answers 400 with a DeveloperApiBadRequest body (code: "invalid_request") naming the field, where it used to answer with an empty body.
  • Every error body carries a feedback line pointing to POST /v1/feedback. See Errors.
​
Feedback
  • POST /v1/feedback reports a bug, a missing capability, wrong docs, or an unclear error, citing the ids of the requests involved. Only kind and summary are required. An id Maple cannot match to your recent requests is kept as sent rather than refused. Any credential may send it; no scope is required. Its contract will not break: fields may be added, never removed or made required. See Feedback.
​
Walk-ins and venue-side cancellation
  • POST /v1/locations/{locationId}/walk_ins seats an arriving party at the earliest table that fits now and returns the seated booking, retry-safe under an app-scoped idempotency_key. See Seat a walk-in.
  • POST /v1/bookings/{id}/venue_cancel cancels on the venue’s behalf (cancelled_by_venue), outside the guest’s cancellation window. See Cancel as the venue.
  • Both require bookings:manage and are available at Maple-native locations. The API reference now lists the waitlist under its own section.
​
Waitlist
  • Read a native location’s walk-in queue and quote waits under bookings:read.
  • Add parties with an app-scoped idempotency_key, and cancel them for the guest, under bookings:write.
  • Notify, seat, and remove parties, and open or close the waitlist, under bookings:manage. Maple sends every guest text; seating creates a walk-in booking. See Run the waitlist.
  • Five waitlist webhook types (waitlist_entry.created, .notified, .seated, .removed, .expired) carrying the entry’s latest state. See Waitlist events.
​
Delivery zones
  • Delivery zone CRUD for connected locations — list, create, get, update, and delete zones under delivery_zones:read / delivery_zones:write, scoped to your app’s active connection.
  • POST /v1/locations/{locationId}/delivery_zones/check reports whether a coordinate is deliverable and returns the matching zone and fee. See Manage delivery zones.
​
Bookings — per-location rollout
  • Booking profile, bounded availability search, holds, and booking list/get/create/change/cancel.
  • Venue actions under bookings:manage, with version checks and app-attributed audit records.
  • Native configuration publish/read under bookings:configure, preserving existing menus.
  • On-demand live floor, eight booking webhook types, and optional booking sandbox provisioning.
  • App-owned native/provider holds, atomic ten-hold quotas per app/location, and separate booking request/search throttles with Retry-After.
  • Durable provider-write claims, version reservations, stable request identities, and reconciliation after uncertain writes or mirror failures. See Take bookings for retry rules.
​
Delivery addresses, order catch-up, and denser webhook retries
  • Delivery addresses — the order resource and the order.notification payload now carry delivery_address (street, unit, city, state, ZIP, and the customer’s delivery instructions in notes). It is null for pickup orders and for delivery orders with no stored address. See Receiving orders.
  • Order catch-up — GET /v1/orders accepts since, starting_after, and limit. With since, results drain oldest first from an exclusive checkpoint so you can page through a backlog after downtime. See Lists.
  • Order resend — POST /v1/orders/{orderId}/resend publishes a fresh order.notification for one live order that missed its webhook, without changing order state. Requires webhooks:write; terminal orders can’t be resent.
  • Denser webhook retries — a failed delivery is now retried up to 9 times (was 6), with the early attempts inside the six-minute POS decision window. See Retries and auto-disable.
​
Developer API launch
The Maple Developer API is available for POS and platform partners.
  • Authentication — API keys (mpk_test_… for the sandbox, mpk_live_… for production) with scoped access.
  • Locations and connections — list granted locations and connect as a location’s order receiver.
  • Orders — receive order.notification, read the full order, and decide it with accept / deny / ready / complete / cancel / status. Optional pre-validation.
  • Menu — publish a location’s full menu as one JSON document keyed by your own external IDs, and read it back.
  • Webhooks — subscribe to event types, verify HMAC-signed deliveries, and replay from the event ledger.