Public Beta: Direct engineering support available. Join Discord →
For
For Claude

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

  • Console REST API at https://console.slashbin.io/api/… — every operation a human can take in the console (list projects, fetch delivery logs, replay events, test and publish transforms) has an HTTP endpoint.
  • 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 commands and the command groups are documented once, on slashbin-cli.

How to get an API key

  1. Sign in to console.slashbin.io and open Account → API Keys.
  2. 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.
  3. Export it in the environment Claude runs in:
    export SLASHBIN_API_KEY=slashbin_sk_...
  4. Use it as Authorization: Bearer $SLASHBIN_API_KEY against https://console.slashbin.io/api/….

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/projects

Then, in Claude Code: ask in plain English and Claude drives the REST API through the Bash tool (curl + jq).

You: The Stripe integration in the "billing" project 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/delivery-logs?projectId=$BILLING&limit=20" | jq
  # inspects the JSON, identifies transform failures on charge.dispute.created
  curl -s -H "Authorization: Bearer $SLASHBIN_API_KEY" \
    "https://console.slashbin.io/api/projects/$BILLING/mappings/charge.dispute.created" | jq
  # reviews the current transform, spots the bug, drafts a fix
  curl -s -X POST -H "Authorization: Bearer $SLASHBIN_API_KEY" \
    -H "Content-Type: application/json" \
    --data @preview-request.json \
    "https://console.slashbin.io/api/transforms/preview" | jq
  # confirms the fix, then publishes the corrected transform
  curl -s -X PUT -H "Authorization: Bearer $SLASHBIN_API_KEY" \
    -H "Content-Type: application/json" \
    --data @corrected-transform.json \
    "https://console.slashbin.io/api/projects/$BILLING/mappings/charge.dispute.created"
  curl -s -X PATCH -H "Authorization: Bearer $SLASHBIN_API_KEY" \
    -H "Content-Type: application/json" \
    --data '{"published":true}' \
    "https://console.slashbin.io/api/projects/$BILLING/mappings/charge.dispute.created/publish"
  # re-drives the failed window through the corrected transform
  curl -s -X POST -H "Authorization: Bearer $SLASHBIN_API_KEY" \
    -H "Content-Type: application/json" \
    --data "{\"filters\":{\"delivery_status\":[\"failed\"],\"occurred_at_from\":\"$FROM\",\"occurred_at_to\":\"$TO\"}}" \
    "https://console.slashbin.io/api/projects/$BILLING/replays"

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 the tool once, and Claude can call any endpoint on the API.

{
  "name": "slashbin_call",
  "description": "Call a Slashbin console API endpoint. Use for listing projects, fetching delivery logs, replaying webhooks, and managing transforms.",
  "input_schema": {
    "type": "object",
    "properties": {
      "method": { "type": "string", "enum": ["GET", "POST", "PUT", "DELETE"] },
      "path":   { "type": "string", "description": "e.g. /api/pipeline/delivery-logs?projectId={id}&limit=10" },
      "body":   { "type": "object", "description": "JSON body for POST/PUT" }
    },
    "required": ["method", "path"]
  }
}

The tool handler forwards the call to https://console.slashbin.io<path> with the Authorization: Bearer <API_KEY> header and returns the JSON response verbatim. path must include the /api prefix (e.g. /api/projects, /api/pipeline/delivery-logs?...) — everything under the console API is served there. Claude then reasons over the JSON and decides the next call.

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:

  1. Point a Slashbin source at the vendor (Stripe, Shopify, GitHub, ...).
  2. Write the transform so the destination shape is the exact input Claude expects — a canonical event via the Golden Model, not raw vendor JSON.
  3. 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.

Related reading

  • Webhook MCP server — the tool-facing surface an agent uses to operate Slashbin, today and on the roadmap.
  • Webhook for AI agents — the reliability argument in full.
  • Webhook ETL — the category Claude is consuming.
  • Replay — re-drive stored events through a corrected pipeline or an improved prompt.