Integraciones por API y webhooks a medida
Casi cualquiera monta hoy una integración que funciona el primer día. Lo difícil es que siga funcionando el día que el otro extremo tarda diez segundos en responder, devuelve un error a mitad de un lote o reenvía el mismo evento tres veces.
Cuéntanos qué sistemas quieres conectar →Qué es una integración por API y webhooks
Una integración por API permite que dos aplicaciones intercambien datos y ejecuten acciones de forma controlada. Los webhooks añaden la parte reactiva: un sistema avisa al otro cuando ocurre un evento, sin necesidad de consultarlo constantemente.
En producción, conectar dos endpoints es solo el principio. La integración también tiene que gestionar duplicados, reintentos, errores, límites de llamadas, seguridad y trazabilidad para que un fallo de un tercero no termine afectando a la operación.
La integración «va bien» pero cada dos semanas alguien pregunta por un pedido que no llegó. Nadie sabe responder sin abrir la base de datos, porque no hay un sitio donde mirar qué pasó con ese mensaje concreto.
Por qué una herramienta no-code no siempre basta
Las plataformas de automatización visual resuelven muy bien una gran parte de las integraciones, y las usamos a diario. Dejan de bastar en tres situaciones concretas: cuando el volumen hace que el precio por ejecución deje de tener sentido, cuando hace falta una transacción real entre dos pasos, y cuando la lógica de error es más compleja que la lógica de negocio. Ese último caso es más frecuente de lo que parece —lo que se tarda en construir no es el camino feliz, es todo lo demás—. La decisión correcta rara vez es «todo a medida»: suele ser dejar en la herramienta lo que le corresponde y sacar a código las dos o tres piezas que la desbordan.
Los flujos que hay que resolver
Cada uno con la decisión de diseño que decide si aguanta en producción.
Entrega al menos una vez, procesamiento idempotente
Prácticamente ningún emisor de webhooks garantiza entrega única. Lo que hay que construir en el receptor es la capacidad de reconocer el evento repetido y descartarlo, guardando la clave del evento con la operación en la misma transacción.
Sin eso, un reintento del emisor genera un cobro duplicado, un pedido duplicado o un correo enviado dos veces. Y el emisor reintenta más veces de las que uno espera.
Recibir rápido, procesar después
El endpoint que recibe el webhook valida la firma, persiste el evento y responde. El trabajo real ocurre en una cola aparte, con reintentos de espaciado creciente y una cola de fallidos donde acaba lo que no se puede procesar.
Procesar dentro de la petición hace que un tercero lento provoque timeouts, y muchos emisores desactivan un webhook que falla de forma repetida. Se pierde la integración por una lentitud puntual.
Firma, no confianza
Toda entrada verifica su firma con comparación en tiempo constante y rechaza marcas de tiempo antiguas. Toda salida se autentica con credenciales rotables y de alcance mínimo.
Un endpoint público sin verificación es un formulario de escritura abierto a internet contra tu sistema de gestión.
Orden y límites de llamada
Los eventos no llegan necesariamente en orden y el otro extremo tiene un límite de llamadas por minuto. Ambas cosas se resuelven en el diseño: número de versión por entidad para descartar lo viejo, y control de ritmo con espera respetando la cabecera de reintento.
Ignorar el orden hace que un estado antiguo pise al nuevo. Ignorar el límite provoca bloqueos que se manifiestan justo en los picos de volumen.
Qué recibes
- ▪ Endpoints de entrada con verificación de firma y registro de eventos
- ▪ Cola con reintento exponencial y cola de fallidos revisable
- ▪ Clave de idempotencia por operación, persistida junto al efecto
- ▪ Panel de estado por mensaje: recibido, procesado, fallido, reintentando
- ▪ Alarma por antigüedad de pendientes y por crecimiento de la cola de fallidos
Cómo lo construimos
Idempotencia por defecto
Toda operación se puede repetir sin duplicar nada. Es lo que permite reintentar sin miedo, y sin ello ninguna integración sobrevive al primer corte de red.
Estado observable
Cada mensaje tiene estado consultable: pendiente, enviado, confirmado, fallido. Una integración que solo se ve cuando falla ya falló antes.
Un solo dueño por dato
Para cada campo hay un sistema que manda y los demás obedecen. La sincronización bidireccional sin esa regla acaba en bucles y en datos que cambian solos.
IA donde decide, no donde calcula
Clasificar, extraer y redactar son tareas de modelo. Sumar, validar y encaminar son tareas de código. Mezclarlo al revés sale caro y es imposible de auditar.
Cómo lo abordamos
El mismo equipo que diagnostica es el que construye, sin traspasos. El método completo y el resto de capacidades están en la página de integración de sistemas.
- 01 Diagnóstico · 3–5 días
Mapeamos sistemas, flujos de datos y dependencias reales, incluidas las que no están documentadas. Salida: alcance cerrado y la lista de lo que se rompe hoy.
- 02 Diseño de la integración · 1 semana
Contratos de datos, dirección de la sincronización, política de reintentos y quién es dueño de cada campo. Se decide antes de escribir código porque es lo caro de cambiar después.
- 03 Implementación y pruebas · 2–6 semanas
Construcción con la casuística real, no con el caso feliz. Pruebas contra los sistemas de verdad y despliegue por fases.
- 04 Producción y observabilidad · continuo
Panel de estado, alarmas cuando algo lleva demasiado tiempo sin confirmar y mantenimiento de las integraciones cuando las APIs de terceros cambian.
Relacionado con APIs y webhooks
Lo que suele venir antes o después, con el motivo por el que lo enlazamos.
Sistemas legados
Cuando el otro extremo no tiene API, el patrón deja de ser este y pasa a ser otro.
Ver →La capa de API de Verifactu
El mismo diseño de cola, reintento e idempotencia, aplicado a un servicio de la Administración.
Ver →Integración de ERP
El destino más habitual de estos conectores.
Ver →Webhook o API, y qué pasa después
La diferencia en una frase y los cinco supuestos falsos que rompen integraciones en producción.
Ver →Preguntas frecuentes sobre APIs y webhooks
¿Qué diferencia hay entre integrar por API y por webhook? +
La dirección de la iniciativa. Con API tú preguntas cuando quieres: es predecible y controlas el ritmo, pero llegas tarde y gastas llamadas preguntando por cosas que no han cambiado. Con webhook el otro sistema te avisa cuando pasa algo: es inmediato y eficiente, pero te obliga a estar disponible siempre y a tolerar repeticiones. La mayoría de integraciones serias usan las dos: webhook para enterarse y API para confirmar el detalle.
¿Qué pasa si el otro sistema se cae? +
Los mensajes se acumulan en la cola y se reintentan con espaciado creciente hasta que el servicio vuelve. Lo que no se debe hacer nunca es dejar que la caída de un tercero pare tu operación: el flujo propio continúa y la sincronización se pone al día después. Ese es exactamente el motivo por el que la cola existe.
¿Usáis n8n o construís todo a medida? +
Las dos cosas, y la elección se argumenta caso por caso. n8n cubre muy bien la orquestación y los flujos que cambian a menudo, con la ventaja de que tu equipo puede editarlos sin depender de nosotros. Lo que sacamos a código son las piezas con requisitos duros: alto volumen, transacciones, lógica de error compleja o algo que tenga que ser auditable. Mezclar los dos mundos suele salir más barato que elegir uno por dogma.
¿Quién mantiene la integración cuando la API de un tercero cambia? +
Es parte del contrato de mantenimiento, y conviene que lo sea explícitamente. Las APIs de terceros cambian sin avisar a nadie en concreto: retiran versiones, endurecen límites, modifican campos. Una integración sin nadie vigilando esos cambios funciona hasta que un día deja de hacerlo, y normalmente se descubre por una queja de cliente.
Empieza por el diagnóstico
Tres a cinco días para saber qué se conecta primero, con alcance y precio cerrados antes de escribir una línea de código.
Hablar con un especialista ↗Otras integraciones