Webhooks

By configuring webhooks in the product, housed under the set of /integrations endpoints with "type": "webhook", custom callback behaviour can be configured to trigger upon specific events. The available events are:

• document_text: this event triggers the sending of the document text obtained by OCR

• document_split: this event triggers the sending of section information for a document

• document_predict: this event triggers sending all predictions made on a document

• document_evaluate: this event triggers sending the final, reviewed version of a document once feedback has been received

• document_delete: this event triggers sending a document id when it is deleted

• document_fail: this event triggers sending a document id when a document has failed to process

In general, the payload sent by the webhooks has the following form:

The expected payload in “data” for both the predict and evaluate event is the same as the default document JSON.

For the other events, the resulting output will have the following form:

document_text

document_split

document_delete

document_fail

In terms of configuring webhooks, the swagger documentation shows how to create webhooks using the POST method in /integrations:

Open

At minimum, a target url or ip address and an event for which to trigger a webhook need to be configured:

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):

Open

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:

Additionally, we now have Inbox specific webhooks. A recent expansion allows to specifically configure webhooks per Inbox, as well as pass this information along in the payload. The configuration for this will then look as follows:

Retry_backoff timings

• 0: immediately

• 1: retry_backoff * 2^0 seconds after attempt 0, so 30 seconds later in the example

• 2: retry_backoff* 2^1 seconds after attempt 1, so 1 minute after attempt 1 and 1'30 after initial attempt

• 3: retry_backoff* 2^2 seconds after attempt 2, so 2 minutes after attempt 2 and 3'30 after initial attempt

• 4: retry_backoff* 2^3 seconds after attempt 3, so 4 minutes after attempt 3 and 7'30 after initial attempt

• 5: retry_backoff* 2^4 seconds after attempt 4, so 8 minutes after attempt 4 and 15'30 after initial attempt