Lead Generation
Lead generation with n8n and Python: what I actually build
"Lead generation automation" gets used to describe everything from a paid list-selling tool to a fully custom pipeline built around one business's actual criteria. What I build is the second kind, and it's almost always two connected pieces rather than one: a Python scraper and an n8n workflow, each doing the part it's actually good at.
What "lead generation automation" actually means here
The problem this replaces is almost always the same one: someone on the team spending hours a week manually searching, copying details into a spreadsheet, and cleaning up the result before it's usable for outreach. That's hours that could go toward actually contacting prospects, not compiling the list of who to contact.
It's not about finding leads that couldn't be found by hand. It's about not paying a person's time to do a research task a script can do faster and more consistently.
The system: a Python scraper feeding an n8n workflow
The lead generation system I've built runs as two connected pieces. A Python script does the actual scraping — finding and extracting the raw lead data from the source — and an n8n workflow picks up what the scraper produces, structures it, and delivers it in a format that's ready to use.
Splitting it this way isn't an aesthetic choice. Scraping is the part of this job that benefits from real code: handling pagination, working around inconsistent page structures, retrying failed requests, and cleaning fields that don't come back in a consistent shape. Once that raw data exists, n8n is the better fit for the rest — routing it, transforming it into the destination format, and delivering it on a schedule without me maintaining a second piece of infrastructure just to run a cron job.
Why the scraper is Python and not an n8n HTTP node
n8n can make HTTP requests and parse basic responses, and for a simple, well-structured source that's sometimes enough. It stops being enough the moment the source has pagination that isn't predictable, rate limits that need real backoff logic, or a page structure that varies enough that simple selectors break. Python's scraping libraries are built for exactly that, and debugging scraping logic in a real language, with real error messages, is faster than debugging it inside a workflow canvas.
The tradeoff is real, though: a Python scraper is a second thing to host and maintain, which is why it only makes sense once the source is genuinely too irregular for n8n alone. For a client with one clean, cooperative data source, I'd recommend staying inside n8n rather than adding a scraper that doesn't need to exist yet.
What "ready to use" actually requires
A list of names and emails isn't a finished lead generation system — it's raw material. The n8n side of this workflow is what turns that raw material into something a sales team can actually act on: deduplicated, structured into consistent fields, and delivered wherever the team already works, rather than as one more spreadsheet they have to remember to check.
That last step matters more than it sounds. An automation that produces a perfect list nobody looks at hasn't actually saved anyone the hours it was built to save. The workflow is only finished when the output lands somewhere the business already checks, in a shape it can use without another manual cleanup pass.