Saltar al contenido principal

Changelog

Resumen de los cambios de la API de Integración de terceros. No repite el detalle de implementación: para eso está cada página de referencia, linkeada desde cada entrada.

2026-10-01 — Actualizar y cambiar el estado de un pedido​

  • Pedidos documenta cómo actualizar un pedido (reenviando POST /pedido con el mismo ordenId) y cómo cambiar su estado: pagado + medioPago para pasar a PAGADO, POST /pedido/cancelar para anular y POST /facturar para facturar. Incluye ejemplos y la tabla de transiciones.
  • Esquema de datos: PedidoTerceros suma pagado, medioPago y listaPrecioId (opcionales) y se agrega ComprobanteEstado.
  • Correcciones de documentación: un total que no cuadra responde 200 con errores: true (no 422); el anti-duplicados de POST /pedido es de 30 segundos por numero; y POST /pedido/cancelar aplica a pedidos PENDIENTE y PAGADO.
  • Sin cambios de contrato: describe el comportamiento vigente.

2026-09-29 — Varios depósitos desde plan Empresa​

  • Leer varios depósitos con una misma integración, incluido el modo multidepósito informativo de los webhooks, está disponible desde el plan Empresa. Es experimental y lo activa NinoxNet en el canal a pedido.
  • Alcance y límites ya no dice "un token = un depósito + un punto de venta": los pedidos y ventas siguen yendo contra el depósito y el punto de venta de la integración, pero leer varios depósitos no requiere integraciones separadas.
  • Sin cambios de contrato.

2026-08-26 — Cliente explícito en pedido, venta y nota de crédito​

  • Pedido, Venta y NotaCreditoTerceros aceptan ahora un entidadId opcional para atribuir el comprobante a un cliente ya existente en NinoxNet en vez de que se resuelva o cree automáticamente a partir de usuario.
  • Con entidadId, usuario pasa a ser opcional: no se busca por documento/CUIT/email ni se da de alta un cliente nuevo. Sin entidadId, usuario sigue siendo obligatorio (con al menos dni, cuit o email); si no se manda ninguno de los dos, la API responde 400.
  • Un entidadId que no corresponde a un cliente activo responde 403. Los ids válidos salen de GET /entidades.
  • Cambio de contrato retrocompatible: campo nuevo y opcional, ninguna integración existente necesita cambios.

2026-08-20 — Exportación de compras y totales de comprobante​

  • Nuevo GET /exportar/compraitems/paginado para exportar ítems de compra por período (mismos criterios que ventaitems/paginado, con proveedor/empleado y precioCompra/precioCompraFinal en vez de la semántica de venta). Solo existe la variante paginada.
  • Nuevo GET /exportar/compratotales/paginado y su equivalente de venta, GET /exportar/ventatotales/paginado: una fila por comprobante, sin el detalle de ítems, para quien solo necesita los totales de cabecera.
  • Los cuatro endpoints paginados de comprobante (ventaitems, ventatotales, compraitems, compratotales) comparten los mismos query params y un único bucket de rate limit corto (30 s producción / 3 s test), para poder paginar de corrido sin esperar el bucket masivo.
  • Nuevo modo multidepósito informativo: el webhook de artículos incluye stockDepositos con el stock desglosado de cada depósito de la integración. Pensado para quienes administran varios locales y hasta ahora necesitaban un token por depósito. Requiere plan Corporativo y lo activa NinoxNet en el canal.
  • En ese modo, unidades pasa a ser el stock del depósito principal y no la suma del array. El campo no viaja si tu integración no está en ese modo, así que si ya integraste, nada cambia.
  • GET /config ahora informa flujoDeposito, para que puedas detectar si vas a recibir stockDepositos sin tener que preguntarnos.
  • GetData y GetDataCurva aceptan un depositoId opcional para consultar el stock de un depósito puntual.

2026-08-13 — Comprobantes, empleados, puntos de venta y vendedor​

  • Nuevo GET /comprobante/{id} para reconsultar una preventa, venta o nota de crédito ya creada por tu integración (útil para reconciliar después de un timeout o corte de red).
  • Nuevos GET /empleados y GET /puntos-venta para descubrir los ids válidos de vendedor y punto de venta de tus sucursales habilitadas.
  • Pedido, Venta y NotaCreditoTerceros aceptan ahora un empleadoId opcional para fijar el vendedor del comprobante.
  • Se corrigió un bug: Terceros era el único canal que no propagaba el vendedor configurado al comprobante resultante. Si no mandás empleadoId, ahora se aplica el vendedor de tu integración (antes quedaba sin asignar).

2026-08-06 — Sucursales habilitadas​

  • La API ahora acota por sucursal: tu integración solo puede leer y escribir en las sucursales que le fueron habilitadas (no es algo que la integración pueda autoatribuirse). Ver alcance y límites.
  • Las exportaciones, saldos/* y POST /stock/movimiento responden 403 si la integración todavía no tiene sucursales habilitadas (deny-by-default).
  • El alta de comprobantes (pedido, venta, notacredito, facturar) valida que el punto de venta caiga en una sucursal habilitada, pero no corta si esa lista aún no fue configurada: una integración que ya funcionaba sigue funcionando igual que antes.

2026-07-31 — Webhooks propios por API​

  • Ya no hace falta coordinar cada webhook con NinoxNet: alta, edición, baja y consulta se manejan solo con tu token. Ver webhooks.

2026-07-06 — Nota de crédito​

  • Nuevo POST /notacredito para emitir notas de crédito directas desde tu integración, con facturaRefId opcional para vincularlas a la venta original.
  • Se dejó de documentar puntoVentaId en venta y notacredito: el punto de venta siempre sale de la configuración de tu integración.

2026-06-29/30 — Exportación de ventas​

  • Nuevo endpoint paginado GET /exportar/ventaitems/paginado, recomendado para automatizaciones y meses completos (bucket de rate limit propio y corto para poder recorrer páginas de corrido).
  • El endpoint no paginado (exportar/ventaitems) suma un tope de 10.000 ítems por request; por encima de eso, hay que usar el paginado.
  • Ambos suman filtro por rango de fechas desde/hasta (máximo 30 días) y el parámetro opcional incluirMediosPago; pageSize del paginado queda con un máximo de 500.

2026-06-02 — Transferencias de stock​

  • Se aclaró el contrato de POST /stock/movimiento para transferencias: el depósito y la sucursal de destino se envían en depositoDosId y sucursalDosId. Ver stock.

¿Encontraste algo que no está reflejado acá? Este changelog cubre los últimos meses; para el historial completo de la API, o dudas sobre una versión anterior, contactanos por los canales de onboarding.