Skip to content
Maple

    Resources

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

    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.

    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.

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

    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.

    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.

    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.

    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. See Errors.

    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.

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

    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.
    • Five waitlist webhook types (waitlist_entry.created, .notified, .seated, .removed, .expired) carrying the entry’s latest state. See 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.

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

    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.

    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.