> ## Documentation Index
> Fetch the complete documentation index at: https://docs.maple.inc/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Notable changes to the Maple Developer API.

Changes to the Developer API surface — new endpoints, new event types, and behavior changes — are recorded here. The [endpoint reference](https://docs.maple.inc/developer-api/api-reference.md) always reflects the current state.

October 2026

## OpenTable refusals use the native codes

- At OpenTable-managed locations, a refusal OpenTable gives a reason for now answers with the code a Maple-native location gives, in Maple’s words, instead of `422 provider_rejected` with OpenTable’s text. A time too soon answers `422 outside_booking_window` (`details.reason: inside_min_lead`); a reservation that has started or is about to `409 not_changeable` / `409 not_cancellable` (`details.reason: outside_policy_window`); a time that needs a card `422 payment_instrument_required`. Other refusals stay `provider_rejected`. See [Errors](https://docs.maple.inc/developer-api/concepts/errors.md#booking-error-codes).

October 2026

## Change only a booking's note

- `POST /v1/bookings/{bookingId}/change` takes `notes` without `slot_token` to change only the guest’s note: the booking keeps its time, party size and table, so no quote is needed. Sending neither field answers `400 change_required`. See [Change or cancel](https://docs.maple.inc/developer-api/guides/take-bookings.md#5-change-or-cancel).

September 2026

## 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](https://docs.maple.inc/developer-api/guides/take-bookings.md#experiences).

September 2026

## 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.

September 2026

## 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](https://docs.maple.inc/developer-api/guides/run-the-waitlist.md).
- 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.

September 2026

## 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](https://docs.maple.inc/developer-api/guides/configure-bookings.md#publish-without-overwriting-the-venue).

September 2026

## 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](https://docs.maple.inc/developer-api/guides/configure-bookings.md#publication-rules).

September 2026

## 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](https://docs.maple.inc/developer-api/guides/take-bookings.md#find-a-guests-booking).

September 2026

## 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](https://docs.maple.inc/developer-api/guides/configure-bookings.md#blackout-dates).

September 2026

## 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`](https://docs.maple.inc/developer-api/concepts/feedback.md). See [Errors](https://docs.maple.inc/developer-api/concepts/errors.md).

September 2026

## 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](https://docs.maple.inc/developer-api/concepts/feedback.md).

September 2026

## 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](https://docs.maple.inc/developer-api/concepts/booking-lifecycle.md#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](https://docs.maple.inc/developer-api/concepts/booking-lifecycle.md#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.

September 2026

## 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](https://docs.maple.inc/developer-api/guides/run-the-waitlist.md).
- Five waitlist webhook types (`waitlist_entry.created`, `.notified`, `.seated`, `.removed`, `.expired`) carrying the entry’s latest state. See [Waitlist events](https://docs.maple.inc/developer-api/webhook-events.md#waitlist-events).

September 2026

## 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](https://docs.maple.inc/developer-api/guides/delivery-zones.md).

September 2026

## 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](https://docs.maple.inc/developer-api/guides/take-bookings.md) for retry rules.

August 2026

## 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](https://docs.maple.inc/developer-api/guides/receive-orders.md#step-4--read-the-order).
- **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](https://docs.maple.inc/developer-api/api-reference.md#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](https://docs.maple.inc/developer-api/concepts/webhooks.md#retries-and-auto-disable).

August 2026

## Customer phone and scheduled orders

- **Scheduled orders** — the order resource and the `order.notification` payload now carry `scheduled_for`: the requested ready time as an ISO 8601 UTC timestamp, or `null` for an order wanted as soon as possible.
- **Customer phone** — `customer.phone` (E.164, or `null`) and `customer.phone_last_four` are now included on orders and in `order.notification`. See [Receiving orders](https://docs.maple.inc/developer-api/guides/receive-orders.md#step-4--read-the-order).

June 2026

## 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.
