Integrations
The twenty events it can notify your system about
The complete catalogue of what can trigger something on your side.
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.
Watch out
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.
Worth knowing
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.
A real case
The situation
A team subscribes to all twenty events and two weeks later nobody reads the log.
What you do
- Keeps three: case completed, request answered and approval decided
What you get
The log becomes readable again and consumption drops, without losing any automation.
The situation
All twenty notifications are subscribed and the receiving system gets constant noise.
What you do
- Subscribes only to the events that will be processed
- Adds the rest when there is something to do with them
What you get
The system receives what it can use and the log stays readable.
The situation
You want to react to a document expiring and do not know which event covers it.
What you do
- Checks the list of available events
What you get
The integration is built on what exists.
The situation
A notification arrives twice because of a retry.
What you do
- Treats the notification as idempotent by its identifier
What you get
The same event does not trigger two actions.
The situation
The notification arrives and the receiving system does not know which file it refers to.
What you do
- Includes the file identifier in the handling
What you get
The action is applied where it belongs.
The situation
A flow changes and the notifications stop fitting.
What you do
- Reviews the subscriptions when the process changes
What you get
The integration keeps up with the change.
This article answers
- which events does the platform emit
- available webhooks list
- notify my erp when something happens
- case and request events