Compare
Webhook tooling spans several categories that overlap at the edges and differ at the core. Competitors are not the enemy here; uncertainty about what actually happened to an event is. This page maps each category to the job it was designed to perform, so you can tell whether your problem is one of inspection, connectivity, development, action, delivery, or evidence.
Choose another product when its primary job matches yours. Choose Switchyard when you need a durable, self-hosted record from webhook receipt through verified recovery.
Category map
Request bins show what arrived. Tunnels show what reached localhost. Gateways move events. Workflow builders act on events. Switchyard preserves the complete operational record.
| Category | Primary job | Where its story often ends |
|---|---|---|
| Request bin | Receive and inspect a request | Arrival |
| Tunnel | Reach a local process | Local connectivity |
| API workspace | Build and test APIs | Request development |
| Workflow builder | Transform and act on events | Automated action |
| Webhook delivery infrastructure | Reliably send or receive at scale | Infrastructure delivery |
| Switchyard | Preserve and operate the full incident record | Verified recovery and evidence |
Category examples, stated neutrally: Webhook.site is a request bin. ngrok is a tunnel. Postman is an API workspace. Pipedream is a workflow builder. Hookdeck, Convoy, and Svix are webhook delivery infrastructure. Each performs its primary job well; the question is whether that job is the one you have.
Overlap
Switchyard shares surface area with three categories. The overlap is real, and it is not the point.
Switchyard receives webhook requests and shows you exactly what arrived: the raw request, headers, payload, and provider verification status. If you only need to see a request once, a request bin does that job. Switchyard keeps going: the request is persisted before acceptance, so the captured record survives the inspection session.
Private-network delivery uses the authenticated relay, so events can reach a local process during development and reproduction. A tunnel solves connectivity. Switchyard uses connectivity as one step in a longer record: what was routed, which attempts ran, and what each attempt returned.
Switchyard routes and delivers events to destinations with retries and recorded responses, which overlaps with what delivery infrastructure does. Delivery is at least once; duplicates remain possible. The difference is not the forwarding. It is that every routing decision, attempt, and recovery action is preserved as evidence you can operate on later.
The record
Switchyard's primary job is the record from receipt through verified recovery. Four properties make that record something you can act on and share.
The record shows which routing configuration was active when the event arrived — the matched rule and the selected and skipped destinations — not which configuration exists now. Investigations compare what the system decided against what it would decide today.
Every delivery attempt is preserved with its response status, duration, and error class, from the first try through retries and exhaustion. Terminal states are succeeded or exhausted, and nothing in between is lost.
After the receiver is repaired, the preserved event itself can be replayed — the same bytes, the same event — so recovery is verified against what actually arrived rather than a hand-reconstructed approximation.
Receipts are sanitized: masked fields carry a masked marker with null values, and raw bodies, header and signature values, tokens, and secret material are structurally absent from evidence exports. The artifact is safe to share with support, a provider, or a customer.
Scope
These are scope decisions, not roadmap items. If your primary job is on this list, another category fits better.
Switchyard does not claim exactly-once delivery. Delivery is at least once; duplicates remain possible.
Switchyard is not a Kafka replacement.
Switchyard is not a general message broker.
Switchyard is not an ETL platform.
Switchyard is not a workflow automation platform.
Switchyard is not a payment-grade delivery service.
Switchyard is not a full API gateway.
Switchyard is not an arbitrary code-execution environment.
Fit check
A confident recommendation includes the cases where the answer is no.
Coexistence
Adoption does not require replacing anything. Switchyard takes over the record; the other tools keep their jobs.
Leave your existing tunnel in place for general local development. Point provider webhooks at a Switchyard endpoint so the record starts at receipt; the relay handles private-network delivery when you need a local reproduction.
Workflow builders transform and act on events, and that job stays with them. Use Switchyard receipts as the evidence layer underneath: when an automated action is questioned, the sanitized receipt shows what arrived and what was delivered before the action ran.
Start with the provider whose webhooks cause the most support arguments. Point that provider at Switchyard, keep everything else unchanged, and let the next incident show whether the preserved record ends the investigation faster than the reconstructed one did.
Evaluation checklist
These questions separate a preserved record from a reconstructed story. Ask them of Switchyard, and ask them of everything else you evaluate.
Run a failed webhook through Switchyard and inspect the preserved evidence yourself.
The demo uses sample data. The quickstart runs a local instance on your own infrastructure.