webhook.site is a throwaway URL that shows you the HTTP request a service sends you

A random URL per test and six jobs people point it at

The mechanism is small enough to state in one line: you get a unique, random URL, and every HTTP request sent to it shows up instantly. Everything else is tooling around that idea. You can transform, validate and process what arrives, either through a graphical editor called Custom Actions or through WebhookScript, described as a simple scripting language for the same three jobs.

The stated uses cover more than debugging a provider. Receiving webhooks without standing up an internet-facing web server. Sending webhooks to a server that sits behind a firewall or on a private subnet, since the traffic goes outward to the public URL rather than inward to you. Converting webhooks into other formats and re-sending them to systems that do not speak the original. Connecting APIs that are not compatible with each other. Building contact forms that send email. And standing up an API without infrastructure.

That last pair is where the tool stretches past its name. A contact form that emails is a production feature, not a test fixture. The repository also carries a Paw client file, `webhook-paw.paw`, which is the kind of artifact a project keeps when it expects people to call its endpoints from an API client rather than only from a shell.

Custom Actions live in the cloud version, not in the MIT one

There are two products under one name, and the split matters before you clone anything. The version on the repository is described as completely open source and MIT licensed, and it is the one you self-host. The cloud version at webhook.site has more features, and some of them require a paid subscription.

The named gap is Custom Actions. The open-source version is called great for testing webhooks, and the reason given for that qualification is that it does not include features like Custom Actions. The README does not say whether WebhookScript is included in the open-source version. Anyone building a transform that has to be maintained by a colleague rather than a programmer should check that assumption before committing.

A smaller discrepancy is worth a line of its own. The repository licence metadata does not resolve to a recognised licence identifier, while the README text calls the open-source version MIT. The `LICENSE` file is in the tree, so the file exists, but the machine-readable field does not match what the documentation claims, and that mismatch is what a package scanner reads.

Three containers: the app, redis, and a websocket relay

Self-hosting is a Docker Compose file, and it defines three services rather than one. The `webhook` service runs the application, `redis` runs on the alpine image, and `laravel-echo-server` is the relay that pushes new requests to a browser as they arrive. The application service depends on redis, and the relay depends on redis as well.

The application service publishes port 8084 on the host, points its own URL at that port, and runs a background queue worker as its command rather than serving from the web container alone. Bring the three services up with the shipped file:

docker compose up -d

The environment that stack starts with is this:

ports:
  - "8084:80"
environment:
  - APP_ENV=dev
  - APP_DEBUG=true
  - APP_URL=http://localhost:8084
  - APP_LOG=errorlog
  - DB_CONNECTION=sqlite
  - REDIS_HOST=redis
  - BROADCAST_DRIVER=redis
  - CACHE_DRIVER=redis
  - QUEUE_DRIVER=redis
  - ECHO_HOST_MODE=path

Three details in there shape everything. Storage is a SQLite file, so nothing survives outside the volume you mount. Cache, queue and broadcast all go through redis, which is why the second service is not optional. And `ECHO_HOST_MODE=path` is set, while the Dockerfile copies an nginx.conf it describes as containing the laravel echo server proxy configuration.

Debug mode and wildcard CORS ship enabled, so keep it off real networks

This is the part to read twice before running the compose file anywhere but your own machine. `APP_ENV=dev` and `APP_DEBUG=true` are the defaults in the shipped configuration, so a fresh start is a development build with the debug layer exposed on port 8084. That is fine on a laptop and wrong on a shared host.

The relay is configured just as loosely. Its environment sets `ECHO_ALLOW_CORS=true` with the origin, the methods and the headers all set to a wildcard, and the relay binds to `0.0.0.0` on port 6001 rather than to localhost. The compose file publishes only 8084, so the relay port is not mapped outward by default and the wildcard matters less in that exact configuration, but the setting is there if you expose it.

The security posture of the app itself is easier to reason about than it looks. Its entire job is to accept anonymous POSTs from strangers and display them, which is what you want while integrating and is not what you want as a permanent inbound endpoint for a production system. Nothing in the README describes retention limits, per-token authentication on the public URLs, or rate limiting, so if you point something real at it you are choosing to trust a URL that anyone who has seen it can also write to.

Live updates arrive from Pusher or from your own Echo server

Instant display is not free, and the example environment file shows both routes. The first is Pusher: uncomment `BROADCAST_DRIVER=pusher` along with the key, secret, app id and cluster values, and the browser connects to Pusher's hosted service. The second is self-hosted: `BROADCAST_DRIVER=redis` with Laravel Echo over Socket.io and the Echo server, which is what the compose file ships.

Two comments in the example file carry real guidance. Using redis as the cache driver instead of files is called recommended, and switching the log to syslog is recommended when you are not in development. Both are one-line changes with a performance or operability reason behind them rather than stylistic preference.

The environment example also leaves `APP_KEY` blank and sets `APP_URL=http://localhost`, which are the two values you must change before the app behaves. An empty application key is the one that bites, because Laravel uses it for encryption and session signing, and the example file gives you no default to copy. A unix socket option for redis is present but commented out, with a note that it is more performant than a TCP host, which matters if you end up running this somewhere with real latency requirements.

A Node 11 build stage and an fpm-nginx 7.4 base image pin your toolchain

The Dockerfile is two stages and both base images are fixed by the repository rather than chosen by you:

FROM node:11 AS npm
FROM bkuhl/fpm-nginx:7.4

The first stage installs node dependencies and runs the asset build: it copies `package.json` and `package-lock.json`, runs `npm install`, copies `resources` and `gulpfile.js`, then runs `npm run gulp`. Only the compiled `public/css` and `public/js` are carried forward, so the node toolchain is a build-time dependency and never ships in the final image.

The front end it builds is dated. `package.json` is marked private and requires Angular ^1.4.5 and gulp ^3.8.8, plus laravel-elixir, highlight.js, jquery, moment and socket.io-client. The scripts are four: a production gulp run, a plain gulp run, a watch mode, and an `echo` script that starts the Echo server directly. There is no test script in the JavaScript manifest, and phpunit.xml plus a `tests/` directory are where PHP tests would live.

The second stage installs PHP dependencies with `--no-dev` and `--no-scripts`, clears the composer cache, dumps an optimized autoloader with `--no-dev`, touches an empty SQLite database file, runs `php artisan optimize`, and runs `php artisan migrate`. Migrations run at image build time rather than at container start, so a schema change lands on rebuild, not on deploy.

Helm, PHPUnit, a Paw file, and a release line that stopped in 2023

The tree has more deployment surface than the README mentions, which is the usual gap between a documentation page and a working repository. A `helm/` directory means there is a chart for Kubernetes deployments. `phpunit.xml` and `tests/` mean the PHP side has a test harness. `webhook-paw.paw` is a Paw file, which is an API client definition you can open to make signed or scripted calls against the app. `laravel-echo-server.json.example` is the relay's own config template, and `SECURITY.md` is a disclosure policy. None of these are explained in the README; all of them are the first place to look when you go past the quick start.

The release history is the other thing to weigh. The three tags are 1.1 with Redis support from 2018-04-29, 1.2 LTS from 2021-05-17, and 1.3 LTS from 2023-06-21. The last push to the master branch is dated 2026-09-25, so commits continue, but no tag has been cut since 2023. If you pin a version you are pinning three years old; if you track master you are tracking something with no named release behind it.

The documentation itself lives elsewhere, at docs.webhook.site, built on the Just the Docs theme for Jekyll. The README is a signpost to that site rather than a manual, and the WebhookScript language is credited as based on Primi by Přemysl Karbula, with the editor built on Ace and JSONPath extraction provided by FlowCommunications.

Editorial conclusion

webhook.site suits a developer who needs to see what a third party actually sends, and the self-hosted MIT version is enough for that, since capture needs nothing more than a public URL. It is the wrong tool the moment you want Custom Actions, since that editor is not in the open-source build, and the wrong tool for a webhook receiver that must survive real traffic, since a debugging inbox is not a queue with retention. Before deploying your own copy, read the shipped compose file rather than the documentation: it publishes 8084, runs with APP_DEBUG true, and opens the websocket relay to any origin. Then set an APP_KEY, which the example environment leaves blank, and decide whether the old toolchain in the Dockerfile is something you want to maintain.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. webhooksite/webhook.site on GitHub