Claude Webhook Integration

Two useful things happen when you connect Claude to a webhook stream through Slashbin: Claude can consume the events (read cleanly-shaped payloads and take action), and Claude can operate the pipeline (inspect deliveries, replay failures, publish a corrected transform). Both work today with the same primitives — a gateway that stores per-stage evidence, and an HTTP-native REST API Claude can call with a bearer key.

This page shows the concrete setup for each.

What ships today

A published contract — https://console.slashbin.io/api/openapi.json. Fetch this first. It is an OpenAPI document, served unauthenticated, that declares every console operation it registers — path, verb, parameters, request body and response shape. (Its own description names what sits outside it: the Stripe webhook receiver and the browser session and OAuth endpoints.) Read it to learn every operation — this page does not restate it, because a restatement is a copy that goes stale.
Console REST API — every operation a human can take in the console (list data streams, fetch delivery logs, replay events, test and publish transforms) has an HTTP endpoint, declared in that contract.
API-key auth — an org-scoped bearer key, generated in the console. Same auth for Claude Code's Bash/curl, for Claude API tool-use, and for anything else that speaks HTTP.

A native Slashbin MCP server is on the roadmap — see Webhook MCP server. The shell binary (slashbin-cli) already ships and wraps this same REST API — install it from slashbin-cli, then run slashbin --help for its command groups. Many of them are generated from the same contract, so --help and openapi.json are the two authoritative lists; neither is maintained by hand on this page.

How to get an API key

Sign in to console.slashbin.io and open Account → API Keys.
Click Create key, give it a name, and copy the plaintext value immediately — it is shown once, at creation. After that, only the prefix and last four characters are visible.
Export it in the environment Claude runs in:
```
export SLASHBIN_API_KEY=slashbin_sk_...
```
Send it as Authorization: Bearer $SLASHBIN_API_KEY on every console API call. The contract declares the same scheme under bearerAuth.

Keys are org-scoped and revocable — delete a key from the same Account → API Keys screen to revoke it.

Pattern A: Claude Code operates the pipeline

Setup — one time: put your API key in Claude Code's environment (see above), then confirm it works:

curl -s -H "Authorization: Bearer $SLASHBIN_API_KEY" \
  https://console.slashbin.io/api/data-streams

Then, in Claude Code: point Claude at the contract once — "read https://console.slashbin.io/api/openapi.json before you call anything" — and it has the full operation list. After that, ask in plain English and Claude drives the REST API through the Bash tool (curl + jq).

You: The Stripe integration in the "billing" data stream has been dropping disputes
     since this morning. Find the failing stage and replay the last hour of events.

Claude (runs):
  curl -s -H "Authorization: Bearer $SLASHBIN_API_KEY" \
    https://console.slashbin.io/api/pipeline/dlq-groups | jq
  # groups the dead letters into the distinct errors behind them —
  # the transform failure on charge.dispute.created, with its topic, count and sample ids

A group names the error, not the event. To trace one specific event, Claude reads that group's dead letters from GET /api/dlq — each row carries the rawWebhookId of the webhook behind it — and passes that id to GET /api/pipeline/webhook/{webhookId}/lifecycle, which returns the stage/status pair naming where it stopped.

From there the rest of the loop is five more operations — read the data stream's model for the failing topic, preview a corrected transform, save it back to the model, publish it, start a replay of the failed window. Claude finds their exact paths, verbs and request bodies in the contract rather than on this page, which is why this page prints two examples instead of seven.

Every endpoint returns JSON with a non-2xx status on failure, so Claude can tell success from failure without parsing free text. The whole loop — inspect, diagnose, fix, publish, replay — runs from the same terminal, with a human reviewing the plan before publish. See Webhook Debugging for the diagnosis walk in more detail.

Pattern B: Claude API tool-use against the REST API

For agents that don't have shell access — a Claude API application, a Claude in a browser, an assistant embedded in an internal tool — the console REST API is the tool surface. Define one generic tool, hand Claude the contract, and it can call any operation the contract declares.

{
  "name": "slashbin_call",
  "description": "Call a Slashbin console API operation. The full operation list is at https://console.slashbin.io/api/openapi.json - fetch it and use the paths and verbs it declares.",
  "input_schema": {
    "type": "object",
    "properties": {
      "method": { "type": "string", "enum": ["GET", "POST", "PUT", "PATCH", "DELETE"] },
      "path":   { "type": "string", "description": "A path the contract declares, with any query string" },
      "body":   { "type": "object", "description": "JSON request body, where the contract declares one" }
    },
    "required": ["method", "path"]
  }
}

The tool handler forwards the call to https://console.slashbin.io + the path, with the Authorization: Bearer <API_KEY> header, and returns the JSON response verbatim. Claude then reasons over the JSON and decides the next call. Two things make this work without a hand-written endpoint list: the contract is fetchable without a key, so the agent can read it during setup, and its paths are the literal strings the handler needs.

For the MCP-native version of this (tool discovery over the Model Context Protocol) see Webhook MCP server.

Pattern C: Claude as a webhook consumer

Slashbin can also deliver events to a Claude-backed service. The setup is a standard destination:

Point a Slashbin source at the vendor (Stripe, Shopify, GitHub, ...).
Write the transform so the destination shape is the exact input Claude expects — a canonical event via the Golden Model, not raw vendor JSON.
Add a destination that POSTs to your Claude-backed endpoint. Your endpoint hands the payload to Claude (via the Anthropic API) and returns 200 when the model has acted.

The reliability guarantees are Slashbin's: retries, DLQ for events Claude declined, Replay for events the improved prompt should re-process. Your endpoint is thin — it hands well-shaped input to Claude and reports the outcome. See Webhook for AI agents for the reliability argument that motivates this shape.

Why route Claude through a gateway

Claude will confidently act on whatever payload you hand it. That's a feature when the input is trustworthy and a liability when it isn't. Putting Slashbin between the vendor and Claude means:

Claude sees one canonical shape — the Golden Model — regardless of source. The prompt doesn't have to enumerate every vendor's envelope quirks.
Delivery attempts are logged — you can prove Claude was called for a specific event, and see the response Claude's endpoint returned.
Replay is a first-class operation — when the prompt improves or the model is upgraded, re-run yesterday's events instead of asking the vendor.
Fan-out lets Claude be one of several consumers — the same event can also land in a warehouse or a queue without Claude being the router.