n8n LinkedIn Job Automation: Building It Without Getting Your Account Banned

A LinkedIn job automation in n8n is four nodes: a schedule trigger, something that fetches listings, a filter or scoring step, and a delivery step that puts the results somewhere you will actually read. The workflow itself takes an afternoon. What takes longer is choosing a data source that will not get your account restricted, and building it so it keeps running when you are not watching.

Those two problems are the real content here. Every tutorial shows the four nodes. Very few mention that scraping LinkedIn directly violates its terms of service and that accounts doing it get restricted, or that a workflow which fails silently every night is worse than no workflow at all.

Table of contents

• Where the data can legitimately come from
• The workflow shape
• Scoring instead of filtering
• Making it survive being ignored
• Where the workflow should run
• Keeping the credentials safe
• How this fits the rest of the stack
• FAQ

Where the data can legitimately come from

This determines everything else, so decide it first.

• LinkedIn’s official API. The legitimate route. Job search endpoints are gated behind partner programme access that individuals do not generally get, so for a personal project this is usually not available.
• A commercial data provider. Several services sell job listing data with the compliance handled on their side. You pay per request, and your account is not the one taking the risk.
• Job board RSS and public APIs. Many boards publish feeds that are explicitly meant for consumption. Less coverage than LinkedIn, zero risk, and no cost.
• Scraping LinkedIn directly. Violates the terms of service. Accounts get restricted or permanently banned, and the anti-automation measures change frequently enough that a scraper is a maintenance commitment rather than a project.

The honest recommendation for a personal job search: aggregate the public feeds first. The coverage is better than people expect, the workflow is identical, and nothing you build can cost you the account you are using to apply for jobs.

If you want LinkedIn’s coverage specifically, pay a provider. The cost is real and it is much lower than the cost of losing your profile mid-search.

The workflow shape

Whatever the source, the structure is the same:

1. Schedule Trigger — once or twice a day. Job listings do not change fast enough to justify more, and every run costs API calls.
2. HTTP Request — fetch from your chosen source, with the search parameters as query values.
3. Code or Filter — deduplicate against what you have already seen, then score or filter what remains.
4. Delivery — append to a sheet, send an email digest, or post to a chat channel.

The deduplication step is the one people skip and immediately regret. Without it you get the same twenty listings every morning and stop reading the digest within a week, which defeats the entire purpose.

Deduplicating needs somewhere to remember what you have seen. n8n’s static data works for small volumes; a database table is better once you are storing more than a few hundred rows, and it also lets you query your own history later.

Scoring instead of filtering

A hard filter on keywords throws away things you would have wanted. Scoring keeps everything and orders it, which works much better in practice.

A simple scoring function in a Code node:

const wanted = ['typescript', 'postgres', 'remote'];
const unwanted = ['on-site', 'clearance required'];

return items.map(item => {
  const text = (item.json.title + ' ' + item.json.description).toLowerCase();
  let score = 0;
  for (const w of wanted)   if (text.includes(w)) score += 2;
  for (const u of unwanted) if (text.includes(u)) score -= 3;
  return { json: { ...item.json, score } };
}).sort((a, b) => b.json.score - a.json.score);

Crude, and it works. The digest arrives ordered by relevance and you read from the top until it stops being interesting.

An LLM node can do the scoring instead, comparing each listing against your CV and producing a rating with a reason. That is genuinely better at judging fit, and it costs money per listing and introduces a dependency that can fail or change. Start with the keyword version; move to the model when the keyword version’s mistakes annoy you.

Making it survive being ignored

An automation you check daily is a script. An automation you forget about is only useful if it fails loudly, and the default failure mode is silence.

Four things that make the difference:

• An error workflow. n8n lets you designate a workflow that runs when another fails. Have it message you. Without this, a broken workflow just stops producing output and you assume there were no jobs.
• Retries on the HTTP node. Transient failures are common. Two or three retries with a delay removes most of them.
• A heartbeat. Send yourself a message even on days with no new listings — a digest saying nothing new today is proof the workflow ran. No message is ambiguous.
• Credential expiry awareness. API keys and tokens expire. When the workflow starts failing three months in, this is usually why.

The heartbeat is the one people leave out and it is the one that catches the most. Absence of output and absence of results look identical from the outside.

Where the workflow should run

The workflow needs to execute on a schedule, which means something running continuously. Three options with real trade-offs:

• Locally on your machine. Free, and it only runs when your laptop is awake and connected. Fine for testing, unreliable as a daily job.
• n8n’s hosted cloud. No infrastructure to manage, priced per execution.
• Self-hosted on a server. Full control, and you own the upgrades, TLS certificates, backups, and the Postgres instance n8n stores its data in.

The self-hosting option is where the effort is underestimated. n8n itself installs easily. What accumulates is everything around it — keeping it updated, renewing certificates, and backing up the database that holds your workflows and credentials. Losing that database means losing every workflow you built.

For reference on the managed-but-not-hosted-cloud middle ground: n8n is available as a managed tool on RunxBuild, deployed with its own plan, custom domain, environment variables, and logs, with a managed Postgres alongside it. A small instance runs on the $6 Basic plan and the database sits on the same ladder. That removes the upgrade and certificate work while keeping it your instance.

Whichever you pick, the thing to be deliberate about is the database. Workflow definitions and credentials live there, and a workflow you cannot restore is a workflow you will rebuild from memory.

Keeping the credentials safe

This workflow holds API keys and possibly an email or chat token. Two rules worth following even for a personal project:

1. Use n8n’s credential store, not hardcoded values in Code nodes. Credentials are encrypted at rest and are excluded when you export a workflow, so sharing a workflow JSON does not leak them. A key pasted into a Code node is included in every export.
2. Scope keys to the minimum they need. A data provider key that can only read listings is a much smaller problem if it leaks than one that can also manage your account.

The export point is the practical one. People share workflow JSON to get help with it, and a hardcoded key in a Code node goes with it into a forum post.

How this fits the rest of the stack

The gap between a workflow that works when you run it and one that runs unattended for six months is almost entirely operational — error handling, credential expiry, and where the state lives. Self-hosting n8n gives you full control of that and also gives you the upgrades, certificates, and database backups to own. Running it as a managed tool on RunxBuild keeps it your instance with your workflows and puts a managed Postgres beside it from the same $6 Basic plan, so the database holding your workflow definitions is backed up rather than assumed. If you are sizing that pair, the RunxBuild hosting calculator shows the tool and the database as separate line items, and Databases on RunxBuild covers what the managed side includes.

Useful related references:

• What Is a Cloud Engineer, Really? (Not the LinkedIn Version)
• Railway n8n: What to Check Before You Self-Host Workflow Automation
• n8n Puppeteer Node: How to Self-Host Browser Automation on a PaaS Without It Eating the Host
• Builds on RunxBuild

FAQ

Is scraping LinkedIn with n8n allowed?

No. It violates LinkedIn’s terms of service, and accounts doing it are restricted or banned. Use the official API if you have partner access, a commercial data provider, or public job board feeds instead.

How often should the workflow run?

Once or twice a day is plenty. Job listings do not change fast enough to justify more frequent polling, and every run consumes API quota or provider credits for very little additional coverage.

Why do I get the same jobs every day?

There is no deduplication step. Store the identifiers you have already delivered — in n8n static data for small volumes, or a database table beyond a few hundred rows — and filter against them before delivery.

How do I know if the workflow silently stopped?

Add a heartbeat that messages you even on days with no new listings, and configure an error workflow that notifies you on failure. Without both, no output and no results look identical.

Where should n8n run for a scheduled workflow?

Somewhere always on. A local machine only runs when it is awake. Hosted cloud or a managed deployment removes the upgrade and certificate work; self-hosting gives full control but makes backing up the n8n database your responsibility.