Using the /webhooks By configuring webhooks in the product, housed under the set of endpoints in the product/integrations endpoints with "type": "webhook", custom callback behaviour can be configured to trigger upon specific events. The available events are:
...
In terms of configuring webhooks, the swagger documentation shows how to create webhooks using the POST method .in /integrations:
...
At minimum, a target url or ip address and an event for which to trigger a webhook need to be configured:
| Code Block |
|---|
{
"type": "webhook",
"events": ["document_predict"],
"target": "http://localhost:3000/alfred/document_predict"
} |
Some simple examples of configured webhooks for the “document_predict" and “document_evaluate” event (these examples are used internally to couple our UI with the API):
...
Additional features:
...
Optionally, authorization headers can also be configured throught the “header” field
...
:
A custom (static) authorization (f.e. Bearer token) can be configured in the webhook, which will be sent back as header with the webhook’s POST request. This allows verification and authentication on the client’s side. For example, adding that to the example above:
| Code Block |
|---|
{
"type": "webhook",
"events": ["document_predict"],
"target": "http://localhost:3000/alfred/document_predict",
"headers": {"Authorization": "Bearer abcdefg1234567989"}
} |
Upcoming extensions:
Retry logic with exponential backoff. In case of the webhook receiving anything besides a succes status code (200), the webhook will re-attempt it’s delivery with an exponential backoff system (2^n seconds) for a maximum of 10 attempts.
Introduction of Inbox or Project specific webhooks. Currently, all documents processed in an organization trigger the same webhooks. The expansion would allow to specifically configure webhooks per Inbox or Project, as well as pass this information along in the payload.