Authentifizierung

Jeder, der eine Webhook-URL kennt, kann eine Anfrage an diese senden. Die Authentifizierung verhindert daher, dass Fremde Ihre Shopify Flow-Workflows auslösen. Richten Sie diese Einstellung für jeden Webhook einzeln im Abschnitt „Sicherheit“ des jeweiligen Webhooks ein.

Die drei Methoden

Verfahren	Wie sich der Anrufer ausweist	Verwenden Sie es, wenn
Keine	Nichts	Nur zu Testzwecken - niemals in der Produktion
Statisches Token	Ein festes Geheimnis in einem Anfrage-Header	Nahezu jede Integration (n8n, Make, Zapier, Ihr eigener Code)
HMAC SHA-256	Eine Signatur, die aus der Anfrage und einem gemeinsamen Geheimnis berechnet wird	Der Absender signiert seine Webhooks (Stripe, GitHub, Slack, …)

Statisches Token

Klicken Sie auf die Schaltfläche „Generieren“ im Webhook, um ein sicheres Zufallstoken zu erhalten, oder fügen Sie Ihr eigenes Token ein. Der Aufrufer übermittelt es in einem Header:

Der Webhook-Editor: Name und Authentifizierung auf der linken Seite, die Endpunkt-Karte mit Status, Webhook-URL und Webhook-ID auf der rechten Seite, darüber „Live-Vorschau“, „Testen“ und „Nutzung“ — Ein statisches Token: Wählen Sie aus, wie der Absender es übermitteln soll, generieren oder fügen Sie das Token ein und kopieren Sie die Webhook-URL aus der Endpunkt-Karte.

bash

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: your-token" \
  -d '{"orderId":"1001"}'

Den Namen der Kopfzeile ändern

Einige Systeme können nur einen Header senden, den sie bereits verwenden. Legen Sie den Namen des Auth-Headers in den erweiterten Einstellungen fest, und wir lesen das Token aus diesem Header anstelle von X-Api-Key aus:

bash

  -H "X-Custom-Auth: your-token"

Bei Header-Namen wird die Groß-/Kleinschreibung nicht berücksichtigt. Reservierte Namen werden abgelehnt - Host, Authorization, Cookie, X-Forwarded-*, X-Webhook-*, CF-* und ähnliche. Diese werden von Proxys und CDNs gesetzt oder umgeschrieben, sodass ein daraus ausgelesenes Token vom Angreifer kontrolliert werden könnte.

Wohin das Token gelangt

Nicht jeder Absender kann einen beliebigen Header hinzufügen. Wie übermittelt der Absender das Token? Auf der Registerkarte „Webhook“ stehen vier Möglichkeiten zur Verfügung:

Auswahl	Der Absender sendet	Verwenden Sie es, wenn
In einer benutzerdefinierten Kopfzeile	`X-Api-Key: <token>` oder der von Ihnen gewählte Header-Name	Die Standardeinstellung und die Vorgehensweise der meisten Integrationen
Als Inhaber-Token	`Authorization: Bearer <token>`	Das Tool verfügt über ein Feld für das Bearer- oder API-Token
Als Benutzername und Passwort	HTTP Basic, mit einem Benutzernamen Ihrer Wahl und dem Token als Passwort	Das Tool unterstützt ausschließlich die Basis-Authentifizierung.
In der URL	`?token=<token>` oder der von Ihnen gewählte Parametername	Der Absender kann lediglich eine einfache URL aufrufen und keine Header festlegen

Authorization Der Name des benutzerdefinierten Headers bleibt bewusst reserviert: „Bearer“ und „Basic“ sind die unterstützten Verwendungsarten, und beide werden für Sie automatisch verarbeitet. Bei einer 401-Anfrage für diese beiden Methoden wird zudem ein WWW-Authenticate-Header übermittelt, da einige HTTP-Clients Anmeldedaten erst nach einer Anforderungsabfrage senden.

Die URL-Option ist die unsicherste der vier - URLs tauchen in Protokollen, Referrern und im Browserverlauf auf -, verwenden Sie sie daher nur, wenn der Absender Ihnen keine andere Wahl lässt. Die App zeigt die fertige URL mit dem Token an und maskiert diesen Parameter überall dort, wo die Anfrage gespeichert wird.

HMAC SHA-256

Der Absender berechnet anhand eines gemeinsamen Geheimnisses eine Signatur für die Anfrage; wir berechnen diese erneut und vergleichen sie. Eine offengelegte Anfrage kann nicht mit geänderten Inhalten erneut gesendet werden, da der Inhalt dann nicht mehr mit der Signatur übereinstimmt.

Anbieter-Voreinstellungen

Wählen Sie unter „Signaturanbieter“ Ihren Anbieter aus, und wir führen die Überprüfung anhand des genauen Schemas dieses Anbieters durch - einschließlich Header-Name, Kodierung, signierter Inhalt und Gültigkeitsdauer der Signatur. Fügen Sie das Signaturschlüssel aus dem Dashboard des Anbieters ein, und schon sind Sie fertig.

Es gibt 22 integrierte Anbieter, für die jeweils eine eigene Einrichtungsanleitung vorliegt: Calendly, Customer.io, GitHub, Lemon Squeezy, Linear, Mollie, Paddle, Paystack, Razorpay, Sanity, Sendcloud, Sentry, Shopify, Slack, Square, Standard-Webhooks (OpenAI, Supabase), Stripe, Svix (Clerk, Resend), Typeform, Vercel, WooCommerce und Zendesk. Sollte Ihr Anbieter nicht aufgeführt sein, beschreiben Sie bitte, wie die Authentifizierung mit einem benutzerdefinierten Schema erfolgt.

Die vollständige Liste, die benutzerdefinierte Option und den integrierten Signatur-Tester finden Sie unter Überprüfung signierter Webhooks.

Ein Webhook mit HMAC-Authentifizierung und Stripe als Signaturanbieter, der das Feld „Signaturgeheimnis“ anzeigt, was dabei überprüft wird und welche Schritte zur Anbindung an Stripe erforderlich sind — Ein signierter Absender, in diesem Fall Stripe: Wählen Sie den Anbieter aus, fügen Sie dessen Signaturschlüssel ein, und der Editor zeigt Ihnen an, was bereits ausgewählt ist und wie Sie die Verbindung herstellen können.

Generisches HMAC

Da weder eine voreingestellte noch eine benutzerdefinierte Schema-Einstellung vorliegt, verwenden wir unsere eigene: Der Aufrufer sendet X-Signature, den HMAC-SHA256-Hash der Werte des X-Webhook-*-Headers unter Verwendung des Signaturschlüssels.

bash

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Webhook-Data: value1value2" \
  -H "X-Signature: <hmac-sha256 of the X-Webhook-* values>" \
  -d '{"data":"payload"}'

Wie eine Ablehnung aussieht

Bei einer fehlgeschlagenen Authentifizierung wird 401 zurückgegeben, wobei der JSON-Body den Grund angibt - die vollständige Liste der Codes finden Sie unter Hintergrund und Fehlerbehebung. Abgelehnte Aufrufe werden weiterhin im „Live Request Inspector“ angezeigt, während Sie den Webhook bearbeiten, sodass Sie genau sehen können, warum ein Aufruf fehlgeschlagen ist.

Rotation des Geheimnisses ohne Ausfallzeiten

Das Ändern eines Geheimnisses in einem Schritt bedeutet, dass jede mit dem alten Geheimnis signierte Anfrage fehlschlägt, bis der Absender die Änderung übernommen hat. Die Rotation des Geheimnisses über den Webhook verhindert dies: Er enthält ein zweites gültiges Geheimnis, das neben dem Hauptgeheimnis akzeptiert wird - sowohl für das statische Token als auch für jedes Signaturschema.

Geben Sie das neue Passwort unter „Zweites gültiges Passwort“ ein und speichern Sie die Eingabe. Beide Passwörter werden nun akzeptiert.
Stellen Sie den Absender auf das neue Geheimnis um.
Klicken Sie auf „Promote“, wodurch der Eintrag in das Hauptfeld verschoben und das zweite Feld geleert wird, und speichern Sie anschließend.

Es wird zu keinem Zeitpunkt eine Anfrage abgelehnt. Das zweite Geheimnis wird genau wie das Hauptgeheimnis gespeichert und von der API niemals zurückgegeben - es wird lediglich mitgeteilt, ob eines festgelegt ist.

Das Geheimnis bewahren

Das Token wird von unserer REST-API oder unserem MCP-Server auf keiner Zugriffsebene zurückgegeben - diese Geben Sie lediglich an, ob einer gesetzt ist. Siehe Entwickler-API und MCP.
Die Daten sind im Ruhezustand verschlüsselt.
Die Änderung wird sofort wirksam; verwenden Sie daher bitte den oben genannten Shopify Flow anstelle von das Hauptfeld überschreiben.
Der gespeicherte Aufrufverlauf maskiert den Authentifizierungsheader, die Basic-Anmeldedaten und das URL-Token, Ein Screenshot des Verlaufs gibt also Ihr Geheimnis nicht preis.

Eine weitere Eingrenzung

Die Authentifizierung belegt, dass der Anrufer das Geheimnis kennt. IP-Zulassungslisten schränkt ein, von wo aus ein Anruf erfolgen darf, und kann mit jedem der oben genannten Modi kombiniert werden.