I am experiencing an issue where the WhatsApp Trigger node in n8n (v2.30.8, self-hosted via Docker with a tunnel) fails to receive incoming messages from the Meta Cloud API test number. Although Telegram nodes and other webhooks operate correctly on this infrastructure, and Meta’s webhook verification passed successfully with the messages field subscribed, sending a test message from a personal device does not trigger the workflow or generate any execution logs. Could this be related to a specific routing quirk with the WhatsApp trigger node under a tunneled Docker environment, or an oversight in the Meta dashboard subscription settings? Any technical insights would be appreciated.
Arabic:
أواجه مشكلة عدم استقبال رسائل واردة عبر نود تريغر الواتساب في n8n (الإصدار 2.30.8، مستضاف ذاتياً عبر Docker باستخدام Tunnel) من الرقم التجريبي الخاص بـ Meta Cloud API. ورغم أن نودز التيليجرام وباقي الويب هوكس تعمل بكفاءة على نفس البنية التحتية، واجتياز التحقق من الويب هوك بنجاح مع تفعيل حقل الـ messages، إلا أن إرسال رسالة اختبارية من جهاز شخصي لا يؤدي إلى إطلاق الورك فلو أو تسجيل أي Executions. فهل توجد مشكلة معروفة في توجيه البيانات تخص تريغر الواتساب مع بيئة الـ Docker والتانل، أم أن هناك إعداداً ناقصاً في لوحة تحكم ميتا؟ أرجو الإفادة بالحلول التقنية المناسبة.
it isn’t the tunnel. Telegram running on the same setup rules that out, and passing verification only proves the callback URL is reachable, not that anything routes to it.
Check which app your WABA is subscribed to. In the Graph API Explorer, GET {your-WABA-ID}/subscribed_apps. A WABA can sit subscribed to a different app than the one holding your webhook, and real messages reach only the subscribed app while Meta still shows them in your event log. Several people there lost days to proxies before finding it.
The other one to rule out: on the test number in Development mode, Meta forwards only from numbers listed under API Setup > To, so your personal number has to be on that list.
one more thing worth checking, only one callback url can be active per Meta app. if you ever wired that same app to another n8n instance or an old workflow with the same credential, whoever registered last owns the webhook and the older one just goes quiet. re-save the trigger node so it re-registers and check the app dashboard shows your current tunnel url and not an old one.
also test the n8n side on its own, curl a fake message payload straight at the production webhook url. if the workflow runs from that, n8n and the tunnel are fine and it is 100% a Meta subscription thing, not docker routing.