Skip to main content

Overview

Webhooks are a way for applications to automatically communicate with each other in real time. Instead of constantly checking (polling) another service for updates, a webhook lets that service send data to you automatically whenever an event happens. Webhooks act as the communication bridge that keeps your real-time world in motion, synchronizing your applications, agents, and services through instant event notifications

Importance of Webhooks in ART​

In the ART ecosystem, webhooks play a vital role in enabling real-time communication and automation between different components and external services. ART Webhooks extend the ADK’s real-time messaging capabilities by acting as HTTP-based interceptors. They enable seamless integration between ADK channels and external systems, allowing you to validate, enrich, or process message data as it flows through the pipeline.

For example, when a message is sent through a channel or a user joins/leaves a session, ART can trigger a webhook to notify an external system. This makes it easy to:

  • Integrate with third-party tools such as CRMs, analytics dashboards, or notification systems.

  • Automate workflows like sending alerts, logging activities, or updating records in real time.

  • Extend ART’s capabilities by allowing external applications to respond immediately to ART events.

How Webhooks Work​

Webhooks operate through a simple but powerful event-driven mechanism that allows systems to communicate automatically in real time.

At the core, a webhook works as a one-way notification system - when an event happens in one application, it immediately sends a message to another application through an HTTP request. This eliminates the need for constant polling or manual updates.

1. Event Trigger​

Every webhook begins with an event that occurs within the system, such as a new message, a user joining a channel, or a process reaching completion. When such an event takes place, it triggers the webhook mechanism.

2. Payload Preparation​

Once triggered, the system collects relevant details about the event - known as the payload. This payload typically contains structured data (usually in JSON format) describing what happened, where it happened, and who or what was involved.

3. HTTP Request to the Endpoint​

The system then sends the payload as an HTTP POST request to a predefined endpoint URL. This endpoint is a public URL hosted by the receiving application or service that’s ready to process incoming webhook data.

4. Processing the Webhook​

Upon receiving the HTTP request, the endpoint processes the payload. This could involve validating the data, updating records, triggering further actions, or sending notifications.

5. Response Handling​

After processing, the receiving system typically sends back an HTTP response (like a 200 OK status) to acknowledge that it successfully received and handled the webhook data.

Webhooks enable a push-based communication model - meaning information flows outward the moment it’s available, rather than waiting to be requested. This design makes them ideal for integrating external services, extending workflows, and maintaining real-time awareness across distributed systems.