Webhooks changed how I think about AI agent automation. Before webhooks, my automations were all time-based: check for new emails every 5 minutes, scan for GitHub notifications every 10 minutes, poll the server status every hour. With webhooks, the events come to me. No polling. No delays. No wasted API calls checking when nothing has changed.
The difference is like checking your mailbox every 5 minutes versus having a doorbell that rings when mail arrives. One is inefficient and annoying. The other just works.
What Webhooks Do for an AI Agent
A webhook is a URL that receives HTTP POST requests when something happens. GitHub can send a webhook when a PR is opened. Stripe can send a webhook when a payment fails. Your monitoring system can send a webhook when a server goes down.
OpenClaw can receive these webhooks and respond to them. The response isn’t just “log it” — it’s “understand what happened and take intelligent action.”
GitHub PR webhook → OpenClaw reads the PR, reviews the code, posts a summary and initial feedback as a comment. This happens within 30 seconds of the PR being opened. With polling, there’d be a 5-10 minute delay.
Payment failure webhook → OpenClaw checks the customer’s history, drafts an appropriate email (existing customer vs. new customer, first failure vs. recurring issue), and queues it for review. Response time: under a minute.
Server alert webhook → OpenClaw checks the affected server’s recent logs, identifies likely causes, and posts a preliminary diagnosis to the team’s Slack channel. The team gets context along with the alert, not just “Server X is down.”
Setting Up Webhooks
OpenClaw can receive webhooks through its API endpoint. The setup:
1. Configure OpenClaw to listen for webhooks on a specific endpoint
2. Set up the external service to send webhooks to that endpoint
3. Write handling instructions in your agent config: “When you receive a GitHub webhook with action ‘opened’ and type ‘pull_request’, review the PR and post a comment”
The external service needs to reach your OpenClaw instance, which means either: your server has a public URL (easiest), you use a tunnel service like ngrok or Tailscale (for home setups), or you use a webhook relay service that queues webhooks and delivers them when your agent checks in.
The Workflows I’ve Built
Deploy notification pipeline. When code merges to main (GitHub webhook), OpenClaw:
1. Checks if CI passed
2. Triggers deployment if CI is green
3. Monitors the deployment for 5 minutes
4. Posts a status update to Slack with the changes deployed
5. If anything goes wrong, rolls back and alerts the team
This replaced a manual deployment process that took 15 minutes of human attention per deploy. Now it takes zero human attention for successful deploys and about 2 minutes for failed ones (reviewing the alert and deciding whether the rollback was sufficient).
Customer support triage. When a support ticket is created (help desk webhook), OpenClaw:
1. Reads the ticket content
2. Checks the customer’s account status and recent history
3. Categorizes the issue (billing, technical, feature request, other)
4. For common issues: drafts a response
5. For complex issues: assigns to the right team member with context
6. For urgent issues: sends an immediate Slack notification
Content monitoring. When someone mentions our product on social media (monitoring tool webhook), OpenClaw:
1. Reads the mention and assesses sentiment
2. Positive mentions: logs for social proof collection
3. Neutral mentions: logs and skips
4. Negative mentions: alerts the team with context and suggested response
Common Mistakes
No signature verification. Webhooks are HTTP requests from the internet. Anyone who knows your endpoint URL can send fake webhooks. Always verify webhook signatures — most services sign their webhooks with a secret key. Reject requests with invalid signatures.
No idempotency. Webhook services sometimes send the same event twice (network retries, service restarts). Your handler should produce the same result whether it receives an event once or five times. Include a check: “Have I already processed event with this ID? If yes, skip.”
Slow processing blocking the response. The external service expects a quick response (usually within 5-30 seconds). If your handler takes 2 minutes to process the event, the service may timeout and retry, causing duplicate processing. Solution: respond immediately with a 200 status, then process the event asynchronously.
No error handling for downstream failures. Your webhook handler calls an API that’s down. Now what? The event is lost unless you’ve implemented retry logic or a dead-letter queue for failed events. I store all webhook payloads and mark them as processed/failed. Failed events get retried automatically after 5 minutes, up to 3 times.
When to Use Webhooks vs. Polling
Use webhooks when: The external service supports them, you need near-real-time response, and the event frequency is irregular (could be 0 events per hour or 50).
Use polling when: The service doesn’t support webhooks, you’re aggregating data over time (checking metrics, not responding to events), or your infrastructure doesn’t have a public endpoint.
In practice, I use webhooks for all event-driven workflows and polling only for data aggregation tasks. The combination covers everything I need.
🕒 Last updated: · Originally published: January 4, 2026