Cuándo hace falta programar la conexión
Muchos negocios ya pagan varias herramientas: la tienda, la hoja, el sistema de facturas, el chat, el ERP. A veces esas herramientas se hablan con un conector y el trabajo correcto es una automatización. A veces el conector no existe, se queda corto o transforma mal los datos. Ahí Devstoremx construye la integración.
El síntoma es concreto. Alguien exporta un archivo todos los días y lo vuelve a subir. Un pedido de la tienda no aparta existencia en el sistema que sí usa el almacén. Un formulario llega, pero el folio se captura a mano. Si ese paso se puede describir y los dos sistemas tienen una puerta de entrada, se puede integrar. Si uno de los dos es una caja cerrada sin exportación, primero hay que cambiar de caja o aceptar el paso manual.
Qué se entrega
No se entrega “la API del universo”. Se entrega un flujo con nombre:
- Qué evento lo dispara: un pedido, un pago, un alta, un horario.
- Qué datos viajan y cuáles no. Sobre todo datos de clientes, que no se copian a un sistema de más “por si sirven”.
- Qué pasa si el otro lado no responde: reintento, aviso a una persona, registro del fallo.
- Dónde queda el secreto de acceso, en una cuenta del negocio, no en un mensaje de chat.
- Cómo se prueba con datos ficticios antes de tocar la operación real.
Eso puede vivir solo, como un servicio pequeño entre dos nubes, o dentro de una aplicación web que el equipo usa. Se dice cuál de los dos es en la propuesta, porque operarlos se siente distinto.
Inteligencia artificial, con un trabajo claro
Integrar un modelo no es pegar un chat en la esquina del sitio. El trabajo serio es definir la tarea: clasificar solicitudes, extraer datos de un documento que siempre trae el mismo tipo de campos, proponer un borrador que alguien aprueba. También es definir qué información del negocio puede ver el modelo y cuál no sale de tus sistemas.
Si la tarea no se puede revisar, no se automatiza la respuesta final. Un modelo que inventa una política de devoluciones y la manda al cliente es un problema operativo, no una función. En la propuesta se escribe el punto en el que la persona sigue en el circuito.
Para equipos que ya saben qué dato se pierde
Es para un equipo que ya identificó los dos sistemas y el dato que se pierde en medio. No es para quien dice “conéctalo con todo” sin poder nombrar el primer flujo. Ese descubrimiento se puede hacer en la llamada, y a veces termina en una automatización más simple, que es mejor noticia que un desarrollo largo.
Tampoco es el mantenimiento del sitio. Una integración rota se atiende como incidente de esa conexión. Las actualizaciones de WordPress o de un tema van en mantenimiento web.
Riesgos que se dicen antes de cotizar
El proveedor puede cambiar o cerrar su API. Puede cobrar por cada llamada. Puede tardar días en dar un acceso de prueba. Esos riesgos se anotan porque mueven la fecha. Cotizar “la integración con X” sin haber visto la documentación es adivinar.
Por eso el primer entregable, cuando el sistema es desconocido, puede ser una revisión corta: ¿se puede conectar, con qué límites y qué no se va a poder hacer? Después se cotiza la construcción. Es más lento que prometer que sí a todo, y es la única forma de no vender un puente hacia una puerta que no existe.
Datos personales en el camino
Si la integración copia nombres, correos o pedidos, ese copia y pega es un tratamiento de datos. Se escribe qué sistema es el origen, cuál es el destino y para qué se usa el dato. No se duplica la base “completa” a un tercero porque la API lo permite. El aviso de privacidad del sitio cubre el formulario público. Una integración interna puede necesitar que el negocio revise ese aviso con quien lleve sus temas legales. Nosotros no sustituimos esa revisión: evitamos mover datos de más y dejamos el flujo explicado para que alguien pueda leerlo.
En la entrega queda un registro de prueba con datos ficticios, no con clientes reales pegados en un chat. El acceso de la API se rota si estuvo expuesto durante el desarrollo. Es parte del trabajo, no un extra de cortesía.
