Webhook URL vs. endpoint

July 23, 2026 · 3 min read

Every service names it differently: GitHub says “Payload URL”, Stripe says “Endpoint”, Zapier says “Webhook URL”, older docs say “callback URL”. The good news: they all mean the same thing.

The terms, decoded

Term	Means
Webhook URL	The address events are sent to
Payload URL	Same thing (GitHub's wording – the payload goes there)
Endpoint	Same address, seen from the receiving side – the thing that accepts the request
Callback URL	Same idea, older term, also used in OAuth for something different – careful
Target / destination URL	Wording used by automation tools

Strictly speaking, the URL is the address and the endpoint is what listens at that address. In everyday use they're interchangeable.

What makes a good webhook URL

HTTPS, always. Most services refuse plain HTTP – and payloads often contain customer data.
Publicly reachable. localhost can't be called from the internet; for local development you need a tunnel (see testing webhooks).
Unguessable. A long random component acts as the password – /webhook gets found by scanners, /a7f3k9d2m5x8… does not.
Stable. If the URL changes, every sender needs reconfiguring – so make it easy to swap out on your side.
Fast to answer. Accept, then work asynchronously.

Where to find it in the sending service

Almost always in the settings of the project, shop or repository: GitHub under Settings → Webhooks, Stripe under Developers → Webhooks, Shopify under Settings → Notifications, GitLab under Settings → Webhooks. You paste your URL there and pick the events you want.

Getting a webhook URL without a server

If you only want to know that something happened, you don't have to build one. Webhooky hands you a personal endpoint URL the moment you install the app (Android / iOS) – with a random 24-character key, HTTPS, and every POST arriving as a push notification. New to the topic? Start with what is a webhook.

Get Webhooky

Free for your first 100 notifications – set up your endpoint in two minutes.