Software a medida
Integrar un ERP con APIs sin detener la operación
Patrones de integración para conectar Siesa, e-commerce y sistemas satélite: colas, idempotencia, ambientes de prueba y cutover por dominios sin big bang.
14 min de lectura · Actualizado 2026-07-22
Por qué fallan las integraciones «directas»
El patrón más común — y más frágil — es un cron que cada noche empuja CSV por FTP al ERP. Funciona hasta que un campo cambia de formato, un pedido queda a medias y nadie se entera, o Black Friday duplica el volumen y el job no termina antes del horario de despacho. En logística, el síntoma es el operador que « arregla a mano » en Excel lo que el sistema no sincronizó.
Las APIs del ERP (REST, SOAP o servicios propietarios de Siesa) tienen límites de tasa, ventanas de mantenimiento y reglas de negocio que no coinciden con el e-commerce: unidades de empaque, listas de precio por canal, reservas de stock. Integrar «en caliente» sin capa de traducción y sin reintentos idempotentes garantiza incidentes en producción.
Otro error: tratar la integración como proyecto único en lugar de producto operativo. Necesita monitoreo, alertas, versionado de contrato y dueño en negocio y en TI. Sin eso, el primer cambio de impuesto o de política comercial rompe el flujo.
Qué hacer: modelar eventos de negocio (PedidoConfirmado, FacturaEmitida, StockActualizado) independientes del ERP concreto. Qué evitar: acoplar el portal directamente a tablas internas o scripts SQL sin capa intermedia.
Arquitectura recomendada: colas, idempotencia y dead-letter
Publicá eventos desde el canal digital a una cola (Redis, RabbitMQ, SQS según tu stack). Un consumidor traduce al formato del ERP, ejecuta la llamada y confirma con ack solo cuando el ERP devolvió éxito verificable. Si el ERP cae, los mensajes esperan — no se pierden pedidos.
Idempotencia: cada operación lleva un ID único de negocio (ej. número de pedido web + versión). Si el consumidor reintenta por timeout, el ERP no debe duplicar la factura. Implementá deduplicación en tu capa, no confíes en «que no pase».
Dead-letter queue (DLQ): mensajes que fallan N veces van a una cola de revisión con payload completo y trazas. Operaciones y soporte pueden reprocesar o corregir datos sin reescribir logs a mano. Alertá cuando la DLQ crece — es el termómetro de salud de la integración.
Ejemplo Conecta: distribuidor con tienda B2B y Siesa — pedidos entran 24/7; el consumidor agrupa líneas, valida crédito vía API y crea documento en ERP. Picos de fin de mes se absorben en cola; el equipo de bodega ve solo estados consolidados en su panel.
Ambientes, datos de prueba y paridad
Nunca desarrolles contra producción del ERP. Exige ambiente de pruebas con catálogo y clientes anonimizados pero representativos: SKUs con conversiones de unidad, productos kit, clientes con múltiples direcciones de entrega. Sin paridad, el go-live es ensayo en vivo.
Contratos de API versionados: OpenAPI o documento equivalente con ejemplos reales de request/response. Usá el JSON Formatter para validar payloads durante desarrollo y en soporte — un null vs campo ausente puede tumbar parsers estrictos.
Pruebas de carga acotadas antes de campañas: simulá 3× el pico histórico de pedidos por hora. Mide latencia p95 del ERP y tasa de error. Si el ERP es el cuello de botella, negociá ventana dedicada con el proveedor o batch asíncrono con confirmación al cliente.
Qué evitar: «probar en prod con un solo pedido fake». Qué hacer: checklist de casos — pedido cancelado, devolución parcial, cambio de precio mid-checkout, cliente bloqueado por cartera.
Cutover por dominios, no big bang
Orden sugerido: (1) maestros de solo lectura — productos, clientes; (2) stock consultable en tiempo casi real; (3) pedidos de bajo riesgo (canal secundario); (4) facturación electrónica y notas crédito; (5) apagar CSV legacy. Cada fase tiene rollback documentado.
Durante la convivencia, definí fuente de verdad por dato: el ERP manda en precios y cartera; el OMS puede mandar en reservas temporales de e-commerce. Conflictos se resuelven con reglas explícitas, no con «el último que escribe gana» sin auditoría.
Monitoreo post-cutover: dashboard con pedidos web vs documentos ERP, diferencias de monto, tiempo de sincronización. Conciliación diaria automatizada los primeros 30 días. En e-commerce, un desfase de stock visible genera sobreventa y reclamos.
Cuándo llamar a Conecta: tienes cutover en menos de 90 días, más de un canal (marketplace + web propia) o historial de integraciones rotas. Aportamos diseño de colas, implementación y observabilidad sobre infraestructura infraestructura propia y LiteSpeed cuando el hosting también es nuestro.
Operación 24/7 y runbook
Documentá runbook: qué hacer si el ERP no responde (modo degradado — ¿se aceptan pedidos en cola?), quién escala con el proveedor del ERP, cómo pausar consumidores sin perder mensajes. Incluí contactos y SLAs internos.
Logs estructurados con correlation ID desde el checkout hasta el documento ERP. Soporte debe reconstruir un pedido en minutos, no horas. Retención acorde a auditoría fiscal.
Seguridad: credenciales de API en vault, rotación periódica, IP allowlist donde aplique. Web Checker 360 ayuda a verificar TLS y headers en endpoints expuestos — integración sin HTTPS estricto no es opción.
Checklist final pre-producción: DLQ configurada, alertas en Slack/correo, prueba de restore de cola, contrato firmado con negocio sobre estados «pendiente ERP», formación a operaciones. Integración sin runbook es proyecto; con runbook es operación.
Ponlo en práctica ahora
Usa las herramientas gratuitas del Toolbox para validar tu configuración en minutos.
¿Necesitas que lo resolvamos contigo?
Un ingeniero de Conecta puede aplicar esto en tu operación: servicio relacionado o conversación directa.