Après avoir migré un workflow de n8n Cloud vers une instance auto-hébergée dans Docker (même volume n8n_data), un workflow avec un nœud Shopify Trigger (sujet orders/paid) apparaît comme actif à la fois dans l’interface utilisateur et dans la base de données (workflow_entity.active = 1, triggerCount = 2), et dispose de sa ligne correspondante dans webhook_entity avec le chemin attendu. Cependant, les requêtes POST entrantes à ce chemin sont rejetées :
Received request for unknown webhook: The requested webhook "POST 257536d8-dabd-4c1a-bc22-f97d64aa082b/webhook" is not registered.
Oui, mais laisse n8n recréer les deux enregistrements au lieu de modifier manuellement webhook_entity. Dépublie le workflow, configure N8N_WEBHOOK_URL avec l’URL HTTPS publique et N8N_PROXY_HOPS=1, redémarre le conteneur et republié-le. À partir de la version 2.35 de n8n, WEBHOOK_URL est obsolète.
Une fois publié, n8n devrait recréer la route locale et l’abonnement dans Shopify. Supprime tous les anciens abonnements qui pointent encore vers n8n Cloud. Si l’activation échoue, vérifie les journaux du conteneur à ce moment-là, car la raison de l’échec y apparaîtra.
Merci à tous pour vos réponses, j’ai finalement réussi à le résoudre, il s’avère que même si les identifiants semblaient connectés et corrects, ils ne l’étaient pas, je ne sais pas si c’était dû à un redémarrage/mise à jour, mais en supprimant et en recréant les identifiants, tout fonctionne à nouveau correctement.
Le correctif d’Anshul règle la route. Reste la question de l’argent : les commandes payées alors que le webhook était mort.
Shopify réessaye une livraison échouée jusqu’à huit fois en quatre heures et, si les échecs persistent, supprime l’abonnement. C’est-à-dire que tout orders/paid de plus de quelques heures avant le correctif ne sera plus livré par webhook, et si l’abonnement a été supprimé, republier le workflow le recrée mais ne renvoie rien de la période morte.
Récupération en deux étapes :
Avec l’Admin API, récupère les commandes avec financial_status=paid et updated_at depuis le moment de la migration, et passe-les par le même chemin du workflow qu’utiliserait le trigger (un trigger Manual/Schedule qui appelle le même sous-workflow fonctionne).
Rends ce chemin idempotent par id de commande avant de reproduire quoi que ce soit : si Shopify réessaye encore une livraison tardive, ou si tu exécutes la récupération deux fois, tu ne veux pas la même commande traitée deux fois.
Et une vérification rapide dans Shopify Admin > Notifications > Webhooks : si l’abonnement n’apparaît plus là, la période morte a commencé avant le dernier réessai échoué, pas à la migration.