n8n Cloud Ate My Code
3 Methods, 9 Errors, 1 Working Pipeline
March 2026
The Setup
I'm building a field-ready lead capture system for a home services company. The architecture is straightforward: a PWA that sales reps use from their phone, an n8n workflow that processes the data, and HubSpot as the CRM. Simple pipeline — fill out a form, hit submit, contact + deal + follow-up task appear in HubSpot.
I had the PWA deployed on Vercel, the n8n workflow designed with 21 nodes, and the HubSpot Private App configured with the right scopes. Everything looked correct on paper.
Then I hit Submit.
The Error Cascade
What followed was a 3-hour debugging session where every fix uncovered a new problem. Nine issues, in sequence, each one hidden behind the last.
Error 1: SSL Certificate Invalid
The Vercel-hosted PWA showed a certificate error. DNS was resolving to a completely wrong IP — turns out the ISP (PLDT in the Philippines) was intercepting and blocking Vercel traffic. Fix: switch to Google DNS (8.8.8.8).
Error 2: "Unable to connect"
The PWA submitted but got a network error. The NEXT_PUBLIC_N8N_WEBHOOK_URL environment variable wasn't set in Vercel. Added it, but the app still failed — because Next.js inlines NEXT_PUBLIC_ variables at build time, not runtime. Had to redeploy without build cache.
Error 3: Webhook 404
The n8n webhook returned "not registered." The workflow was in test mode. Toggled the Active switch off, then on.
Error 4: CORS Blocked
The browser silently dropped the cross-origin request. Added Allowed Origins: * in the webhook node's Options.
Error 5: 200 OK, Empty Body
The webhook returned a 200 status code but Content-Length: 0. The webhook was configured with responseMode: "responseNode", which means it waits for a Respond to Webhook node to fire. But several nodes in the chain were disabled (Google Drive, Calendar), so execution died before reaching the response node.
The webhook just sent back... nothing. Fix: rerouted the workflow to skip disabled nodes and go straight to the response.
Error 6: httpRequestWithAuthentication Not Supported
This is where it got interesting. My Code nodes used the standard pattern from n8n documentation:
this.helpers.httpRequestWithAuthentication.call(
this, 'httpHeaderAuth', { ... }
)Works perfectly on self-hosted n8n. On n8n Cloud?
n8n Cloud sandboxes Code nodes differently. The authenticated HTTP helper isn't available.
Error 7: fetch Is Not Defined
Fine, I thought. I'll use the native fetch() API instead, passing the Bearer token manually in headers.
n8n Cloud's Code node sandbox doesn't expose fetch() either. This isn't a standard Node.js runtime — it's a restricted execution environment.
Error 8: The Method That Actually Works
Third time's the charm. this.helpers.httpRequest() — the unauthenticated version of the HTTP helper — is available in Cloud Code nodes. It doesn't look up credentials from the n8n credential store. It just makes plain HTTP requests with whatever headers you give it.
const response = await this.helpers.httpRequest({
method: 'POST',
url: 'https://api.hubapi.com/crm/v3/objects/contacts',
body: contactData,
headers: {
'Content-Type': 'application/json',
'Authorization': `Bearer ${TOKEN}`
},
json: true
});The request went through. But then...
Error 9: HubSpot 400 Bad Request
The HubSpot API rejected the contact creation with a 400. Two issues: notes_last_updated isn't a default HubSpot property (doesn't exist in a fresh test account), and sending email: '' (empty string) fails HubSpot's email validation. Removed the non-existent property, only included email when it had a value.
The Result
After fixing all nine issues, the pipeline worked. PWA form submission to HubSpot contact + deal + follow-up task in about 4 seconds. The client tested it from his phone that same afternoon.
What n8n Cloud Code Nodes Actually Support
This is the table I wish existed in the documentation:
| Method | Self-Hosted | Cloud | Notes |
|---|---|---|---|
| this.helpers.httpRequestWithAuthentication() | Yes | No | The one everyone uses in tutorials |
| fetch() | Yes | No | Not available in the sandbox |
| this.helpers.httpRequest() | Yes | Yes | Pass auth headers manually |
| $vars.VARIABLE_NAME | Yes | Admin only | Editors can't create variables |
| require() / import | No | No | Neither runtime allows it |
If you're writing Code nodes for n8n Cloud, this.helpers.httpRequest() with manual headers is your only option for external API calls.
The Deeper Lesson
The real issue wasn't any single error — it was that nine problems were stacked on top of each other, each one masking the next. The SSL error hid the missing env var. The missing env var hid the CORS issue. The CORS fix revealed the empty response. The empty response led to the Code node sandbox limitations.
Each fix was simple in isolation. The difficulty was that you couldn't see error #5 until you'd solved errors #1 through #4. There's no shortcut for this kind of debugging — you fix what you can see, then look at what's revealed.
Building automation systems that span multiple platforms (Vercel, n8n Cloud, HubSpot, ISP-level DNS) means accepting that the failure domain is wide. The debugging skill isn't knowing the answer — it's knowing which layer to inspect next.
Built with n8n Cloud, Next.js, HubSpot, and Vercel. Debugged with patience and three different HTTP methods.