Webhooks in Mumble: The Complete Guide to the Four Connection Points for External Systems

Summary

A webhook is a mechanism that lets Mumble push events to external systems (CRM, BI, an order management system, a ticketing system) in real time. Instead of your system having to ask Mumble “what happened?”, Mumble sends you a message the moment an event occurs. This article introduces the four webhooks Mumble offers, the differences between them, and how to choose the right one for each case. If you want to connect your WhatsApp to other systems in your business, this is the article to understand before you get started.

What a webhook is

A webhook is an HTTP request (usually a POST) that Mumble sends to a URL you provide, the moment a particular event occurs. The event’s data is delivered in the request body as JSON, and your system can process it and act accordingly.

A simple example:

1. A customer sends a message on WhatsApp.
2. Mumble receives the message and displays it in the chat.
3. At the same time, Mumble sends a POST to the URL you configured, with the message details as JSON.
4. Your system (CRM, support system, database) receives the data and can act on it: create tickets, update a record, trigger your own automation.

The main advantage: no polling required. Your system doesn’t have to ask Mumble every minute “is there anything new?”. The event is pushed to it the moment it happens.

Mumble’s four webhooks

Mumble offers four different connection points to external systems, each for a different scenario. The right choice depends on what you want to know and when.

Each one gets a dedicated section below.

1. Account-level webhook for incoming messages

This is the broadest webhook. Mumble sends it on every message that arrives from a customer to your account, with no additional conditions.

Where to configure it

In your account settings, under Settings → Technical Profile → Forward message to webhook. Just one field: the URL Mumble will send the requests to.

What’s in the payload

For every incoming message, Mumble sends JSON containing:

• Customer details (name, phone, customer ID).
• Message content (text or a media reference).
• Message type (text, image, file, audio, video).
• Conversation metadata (conversation ID, status, list).
• A timestamp.

What this webhook does not include

It’s important to know what it doesn’t send, so you don’t rely on it for things outside its scope:

• Delivery status (delivered, read, failed) of outgoing messages. If you want to know whether your message arrived, you need an automation webhook.
• Conversation status changes (new → in progress → closed). That’s an automation as well.
• Adding or removing lists.
• Internal Mumble events such as agent assignment or manually opening a conversation.

When to use it

Use this webhook when you want to forward every incoming message to an external system, for example:

• Mirroring every interaction in your CRM.
• Running your own real-time AI processing on the messages.
• Populating tickets in a support system.
• Replicating the messages to BI and analytics.

2. Automation webhook

This is the most flexible webhook. In the automations engine, one of the available actions is Send webhook. You build an automation with a trigger and conditions, and when it runs, it sends an HTTP request exactly to your specification.

Where to configure it

On the Automations page, create a new automation. Define a trigger (for example, “conversation status changed”) and conditions (for example, “to status = closed”). In the actions section, choose Send webhook, which opens two fields: URL and Payload.

The payload you build

Unlike the account-level webhook, which sends a fixed payload, here you build the payload exactly as needed. Each row includes:

• Key. The field name in the JSON, free text.
• Value. Either fixed text or a system variable (customer name, conversation status, campaign ID).

This means that if your system requires JSON in the form { "phone": "...", "event": "closed", "label": "..." }, you build exactly that. This flexibility lets you connect to any external system without needing an adapter in between.

Common triggers that lead to a webhook

• Conversation status changed to closed → sync the conversation outcome to your CRM.
• Customer added to the “hot lead” list → alert the sales team in an external system.
• Conversation inactive for X hours → notify a manager to review it.
• Agent self-assigned a conversation → log it for bonus calculation in your payroll system.

When to use it

This is the recommended webhook for most cases. Use it when you want to be notified about a specific event, not about every message. See Automations in Mumble, the complete guide.

3. HTTP node on the chatbot canvas

Within a chatbot flow, you can add an HTTP request node. This node sends a request to an external system when the chat reaches it, and it can receive a response back and use it later in the conversation.

What it enables

Unlike the two previous webhooks, which are one-way (Mumble sends and doesn’t wait for a meaningful response), this node is two-way: it sends, waits for a response, and uses it.

Examples:

• Retrieving order status. The chat asks for an order number, sends it to the e-commerce system, and receives back the status to show the customer.
• Checking appointment availability. The chat offers the customer available appointment slots, sends the request to the calendar, and receives a list of times.
• Verifying customer details. The chat asks for an ID number and checks your internal system to see whether the customer is registered.

When to use it

Use an HTTP node when the chatbot needs data that isn’t in Mumble, or when you want to perform an action in an external system as part of the conversation flow. See Building a chatbot in Mumble.

4. HTTP action in Dolores AI

In the Dolores AI agent, one of the actions you can configure is send an HTTP request. The difference from the chatbot HTTP node: here Dolores decides when to fire it, based on a description you give it.

How it works

You define an action with:

1. A plain-language description: “when should Dolores do this?”. For example: “when the customer says they want to cancel their subscription”.
2. The action: send an HTTP request, with a URL and payload.

During the conversation, Dolores analyzes the context and decides whether to fire the action. If the conversation matches the description, the action runs automatically.

When to use it

Use a Dolores HTTP action when the trigger is judgment-based and not known in advance. If you can write a clear rule (“when status changes to closed”), an automation is preferable. If the trigger is something that requires understanding context (“when the customer seems confused and wants to talk to an agent”), Dolores is the right tool. See Dolores AI, the getting-started guide.

How to choose the right webhook

Ask yourself:

• If you want every incoming message: the account-level webhook.
• If you want a specific event you can define with rules: the automation webhook.
• If you want to call an external system at a defined point in the chat: the HTTP node on the canvas.
• If the trigger is judgment-based and needs AI to understand it: the HTTP action in Dolores.

You can, and should, combine several of them. A realistic example: a business can set them all up at once. The account-level webhook streams every message to BI. Automations sync conversation events to the CRM. The chatbot retrieves order status during the conversation. Dolores fires actions when judgment is required.

Topics worth knowing

Security

A webhook sends customer data to a URL. Make sure:

• The URL is HTTPS (not HTTP). Without encryption, the data is exposed in transit.
• The receiving system authenticates the request. For example, using a secret key you add to the payload and check on the receiving end. Anyone who knows the URL can forge requests if there’s no authentication.
• You don’t pass sensitive information unnecessarily. If the receiving system doesn’t need the customer’s full phone number, don’t send it.

Reliability

Webhooks can fail. Common reasons: the receiving system is momentarily unavailable, the internet connection drops, the URL changed. Plan for this:

• Don’t rely on a webhook alone for critical actions. Add a periodic sync as a backup.
• Monitor on the receiving end: track “how many requests are expected versus how many were received”.
• A manual check once a week: if something looks wrong, see the next section.

No log in Mumble

Mumble does not keep a log of the webhooks it has sent. You can’t go back and see “what was sent yesterday at 3 PM”. Debugging has to be done on the receiving end (logs of the URL that receives the requests). This is something worth knowing in advance.

Best practices

• Test before production. Use a service like webhook.site or requestbin.com for an initial test. Send the webhook there and see exactly what Mumble sends. Once you’re confident, switch to the real URL.
• Add an authentication key. In every automation webhook, add a secret or token field with an agreed value, and make sure the receiving end verifies it before working with the data.
• Plan for idempotency. If the same webhook is sent twice by mistake (rare but possible), the receiving end needs to recognize this and not perform a duplicate action. Add a unique identifier to each event (for example, the conversation ID together with the event time).
• Keep the webhook URL secret. Anyone who knows the URL can send forged requests to it. Don’t publish it publicly.
• Document it internally. Record which webhooks you run, what payload each one sends, and where it goes. Two months from now, when something breaks, that documentation is the difference between a minute of fixing and a day of searching.
• Check response times. If the receiving system is slow to respond (more than 3 to 5 seconds), the webhook can fail. Make sure it’s ready to process requests quickly.

Common issues

The webhook doesn’t reach my system

Check in this order:

1. Is the URL correct and working? Try testing it with curl or Postman from the outside.
2. Is the URL on HTTPS? Webhooks to HTTP are sometimes blocked.
3. If it’s an automation webhook: is the automation actually enabled? Is the trigger really firing?
4. If it’s an account-level webhook: was it configured under Settings → Technical Profile?
5. Is there a firewall or IP restriction blocking requests from Mumble?

If everything is fine and it still doesn’t arrive, contact Mumble support with a specific example.

The webhook arrives but the format isn’t what my system expects

This depends on the webhook type:

• Account-level webhook: the format is fixed by Mumble. You need to adapt the receiving system.
• Automation webhook: you build the payload. Edit the key/value fields in the automation so they match what’s needed.

I want a webhook for delivery status (delivered/read/failed)

The way to do it: create an automation with a trigger on a message status change, and a Send webhook action. Note that the available triggers depend on your Mumble version; this may require a particular feature.

The webhook works sometimes and not others

Possible reasons:

• The receiving system is unstable. Check its uptime.
• Rate limiting on the receiving end. If there’s suddenly a burst of events, it may reject some of the requests.
• An undocumented change to the URL or the settings.

Check the logs on the receiving end. If there’s no record there of the requests that didn’t arrive, the problem is probably in the network between Mumble and your system.

The webhook is receiving forged requests from attackers

If you published the URL by mistake, or if it’s guessable, someone may be sending forged requests to it. Add a secret authentication key to every request in the payload, and verify it before processing the data. An attacker who doesn’t know the key won’t be able to forge requests.

I want a two-way webhook (for example, to give me a response the bot will use)

This isn’t possible with an automation webhook (which is one-way). But it is possible with the HTTP node on the chatbot canvas, which waits for a response and uses it later in the flow.

Related articles

• Automations in Mumble, the complete guide
• Building a chatbot in Mumble
• Dolores AI, the getting-started guide
• Mumble API, the complete guide
• Connecting Mumble to Make
• General account settings

The bottom line

Webhooks are the bridge between Mumble and your external systems. Choosing the right webhook depends on what you want to know: every message, a specific event, a point in the chat, or an AI decision. Most needs are met by automations with a webhook, and that’s the best starting point. When working with webhooks, insist on HTTPS, authentication, and a backup for reliability. An hour of proper planning saves weeks of debugging.