What is a webhook endpoint?
A webhook endpoint is the public HTTPS URL on your server that receives webhook POST requests from a source system. It must be publicly reachable (localhost won't work — you need a real domain or a forwarding service like WebhookWhisper for development), use a valid TLS certificate (every major provider refuses plain HTTP), and stay stable long-term since changing the URL means re-registering with every source. Each source typically gets its own path (`/webhooks/stripe`, `/webhooks/github`) so signature schemes and logs don't get tangled. Respond with HTTP 200 within seconds, then process asynchronously.
A webhook endpoint is just a route on your HTTP server — typically something like POST /webhooks/stripe — that accepts incoming webhook deliveries. It needs to be publicly reachable over HTTPS and stable enough that the source system can dial it for years.
Three properties matter. Public: the URL must resolve from the source system's network. Localhost or a VPC-internal address won't work; you need a real domain or a forwarding service like WebhookWhisper that gives you a public URL bridged to localhost during development. HTTPS: every major provider (Stripe, GitHub, Shopify, Slack, Twilio) refuses to deliver to plain HTTP. The TLS certificate must be valid — self-signed and expired certs both cause delivery failures. Stable: changing the URL means re-registering it with every source. In production, treat the endpoint URL as a long-term commitment.
Endpoint design has a few non-obvious rules. The route should be path-specific to one source (/webhooks/stripe, /webhooks/github — not a single /webhooks that switches on a query string), because each source has different signature schemes, different retry behavior, and you'll want separate logs and metrics per source. The route must read the raw request body before parsing it, because HMAC signature verification is computed over the exact bytes the provider sent — most signature failures in production come from express.json() having parsed the body before the verification code runs.
Endpoints should respond with HTTP 200 within seconds, not minutes. Most providers consider 3-30 seconds the timeout before they retry, and a slow endpoint cascades into duplicate deliveries and queue backlogs. The pattern is: validate signature, write the event to a queue or DB, return 200, then process asynchronously. Keep the synchronous path under 100ms wherever possible.
If your endpoint is going to be public and receive untrusted POSTs from the internet, treat it like any other public endpoint — rate limit it, log every request with full headers, and reject obviously bad payloads early.
See Webhook Endpoint in real traffic
WebhookWhisper captures every webhook with full headers, body, signature, and timing — so concepts like webhook endpoint stop being abstract and become something you can inspect.
Start Free