Webhook

 What Is a webhook?

A webhook is a method that allows one application to automatically send data to another application when a specific event occurs. Webhooks are commonly used to connect software systems and trigger actions in response to events without requiring the receiving application to continuously request new information.

For example, when a user sends a new message in a chat, the messaging platform can use a webhook to notify an external app. Then the app processes the message, triggers a bot, updates an analytics system, starts a moderation workflow, or performs another action.

Webhooks are event-driven. Instead of repeatedly asking a system whether something has changed, the receiving application provides a URL—known as a webhook endpoint—where event data can be delivered when a relevant change occurs. This makes webhooks particularly useful for real-time and automated integrations between applications.

How webhooks work

A webhook typically connects two systems: the application where an event occurs and the application that needs to know about it. The process generally follows several steps:

An endpoint is configured. The receiving app provides a URL where webhook requests should be sent. This endpoint must be publicly reachable over HTTPS—a common practical hurdle during development, often addressed with tunnelling tools (e.g., ngrok) or by opening the appropriate firewall/network rules before go-live. Events are selected. The application subscribes to particular event types that it wants to receive.
An event occurs. For example, a message is posted, a user performs an action, or another relevant change takes place. The source application creates a webhook request. Information about the event is placed in a structured payload. The request is sent to the webhook endpoint. Webhooks commonly use an HTTP POST request to deliver this data. The receiving application processes the event. It can store the information, trigger another workflow, send a notification, call an API, or perform another action.

The receiving application acknowledges receipt. Senders typically judge delivery success by HTTP status code—a 2xx response tells the sender the webhook was received successfully; anything else (or no response) usually triggers retry logic. Because of this, receivers should acknowledge quickly (often within a few seconds) and do any heavier processing asynchronously, rather than making the sender wait on slow downstream work.

This process allows applications to respond to events shortly after they occur without constantly checking the source system for updates.

Webhook events

A webhook event is the occurrence that causes a webhook to be triggered. The available events depend on the application providing the webhook. In a chat or online community platform, webhook events might include:

• New message being sent
• Message being edited or deleted
• User joining or leaving a community
• Reaction added
• User applying to the bot
• Moderation action performed
• User blocked, muted, or banned
• New report submitted
• Room created
• Livestream or community event started

Applications do not necessarily need to receive every available event. Instead, integrations can subscribe only to the events relevant to their functionality. For example, a moderation system may subscribe to new-message events, while an analytics platform may need events relating to user activity and participation.

Selecting relevant events reduces unnecessary data processing and makes integrations easier to manage. Many providers also send a test or “ping” event when a webhook is first configured, to confirm that the endpoint is reachable and correctly set up before real event traffic begins.

Webhook payloads

A webhook payload is the data sent to the receiving application when an event occurs. Payloads are usually structured in a machine-readable format such as JSON, though some providers use XML or form-encoded payloads instead. The exact structure depends on the provider and event type.

A payload can contain information such as:

• Event type
• Event or delivery ID
• Timestamp
• User ID
• Room or channel ID
• Message ID
• Message content
• User action
• Object status
• Relevant metadata

For example, a new-message webhook might contain information about who sent the message, which room it was posted in, when it was sent, and the message itself.

The receiving application reads the payload and determines what should happen next. It is important to distinguish the event from the payload: the event is what happened, while the payload is the structured information describing what happened.

Webhooks vs. APIs

Webhooks and APIs are often used together, but they serve different purposes. An API allows one application to request information or perform an action in another system. The requesting application initiates the interaction. A webhook works in the opposite direction. The source application initiates the interaction when a subscribed event occurs and automatically sends information to the receiving application. Consider a chat application that needs to know whether new messages have appeared.

Using an API, the application could repeatedly request the latest messages: Application > API > “Are there any new messages?” This approach is known as polling. With a webhook, the messaging system sends an update when the message actually appears: New message> Webhook> Application

Webhooks can therefore reduce unnecessary requests and provide event-driven updates without continuous polling.

The two technologies are complementary rather than competing. A webhook might notify an application that something has happened, while an API can then be used to retrieve additional information or perform an action in response.

Webhooks vs. WebSockets

Webhooks and WebSockets can both support real-time or near-real-time applications, but they work differently. A webhook normally sends an HTTP request when a particular event occurs. Once the request has been delivered and processed, that interaction is complete.

A WebSocket maintains a persistent connection between systems. Once established, the connection can remain open so that data can be exchanged continuously in both directions.

This makes WebSockets particularly suitable for highly interactive experiences such as live chat, where messages and other updates need to move continuously between connected users and the server.
Webhooks are often better suited to notifying external backend systems about specific events.

For example, a chat application might use WebSockets to deliver messages instantly to users participating in a conversation, while simultaneously using a webhook to notify an external bot, analytics service, or automation system that a new message has been created.

The two technologies can therefore operate together within the same communication infrastructure.

Webhooks in Chat and Online Communities

Webhooks are particularly useful in chat and community platforms because these environments generate a continuous stream of user actions and events.
A community platform can use webhooks to communicate these events to other systems without requiring those systems to monitor the community continuously.

For example, a new chat message could trigger a webhook that sends the message to an external AI agent. The agent processes the message and can then use an API to send its response back to the chat.
Webhooks can connect activity with:

• Moderation system
• AI bots
• Analytical platforms
• CRM
• Customer support instruments
• Notification tools
• Data storages
• Internal business systems

This allows chat and community activity to become part of a wider product or business workflow.
For example, a company could analyse community activity in its analytics environment, send relevant user events to its CRM, or trigger an external moderation process when particular activity occurs.

Common webhook use cases

Because webhooks can trigger external workflows automatically, they are used across many types of software integrations.

Bots and AI agents

Webhooks can notify bots and AI agents when relevant activity occurs.
For example, a bot can receive an event when a user sends a message or mentions the bot. It can process the webhook payload, determine an appropriate response, and use an API to send that response back to the conversation.

Moderation

Community platforms can use webhooks to connect conversations with external or internal safety tools. A new message, user report, or moderation event can trigger additional analysis, logging, alerts, or administrative actions.

Analytics

Webhook events can be sent to analytics infrastructure to help organisations understand community activity,

participation patterns, message volumes, engagement, and other user behaviour.

CRM Integration

Relevant community events can be connected to customer profiles in CRM systems. This can help organisations connect community participation with other parts of the customer relationship rather than treating community activity as an isolated source of data.

Notifications

Webhooks can trigger email, mobile, internal, or other notifications when important events occur.
For example, a community administrator could receive an alert when a particular moderation event requires attention.

Automation

Webhooks are frequently used to start automated workflows. One event can initiate several subsequent processes—for example, recording data, notifying another system, running an AI model, or requesting additional information through an API.

Webhook security

A webhook endpoint is accessible over a network and may receive data that triggers actions in another system. For this reason, webhook implementations need appropriate security controls. HTTPS should be used to encrypt webhook data while it is being transmitted.

Webhook providers can also use secrets and cryptographic signatures to allow the receiving system to verify that a request was generated by the expected sender and that the payload has not been altered.
Applications should not automatically trust incoming data simply because it reaches the correct webhook URL.

The receiving system should validate the request according to the webhook provider’s security requirements before performing sensitive actions.

Webhook endpoints should also return only the information necessary to acknowledge the request and should avoid exposing credentials, secrets, or unnecessary internal information.

Webhook delivery and retries

Webhook delivery can fail. The receiving server might be unavailable, experience a network problem, take too long to respond, or return an error. Webhook systems therefore need to account for delivery failures.

Delivery outcomes are usually communicated through HTTP status codes. A 2xx response shows success; timeouts, 4xx, or 5xx responses indicate a failure and retry. Depending on the provider, unsuccessful webhook deliveries may be retried automatically or made available for  redelivery.

This introduces another important consideration: the same event may sometimes be delivered more than once. Receiving applications should therefore be designed to recognise duplicate deliveries when necessary. A common approach is to associate each event or delivery with a unique identifier and record which events have already been processed.

This principle is known as idempotency: processing the same event more than once should not unintentionally perform the same action multiple times.
For example, if a webhook triggers a user notification, a duplicate webhook delivery should ideally not result in the user receiving the same notification several times.

What needs to be considered for a webhook integration?

Successful delivery acknowledgement (returned quickly, with heavier processing handled asynchronously)

• Timeouts
• Retry policies
• Duplicate deliveries
• Unique event or delivery IDs
• Unvaried processing
• Event ordering
• Logging and monitoring
• Recovery after downtime

These mechanisms make webhooks more reliable when they are used as part of production integrations, automation systems, chat platforms, and online communities.

Read about the ways to make in-app real-time messaging secure