Skip to main content
​
POS Bridge — promos del local: líneas en $0 y precios rebajados
Sin cambios en el contrato: mismos campos, mismas respuestas. Cambia lo que puede venir en una línea del pedido.
  • Promos del local. El local puede cargar en Xenda un regalo por compra (“comprando 1 kg te regalamos 1/4 kg”), un 2x1 / 3x2, o un descuento en % (sobre un producto o sobre todo el pedido), válidos ciertos días y, si quiere, solo pagando en efectivo. El bot las ofrece y las aplica al cotizar.
  • Qué ves en GET /v1/orders. El regalo o las unidades gratis llegan como una línea más en lineas, con tu codigo, precio_unitario: 0, subtotal: 0 y el nombre de la promo entre paréntesis en nombre. Con un descuento, precio_unitario viene ya rebajado. total y pago.monto las contemplan: nunca hay líneas negativas ni un campo de descuento aparte.
  • Qué necesitás de tu lado. Que tu sistema acepte una línea con precio_unitario y subtotal en 0 dentro de un pedido con total mayor a 0. No cambia nada más.
​
POS Bridge — puesta en producción de una sucursal y cierres desde Xenda
Sin cambios en la API: mismo contrato, mismas respuestas. Cambia lo que el local puede hacer del lado Xenda y se completa la documentación.
  • El local solo puede cerrar pedidos desde Xenda. En una sucursal conectada a un POS, la plataforma Xenda ya no deja aceptar, rechazar ni mover pasos intermedios: solo marcar entregado o cancelar. Los estados los mueve tu sistema. Si llega un evento tuyo después de ese cierre, recibe el 400 invalid_transition de siempre.
  • Corrección en Estados — tiempos automáticos. La guía decía que un pedido pendiente expira “por defecto a los 15 minutos”. No es así: la cancelación de pendientes y el cierre de pedidos en curso son opciones de cada local y vienen apagadas. La sección explica qué ve tu POS si el local las activa.
  • Guía nueva: Pasar una sucursal a producción (en la Introducción): qué credenciales recibís, carga inicial por API o CSV, cómo se configura qué productos llevan sabores, prueba de punta a punta y cómo cambiar una key sin corte.
  • POST /v1/test/orders: aclarado que funciona con cualquier key de sucursal y que en una sucursal real el pedido es real.
​
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.