Integrations
Letting your system find out by itself
Receiving a notification when something happens, instead of polling every five minutes.
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.
Watch out
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.
Worth knowing
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.
A real case
The situation
An ERP needs to know when a subcontractor is cleared for site access.
What you do
- Subscribes to the case-completed event
- Verifies each notification's signature
- Marks the subcontractor in its own system
What you get
The gate stops phoning the office to ask who may enter.
The situation
The ERP does not learn that a supplier completed their file and purchasing keeps blocking orders.
What you do
- Configures the automatic notification on file completion
- The ERP marks the supplier as approved on receiving it
What you get
The order unblocks the same day the supplier delivers, with nobody checking anything.
The situation
Somebody logs in every morning to see whether anything changed.
What you do
- Receives a notification only when what matters changes
What you get
The daily check disappears and the notice arrives when there is something to do.
The situation
Notifications arrive about everything and the receiving system saturates.
What you do
- Subscribes only to the events that will be used
What you get
The system receives what it knows how to process.
The situation
A notification fails and nobody knows it was lost.
What you do
- Checks the delivery log and the retries
What you get
The lost notification is reprocessed rather than vanishing.
The situation
The receiving system is down an hour and ten notifications are lost.
What you do
- Configures retries and checks what is pending
What you get
The outage does not leave a hole in the data.
This article answers
- webhooks to receive events
- notify my erp when someone signs
- real-time integration
- available api events