Hello,
I am trying to receive webhook events from Bitrix24 CRM in my self-hosted n8n.
Previously it worked on another cloud n8n account, but now on my current hosted instance the Webhook node generates URLs starting with localhost.
Webhook method is currently set to GET. I also tested POST, but it still does not receive data.
Because of that, Bitrix24 does not seem to reach the webhook.
Is it normal that webhook URLs show localhost in self-hosted n8n?
What should I configure so external services like Bitrix24 can access the webhook correctly?
Should I set WEBHOOK_URL or another setting?
Thank you.
good day @Anna5
I think this is happening because your self-hosted n8n instance is generating webhook URLs from the internal host (localhost). To fix it, set WEBHOOK_URL=https://your-domain.com/. If you’re behind a reverse proxy, also configure N8N_PROXY_HOPS=1 and make sure the X-Forwarded-* headers are passed correctly.
@Anna5 if its docker consider tamy’s advice, but if it is on NPM you have to run a command to set the env variable in your terminal, and maybe you are using Ngrok or cloudFlare tunnels, so make sure to set the variable or run on windows that would be “set WEBHOOK_URL=https://yourURl.com” and on linux the set would be replaced with export thats it
Thank you for your reply.
I think I may now understand the real issue.
To access our n8n instance, I need to connect through our company VPN first. This most likely means that our n8n is hosted inside the company internal network and is not publicly accessible from the internet.
I can access it because I use VPN, but external cloud services like Bitrix24 may not be able to reach the webhook endpoint.
Could this be the real reason why Bitrix24 outgoing webhooks are not reaching n8n?
If yes, is there a recommended way to keep the n8n editor private/internal, but expose only webhook endpoints publicly for external services?
Thank you.
thank you for the clarification.
Yes, that does sound like the most likely explanation.
In this case, the recommended setup is usually to keep the n8n editor private/internal and expose only the webhook routes publicly (for example through a reverse proxy, firewall rules, or API gateway), while setting WEBHOOK_URL to the public domain used for incoming webhooks.
@Anna5 since n8n is behind your company VPN, forget about exposing webhooks — just poll Bitrix24 on a schedule instead. their REST API lets you pull events directly so external services never need to reach your n8n at all.
set up an HTTP Query Auth credential with your Bitrix24 webhook token as the auth param, swap the URL for your actual Bitrix REST endpoint, done.
This is a classic self-hosted setup issue. The fix is to set the WEBHOOK_URL environment variable to your public domain.
In your .env file (or Docker environment), add:
WEBHOOK_URL=https://your-domain.com/
Make sure it includes the trailing slash and uses https:// if you have SSL. Once you restart n8n with this variable set, the Webhook node will show your public domain URL instead of localhost.
If you’re running Docker, it looks like:
-e WEBHOOK_URL=https://your-domain.com/
Then Bitrix24 will be able to reach your webhook endpoint directly.
One thing I’d add is that the public webhook setup only helps if you have admin access to change the n8n config, proxy, DNS, or firewall.
If you don’t control that side, then polling may be the better option.
Instead of waiting for Bitrix24 to call n8n, have n8n check Bitrix24 every few minutes for new or updated items. It is not as instant as a webhook, but it works when your n8n instance is locked behind VPN and you cannot expose public endpoints.
That is usually the tradeoff:
Webhook = faster, but needs public access.
Polling = slower, but works better in restricted company environments.
So in this case, if you cannot get the admin/network team to expose only the webhook path safely, I’d go with polling.