Hintergrund und Fehlerbehebung
Jede Anfrage, die bei einem Webhook eingeht, wird protokolliert - unabhängig davon, ob sie angenommen oder abgelehnt wurde. Der Verlauf ist der erste Ort, an dem Sie nachsehen sollten, wenn etwas nicht funktioniert hat.
Das Vorlesen einer Ansprache
Öffnen Sie „Verlauf“ und klicken Sie auf einen Eintrag. Sie erhalten den Zeitstempel, den Status, den Aufrufer, die Dauer, die Payload, die (maskierten) Request-Header, den Abfrage-String sowie bei Fehlern die Fehlermeldung und jeden Wiederholungsversuch.
| Status | Bedeutung |
|---|---|
| Ausstehend | Angenommen und in die Warteschlange gestellt, noch nicht an Shopify Flow übermittelt |
| Erfolg | Shopify Flow den Trigger akzeptiert |
| Fehlgeschlagen | Die Zustellung ist endgültig fehlgeschlagen - auf der Detailseite wird der Grund dafür angezeigt |
Die Spalte „Aufgerufen von“ geben an, woher ein Aufruf stammt: User (ein externes System), Flow (eine Shopify Flow-Aktion, die den Webhook aufruft), Test (die Schaltfläche „Testen“) oder CURL.


Ablehnungen und was die einzelnen Ablehnungen bedeuten
Eine abgelehnte Anfrage gelangt niemals an Shopify Flow. Der Antworttext enthält einen maschinenlesbaren code:
| Code | HTTP | Was ist schiefgelaufen? | Beheben |
|---|---|---|---|
webhook_not_found |
404 | Kurzcode unbekannt | Bitte überprüfen Sie die URL; der Webhook wurde möglicherweise gelöscht |
webhook_disabled |
400 | Der Webhook ist deaktiviert | Aktivieren Sie diese Funktion auf der Webhook-Seite |
unauthorized |
401 | Token fehlt oder ist falsch | Bitte überprüfen Sie das Token und den Namen des Headers |
missing_signature |
401 | HMAC-Modus, ohne Signatur-Header | Senden Sie den Signatur-Header, den Ihre Voreinstellung erwartet |
invalid_signature |
401 | Die Unterschrift stimmte nicht überein | Vergewissern Sie sich, dass das Signaturgeheimnis korrekt ist und dass der Textkörper während der Übertragung unverändert geblieben ist. |
auth_not_configured |
401 | Authentifizierungsmodus ist eingestellt, es wurde jedoch kein Token gespeichert | Speichern Sie ein Token im Webhook |
invalid_json |
400 | Der Textkörper ist kein gültiges JSON. | Senden Sie gültiges JSON oder legen Sie den Content-Type fest, den Ihr Body tatsächlich hat (Formulardaten und XML werden ebenfalls gelesen) |
invalid_body |
400 | Ein Formular oder ein XML-Hauptteil konnte nicht gelesen werden, oder der Hauptteil ist der Literalwert null. |
Senden Sie ein JSON-Objekt oder einen Textkörper, dessen „Content-Type“ damit übereinstimmt |
mapping_field_missing |
400 | Ein zugeordnetes Feld fehlt in der Payload | Das Feld senden oder die Zuordnung aufheben |
unexpected_fields |
400 | Der Textkörper enthält Felder, die nicht zugeordnet sind | Ordnen Sie diese zu, entfernen Sie sie oder aktivieren Sie die Option „Benutzerdefinierten Anfragetext zulassen“ |
ip_not_allowed |
403 | Die Adresse des Anrufers ist nicht in der IP-Zulassungsliste des Webhooks enthalten | Siehe IP-Zulassungslisten |
invalid_proxy_signature |
401 | Die Proxy-Adresse der App wurde direkt aufgerufen, anstatt über die Domain Ihres Shops. | Verwenden Sie die Webhook-URL genau so, wie sie in der App angezeigt wird - siehe CORS, die Proxy-URL der App und Browser-Aufrufe |
payload_too_large |
413 | Die Payload-Menge des Shopify Flow-Datenstroms beträgt mehr als 50 KB | Senden Sie weniger Daten oder deaktivieren Sie die Schaltflächen für die Datenanforderung |
quota_exceeded |
400 | Planlimit erreicht | Siehe Pläne und Nutzung |
Live-Anfrage-Inspektor
Solange Sie einen Webhook im Editor geöffnet haben, zeigt der Inspektor die eingehenden Anfragen in Echtzeit an - einschließlich der abgelehnten Anfragen, zusammen mit dem Grund dafür. Dies ist bei weitem der schnellste Weg, einen Absender zu debuggen: Senden Sie eine Anfrage ab und beobachten Sie, wie sie ankommt.
Auch unterdrückte Duplikate werden hier angezeigt und entsprechend gekennzeichnet - siehe Schutz vor doppelten Lieferungen.
Wiederholung
Jeder frühere Aufruf kann über die entsprechende Detailseite erneut abgespielt werden. Beim erneuten Abspielen wird dieselbe Payload über denselben Webhook erneut gesendet.
Es eignet sich besonders gut für zwei Dinge:
- Erstellen eines Flow-Workflows. Erfassen Sie Ereignisse über den Webhook-Trigger und spielen Sie anschließend ein echtes Rufen Sie diese Funktion bei Shopify Flow auf, damit Shopify Flow Ihre tatsächlichen Feldnamen erkennt.
- Wiederherstellung nach einem unterbrochenen Workflow. Beheben Sie den Fehler im Workflow und führen Sie anschließend die bereits ausgeführten Ereignisse erneut aus. obwohl es falsch war.
Wiederholungen werden im Verlauf entsprechend gekennzeichnet und werden nicht auf Ihren Plan angerechnet.
Häufige Situationen
Es gehen Aufrufe ein, doch der Workflow wird nicht ausgeführt. Fast immer liegt dies an der Bedingung für die Webhook-ID. Ein „Webhook Trigger“-Workflow empfängt Ereignisse von jedem Webhook, den Sie besitzen; daher benötigt er eine Bedingung, die mit der spezifischen Webhook-ID übereinstimmt - siehe Erstellen Sie Ihren ersten Webhook.
Der Workflow wird zweimal ausgeführt. Entweder nutzen zwei Workflows den Webhook-Trigger ohne unterschiedliche Bedingungen, oder Ihr Absender unternimmt einen erneuten Versuch. Anhand des Verlaufs können Sie erkennen, was zutrifft: Zwei Einträge bedeuten, dass zwei Anfragen eingegangen sind. Aktivieren Sie die Option Schutz vor doppelten Lieferungen.
Im Verlauf ist überhaupt nichts zu finden. Die Anfrage ist nie bei uns eingegangen. Bitte überprüfen Sie die URL und den Kurzcode und stellen Sie sicher, dass der Absender auf seiner Seite keine Probleme mit TLS oder DNS hat.
Der Status bleibt auf „Ausstehend“ stehen. Die Zustellung wird mit einer Wartezeit erneut versucht; bei einem dauerhaften Fehler wechselt der Status zu „Fehlgeschlagen“ mit Angabe des Grundes. Sollte der Status ungewöhnlich lange auf „Ausstehend“ stehen bleiben, überprüfen Sie bitte status.codecreationlabs.cloud.

