Slashbin vs Hookdeck

They're not the same shape of product. Hookdeck is an event gateway: it receives inbound webhooks, routes them, retries them, and gives you the infrastructure tooling — CLI, Terraform, CI hooks — to run that as managed plumbing. Slashbin is a webhook ETL layer that happens to deliver: the point is reshaping every inbound event into a schema you own, validating it at the boundary, and only then sending it on.

If your problem is "these webhooks need to arrive reliably and I want to manage that as infrastructure," Hookdeck is built for that and is very good at it. If your problem is "every vendor sends a different shape and my downstream code is drowning in it," that's the part Slashbin is built for.

What Hookdeck is better at

• A real free tier, no credit card. Hookdeck's Developer plan is $0/month with 10,000 events, unlimited connections, and unlimited transformations — and their FAQ states plainly that you can sign up without a credit card. Slashbin requires a card at signup for its 14-day trial. If you want to try before you pay anything, that's a genuine difference.
• A CLI that tunnels to localhost. hookdeck listen <port> forwards live webhook events to a local web server, which makes the dev loop against a real sender trivial. Slashbin does ship a CLI — slashbin-cli on npm, with login, projects, sources, destinations, transform, openapi, logs, and replay — but it has no tunnel, listen, or forward command. For local webhook development against live traffic, Hookdeck's CLI does something ours does not.
• A Terraform provider. hookdeck/hookdeck is published on the Terraform Registry, covering sources, destinations, connections, transformations, and rules. You can define your whole gateway as code and register webhooks from CI. Slashbin has no Terraform provider — configuration is done in the Console or via the CLI.
• A financially-backed uptime SLA. Hookdeck publishes a 99.999% uptime SLA on their Growth tier. Slashbin does not publish an uptime SLA today. If you need a contractual availability number, that's a real gap on our side.
• Longer retry ceilings on paper. Hookdeck allows up to 50 automatic retries per event, with linear or exponential backoff, plus unlimited manual retries and Retry-After scheduling up to 7 days out.

What Slashbin is better at

• Transformation depth against a schema you own. Slashbin's transform is not a passthrough hook — it produces a Golden Model, a canonical source-shaped schema you define once. Fields are mapped visually, values are cast safely (decimal currency, integer coercion), and the output is validated before anything downstream sees it. When the vendor renames a field, validation fails at the boundary instead of corrupting your warehouse. Hookdeck's transformations are JavaScript that reshapes a payload; there is no canonical model to enforce it against.
• Golden Model inheritance across projects. Define a master Order shape once and have every project inherit it, so a Shopify order and a Stripe charge land in the same vocabulary. That's an ETL feature, not a routing feature.
• Data-type-aware delivery semantics. Slashbin asks what kind of data a source produces — Transactional (stateful business events, where a duplicate order is a real problem) or Timeseries (where chronological order is what matters) — and applies deduplication and ordering accordingly, regardless of retries. Retry counts are the easy part; knowing when a redelivery is safe is the hard part.
• Per-destination fault isolation. One inbound event fans out to every consumer that needs it, and a destination that starts failing is circuit-broken on its own without back-pressuring the others. See Fan-out.
• Replay from stored raw history. The original payload is kept byte-for-byte. When you fix a transform, Replay re-runs stored events through the current version of your pipeline — you heal past mistakes instead of asking the vendor to re-send.
• Generated SDKs and OpenAPI from your model. Because the Golden Model is a real schema, slashbin-cli openapi exports it and you generate type-safe clients from it.

The short version: Hookdeck makes the delivery of webhooks operable. Slashbin makes the contents of webhooks yours.

When to use which

• You want to try a gateway today without a credit card. → Hookdeck. Ours needs a card for the trial.
• You need to develop against live webhooks on your laptop. → Hookdeck's hookdeck listen. Slashbin has no tunnel command.
• Your gateway config must live in Terraform and be applied from CI. → Hookdeck. We have no provider.
• You need a contractual uptime SLA. → Hookdeck's Growth tier. We don't publish one.
• Every vendor sends a different shape and your downstream code is full of adapter glue. → Slashbin. One Golden Model, validated at the boundary, is the whole point.
• You need schema drift to fail loudly at ingest, not silently downstream. → Slashbin. Validation failures land in the DLQ with the error attached and the raw payload retained.
• Duplicate deliveries would create duplicate orders. → Slashbin. Declaring a source Transactional makes dedupe the gateway's job rather than yours.
• You want to re-drive three weeks of history through a transform you just fixed. → Slashbin. Replay against stored raw payloads is a first-class operation.

Nothing here is exclusive — plenty of teams would be well served by Hookdeck's free tier while they're still figuring out whether the webhooks even matter.

Feature comparison

Verified against the current hookdeck.com pricing page, Hookdeck's public docs (CLI, transformations, retries), and the hookdeck/hookdeck Terraform Registry listing (2026-07-30). Slashbin rows verified against the live product and slashbin-cli v0.6.0 on the same date.

"Not the product model" means Hookdeck isn't trying to do that specific job — it does not carry a canonical schema registry to validate against or generate from. Hookdeck is a delivery gateway with a scripting hook; it is not an ETL tool with a schema registry. That's a different product shape, not a defect. Where Hookdeck solves a problem by a different mechanism, the table names that mechanism rather than marking it absent.

Related reading

• All comparisons — every tool Slashbin is compared against, with a one-line note on who each page is for.
• Webhook ETL — the category Slashbin fits in, and why point-to-point handlers stop scaling.
• Golden Model — the canonical schema every inbound event is validated against.
• Fan-out — one inbound event to many destinations, with per-destination isolation.
• Replay — re-drive a stored event through the current transform + delivery pipeline.
• Transform Stripe Webhooks — worked example of building a Golden Model from a real vendor payload.