Webhook for AI Agents

An AI agent acting on webhook data has a stricter reliability requirement than a human-driven service: the agent will confidently do something with whatever it receives, and if a payload is malformed or a delivery is silently dropped, the agent takes the wrong action instead of noticing nothing happened. The webhook layer has to be trustworthy before the agent behind it can be.

The pattern that works is a gateway between the vendor and the agent — one that transforms and validates every event, keeps evidence of what happened, and lets you re-drive events when the agent (or its prompt) needs a fix.

The reliability contract an agent needs

An agent consuming webhook events needs four properties from the layer in front of it:

Payload sanity — every event the agent sees matches a shape the agent can reason about. Raw vendor payloads drift, get new optional fields, wrap objects in envelopes. A validated schema at the gateway means the agent's prompt doesn't have to enumerate every historical variant.
Delivery you can trust — retries with backoff, dead-letter for events the agent can't accept yet, and per-attempt logs. "The webhook fired but the agent didn't act" is either a delivery failure the gateway logged, or an agent failure worth investigating — never a mystery.
Replay — when you improve the agent's prompt, upgrade the model, or fix a bug in the tool the agent calls, you need to re-run the affected events, not ask the vendor to re-send.
Visible failures — an agent that silently no-ops on a class of events is a worse bug than one that crashes loudly. The gateway's delivery log is where "did this event actually get acted on?" is answered.

Slashbin exists to provide those four properties. See Webhook Debugging for the four failure modes and their fingerprints — the same failure taxonomy applies whether the consumer is a service or an agent.

Pattern: vendor → Slashbin → agent

Vendor (Stripe, Shopify, GitHub, ...) 
   │
   ▼
Slashbin  ──► signature check ──► transform to Golden Model ──► validate
   │                                                                │
   │                                                                ▼
   │                                            Fan-out to destinations
   │                                              ├── Agent runtime (HTTP)
   │                                              ├── Queue the agent drains
   │                                              └── Data warehouse
   │
   ▼
Delivery log, DLQ, Replay

The agent consumes a canonical event, not raw vendor JSON. If the agent runtime is temporarily down, retries hold the event; if the agent's response is a 5xx, the DLQ catches it. If the agent's prompt improves next week, Replay re-drives the last day of events through it.

Worked example: Stripe events driving a support agent

The job: a support agent reads charge.dispute.created events from Stripe and drafts a response to the customer.

Without a gateway: the agent's tool is a raw webhook handler. Stripe wraps the dispute in data.object.*; the amount is an integer in the smallest currency unit; the reason codes are Stripe-specific strings. The prompt has to explain the envelope shape, the currency casting rule, and every reason code. When Stripe adds a field or changes the shape, the agent's behavior changes without a code change.

With Slashbin in front:

Stripe posts to a Slashbin source URL.
The transform reshapes the payload into a canonical Dispute shape — {id, customerId, amount: {value, currency}, reason, evidenceDueBy} — validated against the Golden Model. Currency uses safe decimal casting, so amount.value is always a decimal string, never a float that lost precision.
Slashbin delivers the canonical Dispute to the agent's HTTP endpoint (or a queue the agent drains).
The agent's prompt describes only the canonical shape. It doesn't know Stripe wraps events in data.object.*, doesn't need to know the smallest-currency-unit rule, and doesn't need per-vendor branches.
When the agent gets rate-limited by the LLM provider, Slashbin retries. When Anthropic ships a better model and the prompt is updated, Replay re-runs yesterday's disputes through the new prompt — the raw payload is still there.

The same pattern works with a Shopify source feeding an inventory agent, or a GitHub source feeding a triage agent. The agent's tool contract is the Golden Model; the vendor contract is Slashbin's problem.

Operating the pipeline from an agent

An agent can also operate Slashbin, not just consume events from it — inspect deliveries, replay failures, publish a corrected transform. Today that runs through the console REST API at https://console.slashbin.io/api/…, authenticated with an org-scoped bearer key (create one in the console under Account → API Keys; the plaintext value is shown once, at creation). A shell binary (slashbin-cli) ships today and wraps that same REST surface — see slashbin-cli. A native MCP server is on the roadmap. See Webhook MCP server for the tool-facing surface and Claude webhook integration for a worked example.

What Slashbin does not solve

The gateway does not make the agent's decisions correct — it makes the events the agent decides on trustworthy. If the agent's prompt is wrong or the model hallucinates, that's still yours to fix. But the fix is cheap once you can replay a real event through the corrected agent instead of asking a vendor to re-fire.