Skip to main content
​
POS Bridge — backlog visible, reintentos y semántica de errores
  • GET /v1/orders: la respuesta suma total (cuántos pedidos hay en ese estado, no solo los de esta página) y has_more. Antes, con 35 pendientes veías lo mismo que con 20 y nada te indicaba pedir page=2.
  • POST /v1/orders/{order_id}/status: un evento rechazado ya no consume su event_id. Si el request falla por validación (por ejemplo, falta el motivo), podés corregirlo y reintentar con el mismo id, y esta vez se aplica. Antes ese reintento devolvía duplicate: true sin aplicar el cambio.
  • Guía nueva en Estados: qué significa cada código de error (400 / 403 rate-limit / 403 key inválida / 404) y cuál conviene reintentar, más una nota sobre las cancelaciones que no salen de tu POS (el cliente cancela, o expira el pedido) y cómo detectarlas.
Cambios aditivos: nada de lo anterior se rompe.
​
POS Bridge — monto del pago y guía de nulls
  • GET /v1/orders: el objeto pago suma monto (igual a total, envío incluido; 0 si no hay total) — para calcular el vuelto en pagos en efectivo.
  • Nueva guía “Qué puede venir en null” en el quickstart: qué campos del pedido pueden llegar en null y qué default usar en cada caso. El OpenAPI marca ahora todos los campos anulables (nullable: true), incluido cliente.nombre.
Cambios aditivos: nada de lo anterior se rompe.
​
POS Bridge — pedidos de prueba
POST /v1/test/orders — generá pedidos de prueba en tu sucursal sandbox usando tus códigos de producto y sabor. Mismo circuito de validación y cotización que el bot; el pedido nace pendiente y aparece en tu próximo poll con todos los campos (domicilio, teléfono separado, pago, costo de envío). Pensado para que pruebes el ciclo completo sin esperar a que el bot esté conectado.
​
POS Bridge — pago, fecha legible y aceptación implícita
Segunda ronda de feedback de integración, aplicada.
  • GET /v1/orders: nuevo objeto pago (modo: en_entrega | online, pagado) para el cierre de caja — hoy todo nace en_entrega; cuando un local active pago online por WhatsApp llegará online / pagado: true sin cambios de contrato.
  • GET /v1/orders: nuevo campo costo_envio (fijo por local, incluido en total) y created_at_iso (ISO 8601 con zona del local) junto al epoch existente.
  • POST /v1/orders/{order_id}/status: aceptación implícita — listo, asignado o entregado sobre un pedido pendiente lo acepta y lo mueve en un solo evento. Los pedidos cerrados siguen siendo inmutables.
Cambios aditivos: nada de lo anterior se rompe.
​
POS Bridge — domicilio y teléfono estructurados
Feedback de la primera ronda de integración, aplicado.
  • GET /v1/orders: cada pedido incluye ahora domicilio estructurado (calle, numero, piso_depto, localidad, referencia) además de delivery_address completo como respaldo.
  • GET /v1/orders: el teléfono del cliente viene también separado en telefono_pais (default "54"), telefono_area y telefono_numero (limpio, sin guiones ni espacios).
  • POST /v1/orders/{order_id}/status: nuevo evento asignado — si tu flujo asigna repartidor directo tras aceptar, podés saltear listo (en_preparacion → asignado → entregado).
  • GET /v1/orders?status=: se pueden consultar también asignado y en_camino.
Los campos nuevos son aditivos: si ya integraste contra el contrato anterior, nada se rompe.
​
POS Bridge v1
Lanzamiento del POS Bridge — integración de sistemas de punto de venta con el módulo de pedidos por WhatsApp.
  • POST /v1/catalog/items y POST /v1/catalog/options: sincronización de catálogo con idempotencia por event_id, orden por occurred_at y errores por ítem.
  • GET /v1/orders: polling de pedidos con las líneas en códigos del POS.
  • POST /v1/orders/{order_id}/status: aceptar / rechazar / listo / entregado / cancelar, con transiciones validadas.
  • GET /v1/sync-log: auditoría de sincronizaciones.
  • Key por sucursal (X-API-Key) y sandbox con sucursal demo.
Guías: Introducción · Quickstart · Estados del pedido.
​
v1.0
Lanzamiento inicial de la Partner API.
  • POST /campaigns: envío de templates con idempotencia y external_ref.
  • Soporte de templates con header multimedia (imagen, video y PDF) vía header_media_url.
  • GET /campaigns/{campaign_id}: estado del envío por destinatario.
  • Webhook reply.received: respuestas de clientes con campaign_id + external_ref.