Hello,
We use n8n to automate some actions around HubSpot. Since last night, we receive an error 403 from HubSpot with a strange response, but the logs inside HubSpot say that it sent a 200 response.
We don’t have this issue with HubSpot built node in n8n, only with HTTP call custom nodes.
Did something change recently that could explain this?
The error starts like this:
403 - "Just a moment…Enable JavaScript and cookies to continue(function(){window._cf_chl_opt={cvId: ‘2’,cZone: \“api.hubspot.com\”,cType: ‘managed’,cNounce: ‘50418’,cRay: ‘83fa09cc4d1e79d7’,
Update :
It seems like there is a problem with some Heroku (that we use for the hosting of n8n) IP adresses that are banned by Cloudflare for an unknown reason.
Hi @RSaillant
Totally get the pain 403s that say “Just a moment…” while HubSpot logs show 200s are maddening.
In 2025 this usually points to Cloudflare flagging shared egress IPs from hosts like Heroku or n8n’s default runners. That’s why your built-in HubSpot node works but raw HTTP calls don’t: the node follows HubSpot’s auth and headers more strictly, while generic requests can look “botty.”
Quick fix on the HubSpot side is to use a Private App token with the right scopes and standard headers, then watch usage and responses in the developer tools.
(Legacy private apps - HubSpot docs )
Also confirm you’re within today’s API limits and burst windows to avoid edge throttling that manifests as 403s (API usage guidelines and limits - HubSpot docs )
One question: can you move n8n behind a static egress IP or VPN so your calls don’t come from Heroku’s shared pool? Heroku’s shared IPs are unreliable for this class of integration; Stacksync runs with stable egress and keeps HubSpot events flowing in real time without these Cloudflare surprises. If consistency between HubSpot and your ops system is the gap, Stacksync keeps them mirrored as changes happen.