Whichever you choose handles your test. Same buttons, same URLs — just routed to a different language.
I built the same backend
twice — once in Go,
once in Node.
Both speak the same API, store the same data, and stream the same events. Different engines, identical behavior. Try poking at either one below — no signup, nothing to install.
- What's a webhook?
- A URL that other apps can ping. Stripe, GitHub and Slack all use them: when something happens on their side, they make an HTTP call to a URL you've given them.
- What does this site do?
- Hands you a temporary URL, then shows — live — exactly what arrives at it. Useful when you're building or debugging integrations.
- Why two backends?
- To prove a point. The same product is wired to two servers I wrote independently — one in Go, one in Node. Same spec, same behavior, two different stacks.
Four steps. Try it.
Click the button. You'll get a unique URL that lives for 24 hours. Anything sent to it shows up below.
Click the button to fire a sample webhook at your URL. Or copy the URL and POST to it from your terminal — anything that lands gets captured.
Each request that hits your URL appears here the instant the backend receives it. We hold an open connection so nothing has to be polled.
For the curious — how it actually works.
A few of the engineering choices that make this fun rather than rote.
Go fans out the live stream with goroutines and a per-bin RWMutex.
Node uses its event loop with a callback set per bin. Same observable behavior, very
different machinery.
Both stacks embed SQLite (with WAL) — no external database. Data lives in a 1 GB Railway volume. A periodic sweeper retires bins after 24 hours.
Both ship a byte-identical openapi.yaml.
The toggle above is the proof: same routes, same shapes, same edges.