Webhook-URL vs. Endpoint

Die Begriffe, entschlüsselt

Begriff	Bedeutet
Webhook-URL	Die Adresse, an die Ereignisse gesendet werden
Payload-URL	Dasselbe (GitHubs Wortwahl – dorthin geht der Payload)
Endpoint	Dieselbe Adresse, von der Empfängerseite gesehen – das, was die Anfrage annimmt
Callback-URL	Dieselbe Idee, älterer Begriff, in OAuth aber für etwas anderes benutzt – aufpassen
Ziel- / Destination-URL	Formulierung von Automatisierungstools

Streng genommen ist die URL die Adresse und der Endpoint das, was an dieser Adresse lauscht. Im Alltag werden sie synonym verwendet.

Was eine gute Webhook-URL ausmacht

• Immer HTTPS. Die meisten Dienste verweigern reines HTTP – und Payloads enthalten oft Kundendaten.
• Öffentlich erreichbar. localhost ist aus dem Internet nicht aufrufbar; für lokale Entwicklung brauchst du einen Tunnel (siehe Webhooks testen).
• Nicht erratbar. Ein langer Zufallsteil wirkt wie ein Passwort – /webhook finden Scanner, /a7f3k9d2m5x8… nicht.
• Stabil. Ändert sich die URL, muss jeder Absender neu konfiguriert werden – mach sie auf deiner Seite leicht austauschbar.
• Schnell antwortend. Erst annehmen, dann asynchron arbeiten.

Wo du sie im sendenden Dienst einträgst

Fast immer in den Einstellungen des Projekts, Shops oder Repositories: GitHub unter Settings → Webhooks, Stripe unter Developers → Webhooks, Shopify unter Einstellungen → Benachrichtigungen, GitLab unter Settings → Webhooks. Dort fügst du deine URL ein und wählst die gewünschten Ereignisse.

Eine Webhook-URL ohne Server bekommen

Wenn du nur wissen willst, dass etwas passiert ist, musst du keine bauen. Webhooky gibt dir eine persönliche Endpoint-URL, sobald du die App installierst (Android / iOS) – mit zufälligem 24-Zeichen-Key, HTTPS, und jeder POST kommt als Push-Benachrichtigung an. Neu im Thema? Starte bei Was ist ein Webhook.

Hol dir Webhooky

Kostenlos für deine ersten 100 Benachrichtigungen – Endpoint in zwei Minuten eingerichtet.