I’m working with an N8N workflow that’s embedded in my app using an iframe. I need to extract URL parameters from the current page URL when executing a custom node, but I’m running into issues with the typical browser-based approaches.
What I’ve attempted so far:
Using window.location.href - but the window object isn’t available in this context
Trying the Node.js url module approach:
const urlModule = require('url');
let queryParams = new urlModule.URLSearchParams('id=abc123');
console.log(queryParams.get('id'));
The second method works for hardcoded strings, but I can’t figure out how to actually retrieve the current page URL to pass into URLSearchParams. The iframe setup seems to prevent standard browser JavaScript from working as expected.
Has anyone successfully accessed URL parameters within N8N custom nodes? What’s the proper way to get the current URL in this environment?
Yeah, iframe sandboxing is blocking your browser API access. I found a workaround on a recent project using N8N’s environment variables. You can set up your parent app to dynamically update N8N’s env vars with current URL params before the workflow runs. Takes a quick API call to N8N’s config endpoint, but then your custom nodes can grab those params via process.env without iframe issues. There’s a bit more latency, but it keeps your app and workflow logic separate. Another option that worked well - use N8N’s HTTP Request node at workflow start to call back to your parent app and grab the current URL state. You’ll need to expose an endpoint in your main app though.
I faced a similar challenge while creating N8N workflows that required access to the page context. The key point to remember is that custom nodes in N8N execute server-side and do not have access to browser-specific objects like the window object. One effective solution is to extract URL parameters in your main application using standard JavaScript before triggering the N8N workflow. You can use URLSearchParams to obtain the parameters you need, then pass this data to N8N through a webhook or as part of the manual trigger data. This approach helps avoid difficulties associated with iframes.
N8N custom nodes can’t access the parent page’s URL because they run in a sandboxed iframe on the server side - no browser APIs available. Here’s what works: Set up a two-step parameter system. Grab the URL parameters in your parent app with new URLSearchParams(window.location.search), then use postMessage to send them to the N8N iframe. Configure your N8N workflow’s initial trigger to accept these parameters as input. Now you’ve got URL parameters available throughout the entire workflow without needing browser access in the custom nodes. I’ve used this approach in several production setups where URL state needed to control N8N workflow behavior - works reliably.
Yeah, iframes make this a pain because of cross-origin restrictions and N8N’s server-side limitations.
I fixed this by building an automation bridge that grabs URL parameters from the parent page and pushes them into the workflow. Don’t try accessing browser objects directly from N8N nodes - it won’t work.
Set up message passing between your main app and the iframe. Your main app pulls the URL parameters with regular JavaScript, then sends that data to the iframe where N8N can pick it up as workflow input.
Honestly though, dealing with iframe communications and N8N’s limitations gets messy quick. You’ll write tons of custom code just to move basic data around.
I switched to Latenode for this stuff because it handles browser context and URL parameter extraction out of the box. You can directly grab current page URLs and query parameters without iframe headaches or complex message passing.
Latenode’s automation flows can pull URL parameters, process them, and trigger actions in one clean workflow. No server-side restrictions or iframe nonsense to deal with.
just use n8n’s webhook trigger - skip the custom nodes. when the parent page loads, grab the url params with window.location.search and post them straight to the webhook. way cleaner than dealing with iframe messaging, plus you get the params directly in your workflow from the get-go.