Integraciones
Que vuestro sistema se entere solo
Recibir el aviso cuando algo pasa, en vez de preguntar cada cinco minutos.
Preguntar cada pocos minutos si ha pasado algo funciona, escala mal y llega tarde. Que la plataforma avise a vuestro sistema en el momento es más barato y más rápido, a cambio de un endpoint que hay que hacer bien.
Para qué se usa, en la práctica
| Evento | Qué suele dispararse en vuestro lado |
|---|---|
| Un expediente se completa | Marcar al proveedor como apto |
| Alguien firma | Adjuntar el contrato al registro del cliente |
| Un documento caduca | Bloquear al transportista en el muelle |
| Una entrega es rechazada | Abrir una tarea a quien lleva esa cuenta |
Tres cosas que hay que hacer bien
- 1
Responder rápido y luego trabajar
Confirmad la recepción y procesad después. Un endpoint que tarda provoca reintentos.
- 2
Tolerar repeticiones
Un mismo evento puede llegar dos veces. Procesad por su identificador, no por el orden de llegada.
- 3
Comprobar que viene de nosotros
Verificad la firma del aviso. Un endpoint público que se cree cualquier cosa que le llegue es una puerta abierta.
Importante
No proceséis un aviso sin verificar su firma. Es una URL pública: cualquiera puede enviarle algo que parezca «este contrato está firmado», y actuar sobre eso sin comprobar es exactamente el agujero que se busca.
Ojo con esto
Un endpoint que devuelve error a todo genera reintentos indefinidos y mucho ruido. Si algo falla en vuestro lado, confirmad la recepción y encolad el problema, no rechacéis el aviso.
Ten en cuenta
Lo habitual es acabar con dos integraciones: la API para lanzar cosas y los avisos para enteraros. Cubren direcciones distintas y no compiten.
›¿Se puede probar sin tocar producción?
Sí, contra el entorno de pruebas.
›¿Qué pasa si mi sistema está caído?
Se reintenta durante un tiempo; conviene revisar los fallidos.
›¿Puedo elegir qué eventos recibir?
Sí, y conviene: suscribirse a todo llena el registro de ruido.
Un caso real
La situación
Un ERP necesita saber cuándo una subcontrata queda apta para entrar a obra.
Qué haces
- Se suscribe al evento de expediente completado
- Verifica la firma de cada aviso
- Marca la subcontrata en su sistema
Qué consigues
El muelle deja de llamar a oficina para preguntar quién puede entrar.
La situación
El ERP no se entera de que un proveedor ha completado su expediente y compras sigue bloqueando pedidos.
Qué haces
- Configura el aviso automático al completarse el expediente
- El ERP marca al proveedor como apto al recibirlo
Qué consigues
El pedido se desbloquea el mismo día en que el proveedor entrega, sin que nadie mire nada.
La situación
Alguien entra cada mañana a comprobar si ha cambiado algo.
Qué haces
- Recibe el aviso solo cuando cambia lo que importa
Qué consigues
La revisión diaria desaparece y el aviso llega cuando hay algo que hacer.
La situación
Llegan avisos de todo y el sistema receptor se satura.
Qué haces
- Suscribe solo los eventos que se van a usar
Qué consigues
El sistema recibe lo que sabe procesar.
La situación
Un aviso falla y nadie se entera de que se perdió.
Qué haces
- Comprueba el registro de entregas y los reintentos
Qué consigues
El aviso perdido se reprocesa en lugar de desaparecer.
La situación
El sistema receptor se cae una hora y se pierden diez avisos.
Qué haces
- Configura los reintentos y consulta lo pendiente
Qué consigues
La caída no deja un agujero en los datos.
Este artículo responde a
- webhooks para recibir eventos
- notificar a mi erp cuando alguien firma
- integración en tiempo real
- eventos disponibles api