Skip to navigation
Applications

Webhooks

Where the platform tells your backend what happened — configured once, on the application

View as Markdown

Almost everything INFONITE does takes as long as an institution takes: an execution runs for seconds or minutes, a session waits for a person. There are two ways to find out it is done — synchronous, where your backend polls our state endpoint on a loop, and asynchronous, which is this screen.

A webhook is a server-to-server call: you register an HTTPS URL on your application, and the platform sends your backend an HTTP POST the moment the event happens — whether or not anyone has a browser open. It is not the widget’s redirect, which moves a person’s browser and carries no data.

It is set up on one screen — App Settings → Webhooks — out of two pieces:

An endpoint

A destination: a name, the HTTPS URL and, if you want one, an authentication header. Stated once and reused by every event that goes there.

A rule

A binding: this event goes to that endpoint, with its own on/off switch. With no rules, nothing is delivered — and nothing else changes.

The number beside the Webhooks section in App Settings is how many events are bound right now. Every endpoint has a test action: use it before binding anything, so a firewall or a certificate problem shows up on your terms rather than on the first real event. Your endpoint answers the test as it answers every real event: a 2xx as soon as the payload has arrived, whatever it does with it afterwards — answering a delivery explains why.

Webhooks belong to the application, like everything technical: two applications, two sets of endpoints and rules, and nothing crosses between them — see organizations, applications and users.

Receiving Webhooks — the guide

The full walkthrough, with screenshots: registering an endpoint, the test delivery, binding engine and flow events, what a valid destination URL looks like, authenticating the call, answering a delivery, and the addresses to allow-list.