Estados
Elstatus del recurso del pedido siempre es uno de estos nueve valores:
FULFILLED, REJECTED, STORE_CANCELLED y CUSTOMER_CANCELLED son terminales: un pedido en uno de estos estados ya no cambiará.
Usted establece el estado mediante los endpoints de decisión.
PENDING, AUTO_ACCEPTED y CUSTOMER_CANCELLED son estados del sistema que usted observará pero nunca establecerá.Cómo fluye
El camino ideal esPENDING → ACCEPTED → READY → FULFILLED, con IN_DELIVERY entre READY y FULFILLED en los pedidos a domicilio. Desde PENDING usted acepta o rechaza. Después de aceptar, todavía puede cancelar (STORE_CANCELLED) hasta que el pedido se complete. Que el cliente cancele (CUSTOMER_CANCELLED) puede interrumpir cualquier estado no terminal y llega como un webhook order.cancelled.
Las transiciones se validan: una decisión que no es válida desde el estado actual se rechaza. Como toda decisión es segura ante repeticiones, repetirla es inofensivo.
Cómo se traducen sus decisiones en estados
Cuándo se envía cada webhook
Aquí se ve dónde cae cada webhook a lo largo de la vida de un pedido. Las flechas punteadas son webhooks que Maple le envía; las flechas sólidas son llamadas que usted hace de vuelta.order.created: el pedido ya existe. Se envía use o no la validación.order.validation_requested(solo si se suscribió): Maple le pide confirmar que el pedido se puede preparar y espera suvalidation_result. Un resultadoinvalidrechaza el pedido aquí, así que nunca llega a la notificación.order.notification: el pedido se le entrega para prepararlo. Usted haceaccept(odeny) y luego informareadyycomplete.order.paid: el pago se liquidó. Su posición varía: un pedido con pago mediante enlace puede pagarse antes de la notificación, mientras que un pedido con pago en el local se paga después; no suponga que llega en un punto fijo.order.cancelled: el cliente o el local canceló. Puede llegar casi en cualquier momento después de la creación, incluso después de que usted empezó a prepararlo. Deténgase cuando llegue.
accept, ready, complete) regresa como webhook, y no hay un evento para cada cambio de estado; vea abajo.
Los webhooks no siguen cada transición
No hay un webhook para cada cambio de estado. Maple emite un conjunto fijo de eventos de pedido:order.notification, order.created, order.paid, order.cancelled y, si se suscribe, order.validation_requested. Las transiciones que usted impulsa (accept, ready, complete) no se le devuelven, y no hay un evento para llegar a IN_DELIVERY ni para que el pago pase a refunded, voided o failed.
Por eso, el recurso del pedido es la fuente de verdad del estado actual, no el flujo de eventos. Cuando necesite saber en qué punto está un pedido, lea GET /v1/orders/{orderId}. Los webhooks le avisan que algo ocurrió; el recurso le dice el estado. Consulte Webhooks.
Tipo de entrega
Cada pedido incluye unfulfillment_type, uno de:
Los pedidos a domicilio también 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.
El pago es de solo lectura
Maple es dueño de todo el ciclo de pago del cliente, de principio a fin. El pago nunca es algo que usted cree o cambie: no existe un endpoint de pagos. Solo lo lee, como campos del pedido:payment_status y payment.status son el mismo valor, uno de:
payment_link_url es el enlace alojado por Maple mediante el cual el cliente paga. Es null en pedidos con pago en el local y antes de que se haya creado un enlace. Trate todo esto como autorizado y de solo lectura; consulte Cómo funciona Maple.