Appearance
Los dos escenarios
Hay dos formas de integrar, y las dos son válidas. Elige según cómo trabaja la tienda.
1. Directo: al delivery que ya elegiste
La tienda trabaja con un delivery. Cada venta con envío se convierte en un pedido en ese delivery en el momento en que se confirma.
Tu sistema ──POST /v1/orders──▶ Delivery ──▶ motorizadoEs el escenario que la API cubre hoy: la llave es del delivery, y con ella el pedido entra directo a su bandeja de recepción. El despachador lo ve, lo recibe cuando llega el paquete y lo asigna.
Qué hacer en tu sistema:
- Al confirmar la venta,
POST /v1/orders. - Guardar
idyguide_codeen tu venta. - Registrar un webhook para
order.deliveredyorder.cancelledy cerrar la venta cuando llegue.
2. Bandeja: a tu tienda, y de ahí a uno u otro delivery
La tienda trabaja con varios deliveries y decide a cuál mandar cada pedido: por distrito, por día, por quién contestó primero. Los pedidos entran a la bandeja de la tienda en Motochaski, y desde su panel alguien los despacha.
Tu sistema ──POST /v1/orders──▶ Bandeja de la tienda ──▶ Delivery A
└──▶ Delivery BPendiente
Este escenario todavía no está disponible por API. Hoy el pedido siempre entra a un delivery concreto (el dueño de la llave). Cuando esté, será el mismo endpoint con un campo operator opcional: presente → escenario 1, ausente → escenario 2. Ver Pendiente.
Mientras tanto, una tienda con dos deliveries pide una llave a cada uno y elige en su sistema a cuál mandar cada pedido. Es el escenario 1 dos veces.
Un pedido va a un solo delivery
"Varios deliveries" significa que la tienda reparte sus pedidos entre operadores, no que un pedido vaya a dos. Un pedido siempre tiene un delivery, un motorizado y un código de guía.
¿Y si mi cliente no es una tienda sino el delivery?
Si el que integra es el propio operador —para llevar su contabilidad, su tablero, su sistema de nómina—, usa una llave sin tienda: ve todos los pedidos del delivery y los webhooks le llegan de todas sus tiendas. Los endpoints son los mismos.