Guía técnica / Integración de sistemas

Integración de sistemas: qué revisar antes de conectar ERP y CRM.

Una integración útil mantiene la identidad y el significado de los datos mientras pasan entre aplicaciones. Antes de construirla, decide qué sistema manda sobre cada dato, qué evento provoca un cambio y cómo comprobarás su resultado.

Autoría: Kenea · Publicación y revisión: 8 de septiembre de 2026.

1. Identifica quién mantiene cada dato

ERP y CRM pueden contener un «cliente», pero utilizar ese nombre para realidades distintas: una cuenta comercial, una entidad de facturación o varios establecimientos. La integración necesita una correspondencia explícita. Coincidir en el nombre visible no garantiza que dos registros sean la misma entidad.

Prepara un mapa de campos con identificadores estables, formato, obligatoriedad y dirección de actualización. Decide qué aplicación es la referencia de cada campo. No hace falta que un único sistema gobierne todos los datos; sí hace falta resolver qué sucede cuando dos aplicaciones proponen cambios.

Las reglas también deben cubrir registros archivados, modificaciones y posibles fusiones. Evita empezar con una sincronización bidireccional de todos los campos si el proceso solo necesita enviar una referencia en una dirección.

2. Revisa la vía de conexión y sus condiciones

Consulta primero qué ofrece el fabricante en la versión y modalidad que utilizas. Una API publicada no implica que todas las operaciones estén disponibles en tu plan, y un conector existente puede cubrir solo una parte del recorrido.

• Conector mantenido: comprobar objetos, acciones, límites, versión compatible y quién atiende incidencias.
• API: revisar permisos, autenticación, filtros, paginación, límites de llamadas y respuestas de error.
• Eventos o webhooks: comprobar autenticidad, posibles repeticiones, orden y recuperación de notificaciones perdidas.
• Intercambio de archivos: acordar formato, entrega, identificación de lotes y cómo se confirma la importación.
• Automatización de pantalla: evaluar estabilidad de la interfaz, sesiones, supervisión y coste de mantenerla.

Estas vías pueden combinarse. Un evento puede avisar de un cambio y una API recuperar los datos vigentes; una exportación puede servir para la carga inicial. La elección depende de frescura, volumen, funciones disponibles y condiciones de operación. «En tiempo real» necesita una demora aceptable definida y medida.

3. Conserva la identidad cuando una operación se repite

Una misma petición puede llegar más de una vez por un reintento, un doble clic o la recuperación de un proceso. La integración debe reconocer a qué operación pertenece cada intento. Generar una referencia nueva en cada reintento impide relacionarlos y puede producir un segundo registro.

Algunas APIs ofrecen idempotencia: un mecanismo para repetir una petición bajo condiciones definidas sin repetir su efecto. Stripe, por ejemplo, documenta claves de idempotencia y restricciones sobre contenido y conservación. Es un comportamiento de ese servicio; hay que comprobar las garantías del destino concreto. Fuente: Stripe, solicitudes idempotentes.

En el diseño de tu integración, conserva la referencia del origen, la del destino y los intentos relevantes. Si una misma referencia llega con contenido distinto, define si representa una modificación válida o un conflicto. No basta con descartar todo lo que se parezca a un duplicado: podrías perder una actualización legítima.

4. Distingue un rechazo de una respuesta desconocida

Si el destino rechaza un campo y devuelve una respuesta completa, hay información para corregirlo. Si se corta la conexión después de enviar, el resultado puede ser desconocido. Que el cliente deje de esperar no demuestra que el servidor haya detenido su trabajo.

AWS explica por qué los límites de espera y los reintentos necesitan diseñarse juntos: repetir llamadas con efectos puede duplicarlos, y una ráfaga de reintentos puede empeorar una sobrecarga. El procedimiento debe limitar y espaciar los intentos y comprobar cuándo es seguro repetir. Fuente: Amazon Builders’ Library, Timeouts, retries, and backoff with jitter.

Para una operación desconocida, conserva evidencia y utiliza la consulta o conciliación que permita el destino. Si no ofrece un mecanismo adecuado, hace falta un procedimiento de revisión. Una cola de errores debe mostrar qué pasó, desde cuándo, quién lo atiende y qué acción procede.

La recepción de eventos también necesita atención. Stripe documenta que sus webhooks pueden repetirse y llegar en un orden diferente al de generación. Es una razón concreta para revisar ese contrato en cualquier proveedor, en lugar de dar por garantizado un orden único. Fuente: documentación de webhooks de Stripe.

5. Define permisos y visibilidad operativa

La cuenta utilizada para conectar aplicaciones debe tener los permisos que exige el recorrido autorizado. Separa entornos de prueba y producción, identifica quién renueva los accesos y evita incluir claves o documentos completos en los registros de soporte.

Para seguir una operación suelen ser más útiles su referencia, los sistemas implicados, el estado conocido y la hora de cada intento que un gran volcado de datos. Ajusta el detalle y la conservación a las necesidades del proceso. El equipo debe poder averiguar qué quedó pendiente sin abrir una consola de desarrollo.

También hay que decidir cómo se detecta una ausencia. Si el origen debería generar un lote diario y no llega ninguno, un sistema que solo alerta cuando recibe errores puede permanecer silencioso. Incluye la comprobación de actividad esperada cuando sea relevante.

6. Prueba el recorrido antes de autorizar producción

Un cambio que ya se ha aplicado en otro sistema no siempre admite un simple «deshacer». Describe qué puede revertirse y qué requiere una operación compensatoria o intervención. La prueba debe comprobar la recuperación posible, con sus límites, antes de ampliar el alcance.

Qué debería quedar documentado

El resultado de una evaluación técnica por encargo debería permitir decidir el siguiente paso: un mapa del recorrido, correspondencia de datos, interfaces disponibles, dependencias, responsables y pruebas pendientes. Las incógnitas deben figurar como tales; tener acceso a una API no acredita una integración terminada.

Para una implementación aceptada se añadirían versiones, configuración necesaria, evidencias de prueba y procedimiento de operación. La línea de integración de sistemas de Kenea parte del software existente y del objetivo del proceso. Si además hay interpretación de documentos, puedes revisar la decisión entre reglas e IA y el enfoque de IA aplicada.

El evaluador gratuito permite dibujar una primera orientación sin registro. Para conocer interfaces, permisos y viabilidad hace falta revisar los sistemas reales dentro del alcance que se acuerde.

Explorar mi proceso Ver las soluciones

Fuentes y límites de esta guía

Fuentes primarias consultadas el 8/9/2026: Stripe, Idempotent requests; Stripe, Webhooks; y Marc Brooker, Amazon Builders’ Library, Timeouts, retries, and backoff with jitter (2019). Las condiciones de Stripe describen su servicio y pueden cambiar: no se atribuyen a cualquier ERP, CRM o API. Las matrices y el plan de aceptación son propuestas de Kenea, no pruebas de una integración ejecutada.