Skip to main content
Aquí se registran los cambios en la superficie de la Developer API: nuevos endpoints, nuevos tipos de evento y cambios de comportamiento. La referencia de endpoints siempre refleja el estado actual.
​
Los rechazos de OpenTable usan los códigos nativos
  • En los locales administrados por OpenTable, un rechazo para el que OpenTable da un motivo ahora responde con el mismo código que un local nativo de Maple, con las palabras de Maple, en lugar de 422 provider_rejected con el texto de OpenTable. Una hora demasiado próxima responde 422 outside_booking_window (details.reason: inside_min_lead); una reserva que ya empezó o está por empezar, 409 not_changeable / 409 not_cancellable (details.reason: outside_policy_window); una hora que requiere tarjeta, 422 payment_instrument_required. Los demás rechazos siguen siendo provider_rejected. Consulte Errores.
​
Cambie solo la nota de una reserva
  • POST /v1/bookings/{bookingId}/change acepta notes sin slot_token para cambiar solo la nota del huésped: la reserva conserva su hora, el tamaño del grupo y la mesa, por lo que no se necesita una cotización. Si no se envía ninguno de los dos campos, responde 400 change_required. Consulte Cambiar o cancelar.
​
Experiencias
  • La disponibilidad lista las experiencias (menús fijos, degustaciones, turnos con boleto) donde el local las ofrece, junto con los horarios estándar en orden de inicio. Cada booking_slot tiene un experience (id, name, description, prepayment_required), null para una reserva estándar. experience_id limita una búsqueda a una experiencia. Se ofrecen en locales de OpenTable; booking_profile.capabilities.experiences indica si un local las ofrece.
  • Un horario de experiencia se reserva con el flujo habitual de retención y reserva, y el recurso Booking (y sus payloads de webhook) incluye experience (id, name), null para una reserva estándar. Un cambio conserva la experiencia: un horario de otra experiencia, o entre una experiencia y una mesa estándar, responde 422 capability_unsupported.
  • Retener un horario cuya experiencia pide pago por adelantado responde 422 payment_instrument_required: Maple todavía no puede cobrar. Consulte Experiencias.
​
Reservas con el grupo ya sentado en locales de OpenTable
  • En los locales administrados por OpenTable, cambiar o cancelar una reserva cuyo grupo ya está sentado, o que ya terminó, ahora responde 409 not_changeable o 409 not_cancellable (motivo in_service o terminal_state) antes de que Maple llame a OpenTable, como ya ocurría en los locales nativos de Maple.
​
Los establecimientos controlan los mensajes a huéspedes
  • Los gerentes de restaurante ahora pueden desactivar los mensajes de texto de Maple a los huéspedes de su establecimiento. Donde lo hicieron, POST /v1/waitlist_entries/{entryId}/notify responde 422 guest_messaging_unavailable, como ya ocurría donde los mensajes a huéspedes no están habilitados. Siente o retire al grupo. Consulte Administre la lista de espera.
  • Los gerentes también pueden activar por sí mismos las reservas de Maple una vez publicada una configuración, así que booking_profile.enabled puede cambiar sin intervención de Maple. Siga verificándolo antes de ofrecer disponibilidad.
​
Revisiones de configuración
  • La configuración de reservas incluye un revision. Publique con expected_revision para recibir 409 stale_configuration en lugar de sobrescribir una configuración que un gerente del restaurante editó en el panel de Maple desde su lectura; null espera que aún no haya configuración. Publicar sin él sigue reemplazando la configuración sin condiciones. Consulte Publique sin sobrescribir al local.
​
Todas las áreas de asientos se pueden reservar
  • La disponibilidad nativa de Maple ahora sienta a los grupos en todas las áreas configuradas, no solo en la primera: prueba la primera área, luego las demás en orden de poolId, y reserva la primera que tenga una mesa o combinación libre que quepa. Ahora se ofrece un grupo que solo otra área puede sentar (una mesa grande en el patio). Los límites de tamaño de grupo abarcan todas las áreas. Consulte Reglas de publicación.
​
Busque reservas por teléfono o código de confirmación
  • GET /v1/bookings acepta phone y confirmation_code para encontrar la reserva por la que pregunta un huésped. Ambos requieren location_id; el teléfono se normaliza primero. Sin una ventana de tiempo, la búsqueda encuentra reservas en cualquier fecha, tanto en locales nativos como administrados por un proveedor. Una búsqueda sin location_id responde 400 location_required. Consulte Encuentre la reserva de un huésped.
​
Fechas bloqueadas para reservas
  • GET /v1/locations/{locationId}/booking_profile devuelve los blackout_dates del local: periodos en los que no recibe reservas.
  • PUT /v1/locations/{locationId}/booking_blackouts reemplaza la lista con el alcance (scope) bookings:configure, en locales nativos y administrados por un proveedor. Envíe el blackout_dates_revision del perfil como expected_revision para recibir 409 stale_blackout_dates en lugar de sobrescribir las ediciones más recientes del establecimiento. Los rangos no válidos responden 400 invalid_blackout_dates. Consulte Fechas bloqueadas.
​
Errores de validación y la pista de comentarios
  • Una solicitud cuyos parámetros de ruta, consulta, encabezados o cuerpo no superan la validación ahora responde 400 con un cuerpo DeveloperApiBadRequest (code: "invalid_request") que nombra el campo, donde antes respondía con un cuerpo vacío.
  • Todo cuerpo de error incluye una línea feedback que apunta a POST /v1/feedback. Consulte Errores.
​
Comentarios
  • POST /v1/feedback reporta un error, una capacidad que falta, documentación incorrecta o un error poco claro, citando los ids de las solicitudes involucradas. Solo kind y summary son obligatorios. Un id que Maple no pueda asociar con sus solicitudes recientes se conserva tal como se envió en lugar de rechazarse. Cualquier credencial puede enviarlo; no se requiere alcance. Su contrato no se romperá: se pueden agregar campos, nunca eliminarlos ni volverlos obligatorios. Consulte Comentarios.
​
Clientes sin reserva y cancelación por parte del establecimiento
  • POST /v1/locations/{locationId}/walk_ins sienta a un grupo que llega en la mesa más próxima donde quepa ahora y devuelve la reserva con el grupo sentado; es seguro reintentar con un idempotency_key limitado a su app. Consulte Siente a un cliente sin reserva.
  • POST /v1/bookings/{id}/venue_cancel cancela en nombre del establecimiento (cancelled_by_venue), fuera de la ventana de cancelación del huésped. Consulte Cancele como el establecimiento.
  • Ambos requieren bookings:manage y están disponibles en locales nativos de Maple. La referencia de la API ahora muestra la lista de espera en su propia sección.
​
Lista de espera
  • Lea la cola de clientes sin reserva de un local nativo y cotice esperas con bookings:read.
  • Agregue grupos con un idempotency_key limitado a su app, y cancélelos en nombre del huésped, con bookings:write.
  • Notifique, siente y retire grupos, y abra o cierre la lista de espera, con bookings:manage. Maple envía todos los mensajes a los huéspedes; sentar crea una reserva de cliente sin reserva. Consulte Administre la lista de espera.
  • Cinco tipos de webhook de lista de espera (waitlist_entry.created, .notified, .seated, .removed, .expired) con el estado más reciente de la entrada. Consulte Eventos de lista de espera.
​
Zonas de entrega
  • CRUD de zonas de entrega para locales conectados: liste, cree, obtenga, actualice y elimine zonas con delivery_zones:read / delivery_zones:write, dentro de la conexión activa de su app.
  • POST /v1/locations/{locationId}/delivery_zones/check indica si una coordenada tiene entrega y devuelve la zona y la tarifa correspondientes. Consulte Administre las zonas de entrega.
​
Reservas — lanzamiento por local
  • Perfil de reservas, búsqueda acotada de disponibilidad, retenciones, y listar/obtener/crear/cambiar/cancelar reservas.
  • Acciones del establecimiento con bookings:manage, con verificación de versiones y registros de auditoría atribuidos a la app.
  • Publicación y lectura de configuración nativa con bookings:configure, conservando los menús existentes.
  • Plano del local en vivo bajo demanda, ocho tipos de webhook de reservas y aprovisionamiento opcional de sandbox de reservas.
  • Retenciones nativas y de proveedor propiedad de la app, cuotas atómicas de diez retenciones por app y local, y límites separados para solicitudes y búsquedas de reservas con Retry-After.
  • Reclamos duraderos de escritura al proveedor, reservas de versión, identidades de solicitud estables y reconciliación tras escrituras inciertas o fallas del espejo. Consulte Tome reservas para las reglas de reintento.
​
Direcciones de entrega, puesta al día de pedidos y reintentos de webhook más densos
  • Direcciones de entrega: el recurso del pedido y el payload de order.notification ahora incluyen delivery_address (calle, unidad, ciudad, estado, código postal y las instrucciones de entrega del cliente en notes). Es null en pedidos para recoger y en pedidos a domicilio sin dirección guardada. Consulte Recibir pedidos.
  • Puesta al día de pedidos: GET /v1/orders acepta since, starting_after y limit. Con since, los resultados se vacían del más antiguo al más reciente desde un punto de control exclusivo, para que pueda recorrer un rezago tras una caída. Consulte Listas.
  • Reenvío de pedidos: POST /v1/orders/{orderId}/resend publica un order.notification nuevo para un pedido activo que no recibió su webhook, sin cambiar el estado del pedido. Requiere webhooks:write; los pedidos en estado terminal no se pueden reenviar.
  • Reintentos de webhook más densos: una entrega fallida ahora se reintenta hasta 9 veces (antes 6), con los primeros intentos dentro de la ventana de decisión del POS de seis minutos. Consulte Reintentos y desactivación automática.
​
Lanzamiento de la Developer API
La Developer API de Maple está disponible para socios de POS y de plataformas.
  • Autenticación: claves de API (mpk_test_… para el sandbox, mpk_live_… para producción) con acceso por alcances.
  • Locales y conexiones: liste los locales autorizados y conéctese como receptor de pedidos de un local.
  • Pedidos: reciba order.notification, lea el pedido completo y decídalo con accept / deny / ready / complete / cancel / status. Prevalidación opcional.
  • Menú: publique el menú completo de un local como un solo documento JSON con sus propios IDs externos, y léalo de vuelta.
  • Webhooks: suscríbase a tipos de evento, verifique entregas firmadas con HMAC y repita desde el registro de eventos.