Administre las entregas en la consola
Los miembros invitados de la organización pueden abrir Developers → app → Webhooks sin ingresar una clave de API. La app necesitawebhooks:read para diagnósticos y webhooks:write para modificaciones. Las acciones salientes también requieren una app activa.
- Endpoints: cree o edite un endpoint, guarde su secreto de firma de un solo uso, envíe una prueba de forma explícita o deshabilítelo y vuelva a habilitarlo. Es preferible deshabilitar para conservar el historial de entregas. Las apps suspendidas siguen siendo consultables y sus endpoints todavía se pueden deshabilitar.
- Deliveries: filtre las entregas ordinarias y las pruebas firmadas por endpoint, tipo de evento, resultado y rango de tiempo. Consulte el estado agregado, el número de intentos, el último estado de respuesta, el error seguro y las marcas de tiempo. Esto no es una línea de tiempo por intento. Las URL y el estado del endpoint que se muestran son la configuración actual, no copias históricas del destino.
- Events: inspeccione los metadatos de eventos de negocio que se pueden reenviar. Review event muestra una vista previa de un reintento a nivel de evento; Confirm retry intenta los destinos elegibles y omite los pares ya exitosos, los endpoints deshabilitados y los endpoints que ya no están suscritos. Si los destinos cambian, revise una vista previa nueva antes de confirmar.
2xx, no que se haya verificado su firma. Las entregas de prueba sin un evento de negocio reenviable ofrecen Send another test. Ni una fila pendiente en el registro ni el fallo de una acción manual demuestran que haya otro intento programado.
La consola expone metadatos, no los payloads completos de los eventos, los cuerpos de respuesta del receptor, los secretos ni los rastreos internos. La API pública de eventos autenticada que se describe más abajo es independiente. La guía Webhook format and signature verification contiene únicamente ejemplos sintéticos que puede copiar; abrirla no envía ninguna solicitud ni genera una firma con su secreto.
Pruebe el flujo completo de pedidos
Para integraciones de pedidos, abra Developers → app → Test orders en el panel del sandbox. Seleccione un local de prueba autorizado y confirme Create test order. La app necesitaorders:write, debe estar activa y debe ser el receptor activo de pedidos en modo de prueba del local. Maple debe poder preparar un artículo del menú con existencias y sin modificadores obligatorios.
Esto crea un pedido real para recoger con pago en el local, a través del flujo normal, incluidas las integraciones de webhook e impresora configuradas. La acción no cobra ninguna tarjeta. Use un local de sandbox aislado; no es lo mismo que Send test en un endpoint de webhook. La creación tiene un límite por local (tres por minuto de forma predeterminada) y no está disponible si no se puede consultar el almacén de presupuestos.
Con orders:read, el rastreador de resultados muestra la validación, la entrega de notificaciones y la decisión del socio para los últimos diez pedidos asociados con esta app, entorno y local. Los pedidos nuevos aparecen después de que el flujo registra la validación o un evento de webhook. Actualice antes de reenviar tras un resultado incierto; una lista vacía no demuestra que la creación haya fallado. Esta herramienta no reemplaza la verificación de solicitudes a la API con su propia clave.
Location settings → Integrations → Connected apps del comercio conserva los controles de conexión y acceso. Las herramientas de prueba para desarrolladores ahora están en la consola a nivel de organización.
El sobre del evento
Todas las entregas tienen el mismo sobre al estilo de Stripe. El payloaddata es específico de cada evento:
string
Id único del evento. Elimine duplicados con este valor: la entrega es al menos una vez.
string
El tipo de evento. Úselo para enrutar el evento.
number
Segundos Unix en que se creó el evento.
object
Payload específico del evento.
order.notification incluye el contenido completo del pedido; los eventos de ciclo de vida (order.created, order.paid, order.cancelled) incluyen campos de resumen. Consulte Eventos de webhook para ver cada payload y use GET /v1/orders/{orderId} para obtener el estado actual autorizado.Tipos de evento
Suscríbase solo a lo que procesa. El catálogo vigente siempre está enGET /v1/webhook_event_types:
El endpoint de prueba también entrega
webhook.test a solicitud, para que pueda verificar un controlador antes de recibir tráfico real.
Estos son eventos discretos, no un flujo de estados. Maple no envía un webhook por cada cambio de estado de un pedido:
las transiciones que usted mismo realiza (
accept, ready, complete) no se devuelven y no existe un evento por
transición. Para conocer el estado actual de un pedido, lea GET /v1/orders/{orderId}. Consulte el Ciclo de vida del
pedido.bookings:read y se entregan para los locales autorizados; consulte Eventos de reserva.
Suscripción
Response
notification_url debe ser HTTPS pública; las direcciones privadas e internas se rechazan. Administre las suscripciones con GET, PATCH (actualiza la URL, los tipos de evento o el estado enabled/disabled) y DELETE en /v1/webhook_subscriptions/{id}. Actualizar una suscripción no cambia su secreto de firma.
Varias suscripciones
Puede registrar más de una suscripción. Cada suscripción habilitada cuyosevent_types incluyan un evento disparado recibe su propia entrega firmada, cada una con su propio secreto de firma, por lo que se permite que los event_types de distintas suscripciones se solapen. Esto le permite distribuir por destino: por ejemplo, dirigir los eventos de pedido a su servicio de preparación y los eventos menu.sync.* a un endpoint de administración interna distinto. El reenvío sigue el mismo enrutamiento y omite cualquier suscripción que ya haya recibido el evento.
Verificación de la firma
Cada entrega incluye dos encabezados:maple-webhook-id— el id del evento.maple-webhook-signature—t=<unix_seconds>,v1=<hex_hmac>.
Garantías de entrega
- Al menos una vez. El mismo evento puede llegar más de una vez. Elimine duplicados con el
iddel sobre y haga que su controlador sea idempotente. - Responda rápido. Devuelva un
2xxde inmediato y realice el trabajo más lento de forma asíncrona. Cualquier respuesta que no sea2xx(o un tiempo de espera agotado) cuenta como una entrega fallida. - No se garantiza el orden. No suponga que los eventos llegan en el orden en que ocurrieron; concilie con el recurso del pedido cuando la secuencia importe.
Reintentos y deshabilitación automática
La entrega duradera de eventos de negocio usa hasta 9 intentos de forma predeterminada: el primero de inmediato y los demás con un retraso creciente. Los primeros intentos caben dentro de la ventana de decisión de seis minutos del POS, mientras que la cola larga permite conciliar después de una interrupción real:
Una respuesta que no sea
2xx (o un tiempo de espera agotado; el límite por intento es de 15 segundos) hace fallar ese intento. Un evento que falla los 9 intentos cuenta como una entrega totalmente fallida. Después de 5 entregas totalmente fallidas consecutivas (cinco eventos distintos que agotaron todos los intentos), la suscripción se deshabilita automáticamente; una sola entrega exitosa reinicia el contador a cero. Vuelva a habilitarla con un PATCH que establezca status de nuevo en enabled cuando su endpoint esté en buen estado y luego reenvíe lo que se haya perdido.
Registro de eventos
Los eventos de negocio publicados se registran para conciliación y reenvío. Las entregas de prueba firmadas sintéticas tienen registros en el registro de entregas, pero no una fila reenviable en el registro de eventos; envíe otra prueba explícita en su lugar.GET /v1/webhook_events— sus eventos recientes, del más reciente al más antiguo (hasta 50). Útil para conciliación y depuración.GET /v1/webhook_events/{eventId}— un solo evento, con su payloaddatacompleto.POST /v1/webhook_events/{eventId}/replay— intenta la entrega a las suscripciones habilitadas que coinciden actualmente, omitiendo los pares con un éxito registrado. Reutiliza el id del evento y no fuerza la reentrega de lo ya exitoso. Los intentos concurrentes o un resultado incierto de red o de persistencia aún pueden producir duplicados; el receptor debe eliminarlos. Los intentos manuales fallidos son definitivos y no programan reintentos automáticos.
since como su último punto de control exitoso y avance en orden: solicite GET /v1/orders?since=<checkpoint>&limit=100 y repita con starting_after=<last-order-id> mientras has_more sea true. Con since, los resultados van del más antiguo al más reciente, de modo que se recorre todo el atraso sin omitir pedidos que comparten una marca de tiempo. Obtenga el recurso autorizado del pedido y luego llame a POST /v1/orders/{orderId}/resend solo para un pedido activo que no recibió su webhook. El reenvío crea un order.notification firmado nuevo con una identidad de evento nueva y nunca cambia el estado del pedido. Los pedidos en estado terminal (REJECTED, CUSTOMER_CANCELLED o STORE_CANCELLED) no se pueden reenviar ni reactivar; concílielos con GET /v1/orders?since=... y GET /v1/orders/{orderId}.
Prueba de su controlador
webhook.test firmado y devuelve si se entregó y el estado HTTP que devolvió su endpoint:
2xx, y verifique la firma en su propio receptor. La respuesta no certifica el manejo de la firma. Es un solo intento; un valor delivered en false o un estado de respuesta nulo no debe interpretarse como un reintento automático pendiente.
Lista de verificación
Verifique la firma HMAC de cada entrega contra el cuerpo sin procesar y rechace las marcas de tiempo vencidas.
Elimine duplicados con el
id del sobre; haga que los controladores sean idempotentes.Devuelva
2xx rápido; procese de forma asíncrona.Suscríbase solo a los tipos de evento que procesa.
Monitoree las suscripciones deshabilitadas automáticamente y reenvíe desde el registro después de una interrupción.