---
id: KB-IN-005
url: https://app.codecontract.io/help/integrations/automatic-notifications-to-your-system
idioma: en
categoria: integraciones
audiencia: desarrollador
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IN-002, KB-IN-003, KB-IN-020]
citadoPor: [KB-IN-007, KB-IN-008, KB-IN-009]
---

# Letting your system find out by itself

_Receiving a notification when something happens, instead of polling every five minutes._

**Responde a:** webhooks to receive events · notify my erp when someone signs · real-time integration · available api events

Polling every few minutes to ask whether anything happened works, scales badly and arrives late. Having the platform notify your system at the moment is cheaper and faster, in exchange for an endpoint you have to get right.

## What it is used for, in practice

| Event | What it usually triggers on your side |
| --- | --- |
| A case completes | Mark the supplier as cleared |
| Someone signs | Attach the contract to the client record |
| A document expires | Block the haulier at the bay |
| A delivery is rejected | Open a task for whoever owns that account |

## Three things to get right

1. **Respond fast, then work** — Acknowledge receipt and process afterwards. A slow endpoint causes retries.
2. **Tolerate repeats** — The same event may arrive twice. Process by identifier, not by arrival order.
3. **Check it came from us** — Verify the notification signature. A public endpoint that believes whatever reaches it is an open door.

> [!IMPORTANT]
> Never process a notification without verifying its signature. It is a public URL: anyone can send it something that looks like "this contract is signed", and acting on that unchecked is exactly the hole being looked for.

> [!WARNING]
> An endpoint that errors on everything generates endless retries and noise. If something fails on your side, acknowledge receipt and queue the problem rather than rejecting the notification.

> [!NOTE]
> Most setups end with two integrations: the API to launch things and notifications to find out. They cover different directions and do not compete.

**Can it be tested without touching production?**

Yes, against the test environment.

**What if my system is down?**

Delivery is retried for a while; review the failures.

**Can I choose which events to receive?**

Yes, and you should: subscribing to everything fills the log with noise.

## Ejemplos

**An ERP needs to know when a subcontractor is cleared for site access.**

- Subscribes to the case-completed event
- Verifies each notification's signature
- Marks the subcontractor in its own system

→ The gate stops phoning the office to ask who may enter.

**The ERP does not learn that a supplier completed their file and purchasing keeps blocking orders.**

- Configures the automatic notification on file completion
- The ERP marks the supplier as approved on receiving it

→ The order unblocks the same day the supplier delivers, with nobody checking anything.

**Somebody logs in every morning to see whether anything changed.**

- Receives a notification only when what matters changes

→ The daily check disappears and the notice arrives when there is something to do.

**Notifications arrive about everything and the receiving system saturates.**

- Subscribes only to the events that will be used

→ The system receives what it knows how to process.

**A notification fails and nobody knows it was lost.**

- Checks the delivery log and the retries

→ The lost notification is reprocessed rather than vanishing.

**The receiving system is down an hour and ten notifications are lost.**

- Configures retries and checks what is pending

→ The outage does not leave a hole in the data.