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 credentials that can be reused across multiple webhooks. By centralizing authentication, you avoid having to repeatedly configure and expose credentials for every integration.

Authentication Modes

The authorization modes supported in the Authentication profiles are:

• Basic Authentication
• OAuth 2.0 Client Credentials
• Authorization Headers 

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
  An allowlist 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.

Authorization Headers 

The Authorization Header mode provides a simple yet flexible way to include custom authorization tokens or headers in your webhook requests. This is ideal when the target system expects an API key or bearer token in a specific header format, such as Authorization: Bearer <token>.

Fields

• Profile name
  A descriptive label for this authentication profile. Use this to easily identify and reuse the profile in multiple webhooks.
• Header name
  The name of the HTTP header that carries the authentication information.
  By default, this is set to Authorization, but you can modify it if your target system expects a custom header (e.g., x-api-key).
• Header value
  The value to include in the header. Typically this follows the format Bearer: [TOKEN], where [TOKEN] is your API key or bearer token.
  You can adjust this to match the exact requirements of the receiving system.
• Allowed domains
  An allowlist of domains that can use this authentication profile. This prevents credentials from being used for unintended or unauthorized destinations.

Usage

When a webhook uses this profile, the system automatically appends the configured header to the outgoing HTTP request.
For example: Authorization: Bearer <token>

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.