Webhooks: Use and configuration
Automated data exchange between the AI chatbot and external systems to optimise service processes
Webhooks enable real-time communication between different applications. In this process, one server (the sender) automatically sends an HTTP enquiry to another server (the recipient). In the context of moinAI, this means that data collected in the chat is transmitted to an external system, or information is retrieved from there, so that it can be displayed to users directly within the chat widget.
The prerequisites for using a webhook are an existing form or an AI agent in the Hub and an accessible target URL (API endpoint) for the external system.
-
2.1 Technical configuration
2.2 Advanced options (cookies & authentication)
2.3 Webhook actions before execution -
Use in chatbots
3.1 Webhooks as AI actions
3.2 Webhooks in forms
1. Benefits and functionality
The use of webhooks allows the AI chatbot to be seamlessly integrated with third-party systems such as CRM tools, product databases and e-commerce platforms. This offers the following benefits:
-
Automation: Processes such as booking appointments or checking order statuses take place directly within the conversation, enabling self-service interactions
-
Flexibility: Any REST webhooks can be integrated without the need for code modifications.
-
Contextual relevance: Information from the ongoing conversation is fed directly into the API query, e.g. customer status, current subpage or product interest.
➔ How webhooks function explained simply: the post office analogy 📩🏷️📯 (click to expand)
To illustrate the technical processes, we can draw a comparison with a hotel reception and the postal service.
📯 The webhook: The switchboard
In this analogy, the AI chatbot cts as a switchboard, much like a hotel reception desk. When a user approaches the chatbot with an enquiry (e.g. asking about a parcel's status), the chatbot does not have the necessary information stored in its own memory. A webhook acts here like a digital pneumatic tube or a direct call to the warehouse ( (backend oder shop system). The necessary data is transmitted, checked there, and the response is sent straight back to the chatbot to inform the user.
📩 The Body: The content of the message
Whilst the URL simply specifies the recipient's address, the body represents the actual message contained within the message. This is where the specific details required by the target system for processing are stored (e.g. customer number or meter reading).
- Default (standard): Time-saving consolidation and transmission of all information from a conversation in a single package. Due to frequent data overload and incompatible formats, its use with POST methods is not recommended, as interfaces (APIs) require precise data structures.
- Custom (individual): Comparable to a blank sheet of paper on which only the necessary information is noted in the exact format required. This ensures precise and efficient data transmission.
🏷️ The headers: The envelope
The headers correspond to the information on the envelope and the instructions for the delivery staff. They set out the framework to ensure that the content (body) is processed securely and correctly:
- Delivery instructions (authorisation): Acts as proof of identity or a stamp for a 'registered letter'. Using the authorization header and a security token (e.g. a JWT), the chatbot identifies itself as an authorised sender.
- Language specification (Content type): Informs the recipient system of the format used. For example, specifying application/json indicates that the content has been written in a specific technical language.
- Special labels (Custom headers): Correspond to individual identifiers such as an X-Api-Key. If these necessary identifiers are missing, the 'letter' will not be opened by the target system for security reasons.
|
Term |
Analogy |
Purpose |
|
Webhook |
Pneumatic tube / phone call |
The data exchange process |
|
Body |
Letter content |
The actual information (data) |
|
Header |
Letter envelope |
Security and framework conditions |

2. Create webhook
- You can access the overview in the Hub via the menu item Integrations → Webhooks (Push).
- Click the Edit button to open the list of existing webhooks.
- The Create webhook + button opens a new, blank form.

- Existing webhooks can be customised using the pencil icon.

- By clicking the Deploy button at the bottom/top right of the webhook editor, the webhook becomes available in both the preview and live environments and can be linked to AI agents or forms.
2.1 Technical Configuration
The basic settings for the interface are defined in the edit view.
-
Select a name: A custom name used for internal identification within the Hub. The name can be easily changed at any time.
-
Define context name: The API response is saved in the dialogue under this name. It is also possible to use the context name elsewhere as a reference, e.g. via handlebars. For this reason, the name should remain as consistent as possible, otherwise every link will require manual adjustment.
-
Enter target URL: The API address to which the data is sent. This can be an internal or external API. Handlebars can also be used here, so that the URL is not static but can be used dynamically.
-
Select method: Specify the HTTP method by which the webhook sends the data. By default, POST is used to send data and GET to retrieve it.

Dynamic placeholders (Handlebars)
Handlebars (the curly brackets {{...}}) act as dynamic placeholders. In the Hub, they are used to specify where the chatbot should insert information that is generated by users only at the moment of the conversation.
For instance, handlebars templates can be used to dynamically integrate values from the dialogue context into the target URL.
Example: https://api.beispiel.de/v1/orders/{{orderId}}/status. Here, orderId is replaced by the user’s actual entry.
2.2 Optional: Advanced options (cookies & authentication)
For specialised requirements, the editor offers additional control options:
-
Customise headers: Using the Add field option, you can define custom headers (e.g. content-type: application/json) to be sent with the enquiry to the API. Alternatively, you can load a standard set using the Template option. A typical example is the X-Api-Key for authenticating the enquiry. Here, any number of headers can be configured to meet the requirements of the target API.

- Body: The options are Default, Custom and No Body.

-
- Default: Time-saving consolidation and transmission of all information from a conversation in a single package. Due to frequent data overload and incompatible formats, its use with POST methods is not recommended, as interfaces (APIs) require precise data structures.
- No Body: This option is selected when no message content is required for the enquiry. This is the default for GET enquiries, where data is retrieved exclusively via the URL.
- Custom: This option allows for customisation of the body, enabling specific data to be sent to the API. This is particularly useful when more complex data structures need to be transferred. The body is configured in JSON format. Using handlebars, information from the dialogue context can be specifically accessed to integrate dynamic information such as customer data or responses.
- Use of cookies: Enabling this option means that cookies in the webhook request are accepted and used by the target system. This is particularly important for maintaining sessions across webhook calls. From a data protection perspective, you should check whether this needs to be specifically mentioned in the privacy policy. More information on data protection is provided in this article.
- Authentication: Here, you can choose between No authentication (security is handled, for example, via an API key in the header) and Basic Auth (request for username and password).

Security and protection against misuse (recommendation)
-
API key and JWT: Using an API key in combination with a JWT provides an additional layer of security. The API key is included in the header, whilst the JWT ensures that the enquiry is authenticated and made within a specific timeframe.
-
TLS/SSL encryption: All data transfers should be carried out via HTTPS to ensure that the data is encrypted during transmission and cannot be intercepted by third parties.
Each webhook configuration and API is tied to a specific use case. Separate webhooks must be set up for different functions (e.g. a product search via the Salesforce ProductSearch API and ticket creation via the Salesforce Ticket API). However, it is possible to combine multiple webhooks within a single form.
JWT (JSON Web Token)
You can think of a JWT as a digital festival wristband. Once obtained, it serves as proof for the rest of the process that the person has already been successfully verified.
2.3 Webhook actions before execution
Optionally, actions can be enabled that are executed immediately before the webhook is sent:
-
User Message History: Adds the conversation’s message history to date to the context. This is useful if the target system (e.g. a CRM) requires the full conversation context for further processing.
-
Save File URL(s): Saves the URLs of files that users have previously uploaded in the chat to the context. This is essential for processes where documents or images need to be transferred to a backend.

Clicking on the question mark opens a window with further information about the respective webhook actions.
3. Use in chatbot
Once a webhook has been configured, it can be used in various places within the chatbot.
3.1 Webhooks as AI Actions
AI actions enable the AI agent to initiate a query independently when required.
-
Go to Knowledge Base → RAG → and click Add Action + in the Actions & Follow-Up card to create a new action.
-
The link is established by selecting the previously created webhook under Choose tool.
-
Thanks to precise parameter descriptions, the AI agent knows which information (e.g. an ID) it needs to request in advance.
More information on AI actions can be found in this article.
3.2 Webhooks in forms
In forms, integration takes place at a fixed point in the query path.
-
In the form editor, click the plus icon at the desired location.
-
Select Webhook from the element bar.
-
Choose the desired webhook from the field that appears.


You can find more information about forms in this article.
4. Testing and Validation
To ensure correct functionality, each configuration should be tested.
-
Click the Test button in the top-right corner of the webhook editor to open the test environment.
-
Select a form for simulating the database.
-
Click Send test data triggers the enquiry and validates the API’s response.

-
You can also validate the function in the preview (for webhooks in forms) or in the AI Playground (for webhooks in AI actions). The AI Playground shows in detail how an AI action was executed.
5. Practical Examples
|
Use Case |
Method |
Benefit |
|
Order status |
POST |
Authenticates users and returns the current delivery status. |
|
Meter reading |
POST |
Securely transmits collected consumption data to the service provider’s backend. |
|
Product search |
GET |
Searches external catalogues (e.g. Shopify) based on keywords. |
|
Seminar availability |
GET |
Checks whether there are still places available using a seminar ID and returns the result to the chatbot. |
➔ Tutorial: Check order status (click to expand)
Checking the order status is one of the most common customer enquiries in e-commerce. As queries such as "Where is my order?" account for a large proportion of support volume, using a webhook to integrate with the shop system allows for an automated response to be generated. This informs users of the current status of their order or delivery without the need for manual intervention by customer service. As users often use the terms "order status" and "parcel tracking" interchangeably, this example covers both areas. The webhook sends a request to the shop system, retrieves the current order and delivery status, and the AI chatbot provides the relevant information.
What you will need:
- 1x data retrieval form
- 1x access to the shop system's API (e.g. Shopify, Shopware)
- 1x webhook for data updates to transmit the order status; in this example, it has the context name `order_status_response`
Each shop system outputs data in different formats. The code examples shown here must therefore be adapted to the specific variable names used in your own system.
1. Structure of the query process
To retrieve information from a shop system, the order is usually identified using two specific details: the order number and the email address. The process is divided into the following steps.
- Querying the order number: Retrieving the unique identification number of the order. Validation using RegExp (Regular Expression) is optional.
- Querying the email address: Additional validation to ensure compliance with data protection standards, including email format validation.
- Execution of the webhook: Transmission of the data to the shop system.
- Generating the response: Dynamic creation of the message based on the values returned by the system.
2. Configuring the webhook
To communicate with the shop system, a new webhook is created in the Integrations → Webhooks (Push) section.
- URL: https://api.your-shopsystem.de/v1/orders/{{orderId}}/status
- Method: POST (or GET, depending on API requirements)
- Context name (example): order_status_response
- Headers:
- X-Api-Key: <Dein-API-Key deines Shopsystems>
- Content-Type: application/json
- Body (example) in JSON format:
{
"orderNumber": "{{order_number_input}}",
"email": "{{email_input}}"
}

3. Optional: Authentication via login (alternative to email verification)
The enquiry process can be optimised through automatic identity recognition. If a person is already logged into their customer account, there is no need to manually enter their email address. In this case, only the order number needs to be entered to retrieve the dispatch status.
Form design with the conditional switch
The Conditional Switch element in the form is used to control whether a login is present or not.
- Select the element conditional switchin the form editor.
- The editing screen is opened via the three-dot menu behind a condition.
- In the Edit condition screen, the variable name, the condition operator and the compared value are defined.
- Click Edit to save the condition.
- The plus icon can be used to add further branches to map different login states.
The following three conditions are recommended for precise control:
- jwt = logout: This status indicates that the user was previously logged in but the session has ended. A message is displayed here with a link to log in again.
- jwt exists: The user is successfully logged in. The form immediately redirects to the order number query.
- uniqueUserId exists: This condition serves as a fallback if no authentication is present. The user is prompted to log in.



Variable names as jwt must be written exactly as they are passed by the external system (e.g. Shopify). Any deviation in spelling will cause the condition to fail.
The variable uniqueUserId must be written exactly as they are passed by the external system (e.g. Shopify). Any deviation in spelling will cause the condition to fail.
JWT (JSON Web Token)
A JWT can be thought of as a digital festival wristband. Once received, it serves as proof for the rest of the process that the person has already been successfully verified..
Webhook configuration for login authentication
To ensure the shop system recognises that the request originates from a previously verified person, the security token (JWT) must be included in the webhook.
This is done in the webhook configuration under Customise headers (optional):
- Field: Authorization
- Value: Bearer

Zweck dieser Konfiguration: Durch diesen Header weist sich der KI-Chatbot gegenüber der API als autorisierter Vertreter der eingeloggten Person aus. Das System erkennt das Token und gibt die Bestelldaten frei, ohne dass eine zusätzliche E-Mail-Validierung im Chat-Verlauf notwendig ist.
4. Logic of the response message (handlebars)
To respond to different return values from the system (e.g. 'cancelled', 'processing', 'shipped'), Handlebars templates with if statements are used in the form's text block. This translates technical status descriptions into customer-friendly text.
Example of a code snippet for the status response:
{{#if shopify_order_status_url}}
{{#if shopify_shopify_fulfillments}}
{{#if (eq shopify_status "pending")}}
Your order has been processed but has not yet been dispatched.{{/if}}
{{#if (eq shopify_status "open")}}
Your order has been dispatched.{{/if}}
{{#if (eq shopify_status "success")}}
Your order has been confirmed.{{/if}}
{{#if (eq shopify_status "cancelled")}}
Your order has been cancelled.{{/if}}
{{#if (eq shopify_status "error")}}
There was an error with the delivery.{{/if}}
{{#if (eq shopify_status "failure")}}
Something went wrong with the delivery.{{/if}}
{{else}}
Your order has not yet been dispatched.{{/if}}
{{else}}
There is currently no order matching your details. Please check your details again or check the order status page:{{/if}}

Every shop system outputs data in different formats. The code examples shown here must therefore be adapted to the specific variable names used by your own system.
5. Dynamic buttons and fallbacks
In addition to the text block, you can use buttons that change their behaviour based on the webhook result. This is particularly useful for linking directly to the shipping provider's (e.g. DHL) tracking service.
- Conditional button text: The button displays "View shipping status" only if a parcel has been dispatched. Otherwise, a generic text such as "Order status" appears.
{{#if order_status_response.tracking_url}}Track shipment{{else}}Go to customer account{{/if}}
- Conditional button URL: The link leads either directly to the tracking URL or, as a fallback, to a general FAQ page or the customer account.
{{#if order_status_response.tracking_url}}{{order_status_response.tracking_url}}{{else}}https://yourshop.com/login{{/if}}
This logic ensures that users are always offered a helpful next destination (fallback to the customer account or FAQ) if no tracking number is yet available.
Such conditions are implemented in buttons using Handlebars syntax within the button text and button URL.

Every shop system outputs data in different formats. The code examples shown here must therefore be adapted to the specific variable names used by your own system.
6. Best Practice: Authentication and Security
As an additional security check, the order status query can be linked to the user's login status. By using contextual information, it is possible to check whether a user is already logged in.
-
Precise validation: Using RegExp for the order number (e.g. checking for 11 digits and a leading digit of '9') minimises faulty API calls and improves the user experience.

-
Security check: The combination of order number and email address serves as verification.