Webhooks

In order to support bidirectional system integration, AlisQI can invoke external webhooks upon event triggers within AlisQI. These triggers are insert, update, delete or manual actions.

Workflows

Webhooks are one of the actions in a Workflow.

When creating a Workflow you can specify the Signal of the workflow to be a webhook call. That means that when the workflow triggers, the webhook will be called.

In the webhook widget you can configure the webhook call. 

Authentication

To authenticate your webhook calls, you can set up Authentication Profiles in the Integration Hub. This enables you to securely store Basic Authentication or OAuth 2.0 Client Credentials and reuse these credentials across multiple webhooks. By centralizing authentication, you avoid having to repeatedly configure and expose credentials for every integration.

Authentication Modes

Basic Authentication

Basic Authentication is a straightforward method where a username and password are included in the request header. This is suitable for systems that support HTTP Basic Auth but do not require more advanced token-based authentication.

Fields

• Profile name: A descriptive label for this authentication profile. Helps you identify and reuse it later.

• Username: The login name that the target system expects.

• Password: The corresponding password. Stored securely and never displayed in plain text after saving.

• Allowed domains: A whitelist of domains that are permitted to use this authentication profile. This ensures credentials are not accidentally used for unintended targets.

Usage

When a webhook uses this profile, the system will automatically add an Authorization: Basic <base64(username:password)> header to the outgoing HTTP request.

OAuth 2.0 – Client Credentials

The Client Credentials flow is an OAuth 2.0 mechanism designed for server-to-server authentication. Instead of using a fixed username/password, the system dynamically requests an access token from an authorization server and uses that token in webhook calls.

Fields

• Profile name: A descriptive label for this profile.

• Client ID: The identifier issued by the authorization server. Identifies your application.

• Client secret: A secret known only to your application and the authorization server. Used to prove your app’s identity.

• Scope: Defines the level of access requested (e.g., read:orders, write:users). Optional, depending on the target API.

• Access token URL: The endpoint of the authorization server where the system exchanges client credentials for an access token.

• Allowed domains: Restricts the use of this authentication profile to specific target domains.

Usage

When a webhook uses this profile:

1. The system sends a POST request with the Client ID and Client Secret to the Access token URL.

2. The authorization server responds with an access token.

3. The webhook call is sent with an Authorization: Bearer <token> header.

This ensures that each call uses a valid, time-limited token rather than a static password.

Best Practices

• Use Basic Authentication only for simple systems that do not support OAuth 2.0.

• Prefer OAuth 2.0 Client Credentials for modern APIs, as tokens are short-lived and reduce the risk of leaked long-term credentials.

• Always configure Allowed domains to prevent misuse of credentials in unintended webhooks.

• Choose meaningful Profile names so that administrators can easily manage and audit authentication profiles.

Payload

The webhook payload is identical to that of the getResults API operation.
See the in-app API documentation for a detailed description of the payload structure.

{ 	
"@id": 1337,	
"date":"2001-02-03 14:15:16",
"numeric":123,
"numerico":"<321",
"select":"option value",
"check":true
}

Error reporting

Provide an error reporting email address to receive error reports in case of failed webhook invocations.

Overview of all webhooks

The Integration hub provides a list of all outgoing webhooks, as well as logs on their invocations.