---
id: KB-IN-005
url: https://app.codecontract.io/ayuda/integraciones/avisos-automaticos-hacia-vuestro-sistema
idioma: es
categoria: integraciones
audiencia: desarrollador
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [en]
relacionados: [KB-IN-002, KB-IN-003, KB-IN-020]
citadoPor: [KB-IN-007, KB-IN-008, KB-IN-009]
---

# Que vuestro sistema se entere solo

_Recibir el aviso cuando algo pasa, en vez de preguntar cada cinco minutos._

**Responde a:** webhooks para recibir eventos · notificar a mi erp cuando alguien firma · integración en tiempo real · eventos disponibles api

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.

> [!IMPORTANT]
> 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.

> [!WARNING]
> 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.

> [!NOTE]
> 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.

## Ejemplos

**Un ERP necesita saber cuándo una subcontrata queda apta para entrar a obra.**

- Se suscribe al evento de expediente completado
- Verifica la firma de cada aviso
- Marca la subcontrata en su sistema

→ El muelle deja de llamar a oficina para preguntar quién puede entrar.

**El ERP no se entera de que un proveedor ha completado su expediente y compras sigue bloqueando pedidos.**

- Configura el aviso automático al completarse el expediente
- El ERP marca al proveedor como apto al recibirlo

→ El pedido se desbloquea el mismo día en que el proveedor entrega, sin que nadie mire nada.

**Alguien entra cada mañana a comprobar si ha cambiado algo.**

- Recibe el aviso solo cuando cambia lo que importa

→ La revisión diaria desaparece y el aviso llega cuando hay algo que hacer.

**Llegan avisos de todo y el sistema receptor se satura.**

- Suscribe solo los eventos que se van a usar

→ El sistema recibe lo que sabe procesar.

**Un aviso falla y nadie se entera de que se perdió.**

- Comprueba el registro de entregas y los reintentos

→ El aviso perdido se reprocesa en lugar de desaparecer.

**El sistema receptor se cae una hora y se pierden diez avisos.**

- Configura los reintentos y consulta lo pendiente

→ La caída no deja un agujero en los datos.