---
id: KB-IN-009
url: https://app.codecontract.io/help/integrations/which-events-the-platform-can-notify
idioma: en
categoria: integraciones
audiencia: desarrollador
nivel: avanzado
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IN-005, KB-IN-008, KB-IN-014]
citadoPor: [KB-IN-013]
---

# The twenty events it can notify your system about

_The complete catalogue of what can trigger something on your side._

**Responde a:** which events does the platform emit · available webhooks list · notify my erp when something happens · case and request events

Your system can find out the moment something happens here, without polling. This is everything it can be notified about, grouped by what it happens to.

## What happens to a case

| Event | When it fires |
| --- | --- |
| It completes | Everything mandatory is delivered and approved |
| It is cancelled | Someone closes it incomplete |
| It is duplicated | A new one is created from it |
| A phase is added | The case grows while running |
| A block is imported | Documentation arrives in bulk |
| It is deleted | It ceases to exist |

## What happens to a request

| Event | Typical use |
| --- | --- |
| It is sent | Record in your system that it was asked |
| It is opened | Know it genuinely arrived |
| It is answered | Trigger your next step |
| It is received | Mark the document as in |
| It is rejected | Open a task for whoever asked |
| It is reminded | Count the chasing |
| It is resent | Detect problem contacts |

## What happens to a document

| Event | Typical use |
| --- | --- |
| It is uploaded | Reflect it in your document manager |
| Data is extracted | Push those values into your system |
| It is certified | Store the evidence reference |
| Generated from a template | Trace automatically created documents |
| Filled in manually | Tell manual from automatic |

## Approvals

Approved or rejected. These two trigger the most work on the other side: approving usually unblocks something of yours, and rejecting usually opens a task.

> [!IMPORTANT]
> Subscribe only to what you will use. Listening to all twenty fills your log with events nobody processes, and when an important one fails it will be buried among them.

> [!WARNING]
> Each webhook delivery consumes a credit. Twenty events per case at high volume adds up; listening to three well-chosen ones costs a fraction and solves the same.

> [!NOTE]
> The three that cover most real integrations: case completed, request answered and approval decided. Those three automate nearly everything people want to automate.

**Can I choose which to receive?**

Yes, and you should.

**What if my system is down?**

Delivery is retried; check the failed queue.

**Can it be tested outside production?**

Yes, against the test environment.

## Ejemplos

**A team subscribes to all twenty events and two weeks later nobody reads the log.**

- Keeps three: case completed, request answered and approval decided

→ The log becomes readable again and consumption drops, without losing any automation.

**All twenty notifications are subscribed and the receiving system gets constant noise.**

- Subscribes only to the events that will be processed
- Adds the rest when there is something to do with them

→ The system receives what it can use and the log stays readable.

**You want to react to a document expiring and do not know which event covers it.**

- Checks the list of available events

→ The integration is built on what exists.

**A notification arrives twice because of a retry.**

- Treats the notification as idempotent by its identifier

→ The same event does not trigger two actions.

**The notification arrives and the receiving system does not know which file it refers to.**

- Includes the file identifier in the handling

→ The action is applied where it belongs.

**A flow changes and the notifications stop fitting.**

- Reviews the subscriptions when the process changes

→ The integration keeps up with the change.