Webhooks and Agent Readiness: Why Real-Time Beats Polling for AI Agents
AI agents cannot poll endlessly — it burns budget, misses events, and turns every API into a DDoS target. Webhooks are how agent-ready businesses broadcast state changes. HMAC signing is non-negotiable. The top scorers in our 500-business scan (Stripe 68, GitHub 67, Slack 68, Resend 75) all have them. Here is why webhooks are the backbone of the agent economy.
The Polling Problem: Why Agents Go Broke Waiting for News
Imagine a booking agent that has to tell a user “your appointment is confirmed” the moment the vendor accepts it. Without webhooks, the agent has one option: pollGET /appointments/{id}every five seconds and wait for the status to change. Multiply that by every appointment, every user, every agent session, and you get a brute-force traffic pattern that costs tokens, costs bandwidth, and costs latency — the agent still learns about the confirmation up to 5 seconds late.
Now imagine a hundred agents polling the same API. That is 7,200 redundant requests per hour for a resource that changed twice. The API owner rate-limits them, the agents hit 429s, and the user experience collapses. Polling does not scale in the agent economy because agents scale faster than humans ever did.
Webhooks invert the cost equation. The server broadcasts once when something changes, every subscribed agent receives it in under a second, and no agent spends a token on empty polling loops. This is why webhooks are scored inside D8 Reliability (13% weight) — they are the single largest reliability win an API can ship.
The Five Core Events Every Agent-Ready Business Should Broadcast
You do not need hundreds of webhook events to go from invisible to agent-ready. You need five. These are the state changes agents actually listen for across every vertical we have scanned.
order.created
Fires the moment an order is placed. Agents subscribing to this can trigger fulfillment, accounting entries, or downstream orchestration without polling the orders endpoint every 30 seconds.
Seen in the wild: Shopify, WooCommerce, Stripe Checkout all emit this shape
payment.succeeded
The single most important financial signal. Agents listening for payment.succeeded can release digital goods, send receipts, and update subscription state in under a second.
Seen in the wild: Stripe emits payment_intent.succeeded, charge.succeeded, and invoice.paid
inventory.updated
Agents shopping on behalf of users need live stock state. Without this event, every purchase becomes a gamble: is it in stock now, or was it in stock 5 minutes ago when we last polled?
Seen in the wild: Shopify inventory_levels/update, WooCommerce product.updated
appointment.booked
For service businesses — dentists, salons, consultants — booking events let calendar agents reconcile multi-party schedules without race conditions.
Seen in the wild: Calendly invitee.created, Acuity appointment.scheduled
support.resolved
Agents triaging tickets on behalf of support teams close the loop when support.resolved fires — updating CRMs, measuring CSAT, and tracking resolution SLAs.
Seen in the wild: Zendesk ticket.solved, Intercom conversation.closed
Each of these events maps to a real agent workflow: fulfillment orchestration, receipt generation, inventory-aware shopping, multi-party scheduling, and SLA tracking. Ship all five, document their payloads, and you have covered the surface area that matters for 90%+ of general-purpose agents in 2026.
HMAC-SHA256: The Non-Negotiable for Agent Trust
Every production agent framework refuses unsigned webhooks by default. LangChain, CrewAI, OpenAI Agent SDK, and Anthropic Computer Use all ship with signature-verify helpers because unsigned webhooks cannot be trusted with money, inventory, or identity. An attacker who learns your webhook URL can forge payment.succeeded events all day long and drain every agent acting on them.
The fix is HMAC-SHA256: a keyed hash of the payload, transmitted in a request header, verified by the receiver against a shared secret. If the hash does not match, the event is dropped. This is a two-line addition on the sender side and a three-line verification on the receiver side.
Scoring implication: AgentHermes flags SHA-1 signing as a partial-credit signal in D7 Security (12% weight). Switching to SHA-256 is usually a 10-line change and raises D7 by 1-2 points. Twilio is the most common laggard in our 500-business scan.
Retry Logic: What Happens When the Agent Receiver Is Down
Agents crash. Endpoints 503. Deploys cause 30-second gaps. Webhooks that fire once and forget will silently lose events every time any of that happens. The agent that should have been notified about a paid invoice is never notified, and the user does not get their digital product.
Every top-scoring webhook provider in our scan retries with exponential backoff. The specifics vary but the shape is consistent: 5-24 attempts over 24-72 hours with increasing delays. Stripe retries for 3 days. Resend retries for 24 hours. GitHub retries 3 times within 30 seconds (the most aggressive and, frankly, the least forgiving).
Idempotency is on the receiver
Every webhook delivery may arrive more than once. The receiver must de-dupe on event ID or composite key. Double-charging a card because you got the same payment.succeeded twice is a reputational incident — and a refund call.
Include a delivery ID
Every event needs a stable unique ID (not a timestamp). GitHub uses X-GitHub-Delivery. Stripe uses the event id. Your webhook handler stores this ID and returns 200 without re-processing if it has seen it before.
Return 2xx fast, process later
Webhook handlers should return 200 within 5 seconds. Queue the work and process asynchronously. If you process inline and take 10 seconds, the sender times out and retries — now you have the same event being processed twice in parallel.
Expose a retry log
The top scorers publish a webhook attempts dashboard showing every attempt, status code, and latency. This is the single largest trust signal for agent operators evaluating whether your webhook surface is production-grade.
How AgentHermes Scores Your Webhook Surface
Four signals feed the webhook component of D8 Reliability. Each is binary: present and documented, or missing. Ship all four and you are in the top decile of our 500-business scan.
/webhooks or /events documentation page
We probe /docs/webhooks, /webhooks, /developers/webhooks, /api/webhooks, /events. A discoverable page at a predictable path is the entry point — without it, agents cannot even confirm you support webhooks.
HMAC signing with SHA-256
We scan your docs for "HMAC", "signature", "verify signature", and "signing secret". SHA-256 earns full credit. SHA-1 earns partial credit (Twilio is the main offender). No signing earns zero.
Retry logic described
Explicit retry behavior — attempts, backoff, timeout — documented on the webhooks page. We reward transparency even if the retry policy is aggressive (like GitHub). Silent retries are worse than documented limits.
Event catalog with typed payloads
A list of every event you emit, with example payloads. The top scorers link directly to TypeScript types or OpenAPI schemas. Resend, Stripe, and GitHub all ship published event catalogs that LLM code generators can ingest.
Each signal is roughly 1.5 points of D8. All four together move D8 from ~40 to ~80 on the sub-dimension scale, which translates to roughly 5-6 points on the overall Agent Readiness Score. For a business sitting at the Silver/Gold boundary, webhooks are often the single highest-leverage infrastructure ship.
Frequently Asked Questions
Why can AI agents not just poll an API every few seconds?
Polling forces every agent to re-fetch state on a fixed interval whether or not anything changed. For a hundred agents watching a single resource, that is a hundred redundant round-trips per poll window. At production scale the math breaks: you either pay for tokens and bandwidth that return no new information, or you lengthen the polling interval and miss events entirely. Webhooks invert the cost — the server broadcasts once, every subscriber hears it instantly, and agents only spend budget when something actually happened.
What is HMAC-SHA256 and why do agents refuse webhooks without it?
HMAC-SHA256 is a keyed hash that lets the receiver verify two things: the payload is exactly what the sender transmitted, and it was signed by someone holding the shared secret. Without HMAC, an attacker who learns your webhook URL can send fake events — fake payment confirmations, fake inventory updates, fake cancellations. Agents running on a user budget cannot afford to act on forged events, so any production agent framework will refuse unsigned or unverified webhooks by default.
How do the top scorers (Stripe, GitHub, Slack, Resend) sign their webhooks?
Stripe sends a Stripe-Signature header with a timestamp and v1=signature over timestamp.payload using the webhook signing secret. GitHub uses X-Hub-Signature-256: sha256=... over the raw body with your repository webhook secret. Slack sends X-Slack-Signature with a timestamp-prefixed HMAC. Resend follows the Stripe-compatible pattern with Resend-Signature. All four use SHA-256, all four include a timestamp to prevent replay attacks, and all four publish verification code in 5+ languages. That is why they cluster at the top of the D8 Reliability dimension.
What retry policy should an agent-ready webhook endpoint follow?
The industry convention is exponential backoff with jitter across 24-72 hours of retries, capped at 5-24 attempts. Stripe retries for up to 3 days. GitHub retries 3 times over 30 seconds then gives up. Resend retries 5 times over 24 hours. The agent side of the contract is that your webhook handler must be idempotent — the same event can arrive more than once, and processing it twice must not double-charge, double-ship, or double-book.
How does AgentHermes score webhooks in the D8 Reliability dimension?
AgentHermes scans for four signals: a documented /webhooks or /events page at a predictable path, visible HMAC signing instructions (SHA-256 preferred), an event catalog listing every emitted event with a typed payload, and retry behavior described in the docs. Each signal contributes to D8 Reliability (13% weight). Businesses with all four signals cluster in Silver and Gold tiers. Businesses with zero — the majority of our 500-business scan — lose ~6 points off D8 alone.
See how your webhook surface scores
AgentHermes scans for HMAC signing, retry logic, event catalogs, and docs discoverability — and tells you exactly what is missing. Free, 60 seconds, no signup.