Skip to content
Scalpels home

Scalpels is officially launching on October 31, 2026. Special early adopter pricing is available now.

Bobbin

Any stack MIT licensed Experimental

A stable, hard-to-guess URL for every integration, running in your own Laravel Cloud account. Bobbin keeps the request exactly as it arrived — method, query string, headers, body and the moment it landed — so you can read what a provider really sent instead of what its docs say it sends, and replay it at the thing that was meant to receive it.

Deploy Bobbin with Unlimited Or run it yourself, free

Work in progress. Available to teams with Unlimited.

Replaces
A hosted webhook gateway
Runs on
Your Laravel Cloud account
Needs
Compute · Database · Queue · Scheduler
Bobbin, catching and replaying a webhook Placeholder — the launch recording replaces this

What it captures

Whole requests, kept as they arrived, on infrastructure you own

  • A URL per integration

    Each endpoint gets its own public capture URL with a hard-to-guess identifier, so one provider misbehaving never means rotating the others.

  • The whole request

    Method, query string, headers, body and time of receipt are stored together, which is the version of events an argument with a provider actually needs.

  • Replay on demand

    Send any stored capture to the endpoint destination you configured, with automatic retries and a delivery history you can read.

  • Retention you set

    One to three hundred and sixty-five days per endpoint, thirty by default, swept daily by a scheduled prune rather than left to grow.

  • Redaction before storage

    Name the headers and body fields you never want kept, and Bobbin redacts them on the way in rather than after the fact.

  • No tunnel to your laptop

    A deployed Bobbin is the public endpoint, so developing against a real provider never means exposing your own machine to the internet.

  • What arrived, not what was documented

    Most webhook debugging is an argument about whose side dropped the field. Bobbin keeps the bytes: the headers as sent, the body unparsed, the query string intact, timestamped. You are reading evidence rather than reconstructing it from a log line somebody remembered to write.

  • At-least-once, and honest about it

    2xx

    A replay counts as delivered only when the receiver answers 2xx, and a failure is retried four times with a visible status. A destination may well process a request before Bobbin records the success, so receivers must tolerate duplicates — that is stated rather than buried.

Bobbin vs. the incumbents

We rebuilt one row of their feature matrix

Hookdeck, Svix and webhook.site are good products and Bobbin is not trying to replace them. It does one slice of what they do — hold on to the requests other people send you, and put them back where they belong — on infrastructure you own, and deliberately does not do the rest. The question is not which product is better. It is which slice you are actually using.

Bobbin feature comparison
Feature Bobbin Self-hosted, MIT Hookdeck Hosted Svix Hosted, or enterprise self-host webhook.site Hosted, or self-host
Captures on infrastructure you own the row we rebuilt Does this well:Your Cloud account Not built:Hosted only Works, but on their terms:Enterprise only Partly, or with a caveat:Self-host available
Replay a stored request the row we rebuilt Does this well:One click, with history Does this well:Included Does this well:Included Partly, or with a caveat:Manual resend
Redact secrets before storing Does this well:Per endpoint Partly, or with a caveat:Transformations Partly, or with a caveat:Transformations Not built:Stored as sent
Fan out to several destinations we did not build this Not built:One destination Does this well:Core feature Does this well:Core feature Not built:Inspection only
Verify vendor signatures we did not build this Not built:Not built Does this well:Per source Does this well:Per endpoint Not built:Not built
Transform or filter payloads we did not build this Not built:Stored as sent Does this well:Inline scripts Does this well:Transformations Partly, or with a caveat:Custom actions
Sending webhooks to your customers we did not build this Not built:Inbound only Does this well:Included Does this well:Their core strength Not built:Inbound only
Where your captured payloads live Does this well:Your own database Works, but on their terms:Their cluster Works, but on their terms:Their cluster Works, but on their terms:Their cluster
Cost of catching more events Does this well:Disk Works, but on their terms:Per event Works, but on their terms:Per message Works, but on their terms:Per plan
Who is on call for the tool itself Partly, or with a caveat:You are Does this well:They are Does this well:They are Does this well:They are
  • Does this well
  • Partly, or with a caveat
  • Not built
  • Works, but on their terms

The honest test

Ask what the webhook gateway is actually for on your team. If these are all true, you are paying per event for a platform to use one row of it.

  • The question you ask it is "what did they actually send me?"
  • Each integration has exactly one place its events need to end up.
  • You would rather own the captured payloads than rent them.

Then you lose very little by moving. Bobbin is experimental today, so start with one noisy integration; the captures stay in your own database either way.

Keep paying them if

These are the parts we chose not to build, and we are not going to pretend otherwise.

  • You need one event fanned out to several destinations with independent retries.
  • You rely on vendor-specific signature verification at the gateway.
  • You transform, filter or enrich payloads before they reach your app.
  • You are SENDING webhooks to your own customers and need delivery infrastructure for that.

Small, sharp tools are a deliberate scope, not an unfinished roadmap. Bobbin will not grow into an event platform.

Be honest about it

You don't need us to run Bobbin

The repository is public and MIT licensed. These are the steps, and you are welcome to spend the afternoon doing them by hand.

  1. 1

    Fork the Bobbin repository into your own GitHub organisation.

  2. 2

    Deploy the fork to Laravel Cloud with its own compute, Postgres, a managed queue and the scheduler enabled, then create the first Owner.

  3. 3

    Create an endpoint, give its capture URL to the provider, and set the one destination each replay should go to.

Or buy Unlimited once. Scalpels forks it, provisions exactly what it needs on your Laravel Cloud account, and deploys it. The app and the infrastructure are yours either way — the only question is who spends the afternoon.

Deploy Bobbin with Unlimited

Bobbin pairs with the rest of the suite

Bobbin is the inbound half of the same job Sink does for mail: something outside your app sends you a thing, and you want to see it before you trust it. Muster watches the scheduled work on the other side of that boundary, and Hone tells you what the replay did to your application.

Sink Muster Hone