n8n LinkedIn Node

n8n’s built-in LinkedIn node has a single operation, Post: Create, so it publishes posts and nothing else. Invitations, messages, enrichment and people search come from community nodes, and several LinkedIn API vendors publish one for their own API, Unipile and Linked API among them. Ours is n8n-nodes-gtm-api, and n8n verified it on 7 October 2026, so it installs from the nodes panel on n8n Cloud and self-hosted alike.

The rest of this page is about that node: installing it, its one credential, its four actions and its trigger, which starts a workflow on LinkedIn events, all acting through a LinkedIn account you connect yourself. On that stack, gtm-api.com runs 20,000+ accounts with under 1% of them ever restricted.

Built-in node or community node

The built-in node is the one n8n describes in one line on its own reference page: “Use the LinkedIn node to automate work in LinkedIn, and integrate LinkedIn with other applications. n8n supports creating posts.” Creating posts is the whole surface. There is no trigger, no messaging resource and no search.

Installing the gtm-api node

n8n documents four install routes, and they are not equivalent. “There are four ways to install community nodes”, its documentation says: from the nodes panel for verified nodes only, from the GUI for anything on npm, manually from the command line, and from environment variables for a deployment pipeline. Now that the node is verified, the nodes panel is the route on any instance: search for gtm-api and install it from the node’s page. A self-hosted instance also keeps the GUI route, which is how you get a release the panel has not picked up yet.

• Settings, then Community Nodes, then Install. The flow asks for an npm package name. Enter n8n-nodes-gtm-api for the current release, or append a version such as @1.0.10 to pin one.
• Accept the risk checkbox. n8n words it as “I understand the risks of installing unverified code from a public source”, and the risks page behind it is worth reading once: a community node “has full access to the machine that n8n runs on”.
• Do it as an Owner or an Admin. n8n restricts npm installs to those two roles on self-hosted instances, so a member account will not see the button.
• Pin the version deliberately. A dist-tag such as @beta is resolved once, at install time, and does not follow later releases. A bare package name takes whatever is current on the day you install.

Two things can stop the install outright. n8n keeps a blocklist of packages it refuses, and a self-hosted instance can have community nodes switched off entirely with N8N_COMMUNITY_PACKAGES_ENABLED=false, which is a common setting on managed deployments somebody else administers.

The package itself is public and checkable before you install anything. The current release, 1.0.10, was published on 10 October 2026, carries an MIT licence, requires Node 20 or newer, and declares no runtime dependencies at all. The npm registry also serves a signed provenance attestation for it, which ties the published tarball to a GitHub Actions run on the gtm-api/n8n-nodes-gtm-api repository at tag v1.0.10. Those two properties, zero runtime dependencies and provenance from a GitHub Action, are the two hardest requirements in n8n’s own verification guidelines.

What verification changed is discovery, and it is not cosmetic. n8n’s guidelines describe the verified experience as: “Any user with verified community nodes enabled can discover and install verified nodes from n8n’s nodes panel across all deployment types (self-hosted and n8n Cloud).” No npm name to type, no risk checkbox, and Cloud included. The panel installs the version n8n reviewed, and n8n picks up new npm releases on its own schedule, so the panel can trail npm by a couple of weeks.

The credential and where it is reusable

The node ships one credential type, and n8n lists it under the display name LinkedIn API. It has a single field, an API key, stored as a password field. The node sends it as an ordinary bearer header, which is worth knowing because it means nothing about this credential is exotic.

Authorization: Bearer <your API key>
Content-Type:  application/json

base URL   https://app.gtm-api.com/linkedin/v4
trigger    https://app.gtm-api.com/orchestration/v4

The credential carries a test request, so n8n validates the key the moment you save it by asking the API for one connected account. A wrong or revoked key fails there, in the credential dialog, at save time, long before a production run depends on it. Keys come from the dashboard at app.gtm-api.com, and the free plan issues one without a card.

The reuse is the part most people miss. n8n’s HTTP Request node supports a Predefined Credential Type, and its documentation is explicit that this covers “integrations supported by n8n, including both built-in and community nodes”. Once the LinkedIn API credential exists, an HTTP Request node can select it and call any endpoint the node itself does not wrap, with no second credential and no token pasted into a header field.

The four actions

The action node presents four resources with one operation each. It is a deliberately small surface: these are the four calls an outreach workflow makes over and over, and everything rarer goes through HTTP Request on the same credential.

• Connection Request, Send. Sends the invitation to a member ID from search or enrichment, with an optional note (up to 300 characters, 200 on a sender without Premium) and a flag that sends it without the note instead of failing when the note cannot be attached.
• Message, Send. Sends a direct message, either into an existing conversation by its identifier or to a member by their member or Sales Navigator ID.
• Person, Enrich. Returns the lite profile for a person (full name, profile slug, LinkedIn IDs and connection degree), addressed by the public identifier from their profile URL or by a member ID.
• People Search, Search by URL. Takes a LinkedIn search URL that you built in the LinkedIn interface and returns one page of results, with a page parameter to walk the rest.

Every one of them starts with the same field, and the node renders it as a dropdown. Sender is populated live from the accounts on your team, so the workflow author picks a connected LinkedIn account by name and never handles an identifier. That single choice is what makes an n8n workflow multi-account: the same workflow, driven from a spreadsheet column of senders, spreads a campaign across a fleet. The arithmetic of how many accounts a target volume actually needs is on Scaling LinkedIn outreach.

The trigger node and its three events

The package’s second node is a trigger, and it does something the built-in LinkedIn node cannot do at all: it starts a workflow when something happens on LinkedIn. Three events are on the dropdown.

• Connection Request Accepted. The event most sequences are actually waiting for, and the one that makes a polling loop unnecessary.
• Message Received. An inbound reply, which is the trigger for routing a conversation into Slack, a CRM or a task queue.
• Invitation Received. Somebody has invited the connected account, which is the inbound half most outreach tooling ignores.

The registration is automatic in both directions. Activating the workflow creates the webhook subscription against the orchestration service and stores its identifier in the workflow’s own static data. Deactivating it deletes that subscription. Nothing is left behind pointing at a URL that has stopped answering, which is the usual way a stale subscription outlives the workflow that made it.

Two n8n behaviours decide whether an event ever lands. A test webhook is registered only while the editor is listening and stays active for 120 seconds, so a subscription made against the test URL works once during setup and then goes quiet. And the target has to be reachable: the platform refuses a target URL that is not public https, so a laptop instance behind a firewall needs a tunnel or a public hostname before the first event arrives.

Without the node: HTTP Request and MCP

The node is not the only way in. Two routes reach the same API without it, and the second one is the better fit if the workflow already has an AI agent in it.

The first is the HTTP Request node with the same bearer credential, which is how every one of these calls worked before the package existed and how the recipes on Automate LinkedIn with n8n are written. Nothing about that route is a downgrade in capability. It costs more nodes and more field-typing, and it reaches the whole API, well past the four operations the node wraps.

The second is the MCP Client Tool node, a cluster sub-node that hands an external MCP server’s tools to an n8n agent. It supports bearer, generic header, multiple-header and OAuth2 credentials, and its Tools to Include setting takes All, Selected or All Except, which matters because handing an agent every tool on a large server is how you burn a context window. Setup per client, and what an agent can actually do once connected, are on LinkedIn MCP server.

Whichever route you take, the pacing does not belong in n8n. Wait nodes and schedule triggers produce a fixed cadence and know nothing of the account’s budget. Per-action daily budgets and randomised spacing are enforced on the server, per connected account, so a workflow can push its whole queue and let the budget hold it back. LinkedIn’s own caps, which those budgets sit under, are on LinkedIn limits.

Frequently Asked Questions

Sources & Further Reading

• n8n, LinkedIn node reference (the single Post: Create operation, and the one-line scope quoted above), read 1 September 2026
• n8n, Community node installation (the four install routes, and the quoted statement that unverified nodes are not available on n8n Cloud), read 1 September 2026
• n8n, Installing from the GUI (the Settings route, the quoted risk checkbox, the Owner and Admin restriction, the blocklist and dist-tag behaviour), read 1 September 2026
• n8n, Risks of using community nodes (the quoted full-machine-access warning and the environment variable that disables installs), read 1 September 2026
• n8n, Community node verification guidelines (the quoted description of the verified experience, plus the zero-dependency and provenance requirements), read 1 September 2026
• n8n, HTTP Request credentials (the quoted statement that Predefined Credential Type covers community nodes), read 1 September 2026
• n8n, Webhook node in development (the 120-second test webhook window), read 1 September 2026
• n8n, MCP Client Tool node (the supported credential types and the Tools to Include setting), read 1 September 2026
• npm registry, n8n-nodes-gtm-api package metadata (version 1.0.10 published 10 October 2026, MIT, Node 20 or newer, no runtime dependencies) and its provenance attestation (the signed build on tag v1.0.10), read 23 October 2026
• n8n, community node catalog entry for n8n-nodes-gtm-api (both nodes marked verified and published on 7 October 2026), read 7 October 2026
• gtm-api.com, developer documentation (the endpoints behind the four actions and the webhook event names)
• Related: LinkedIn integrations for n8n, Zapier and Make · Automate LinkedIn with n8n · LinkedIn MCP server · LinkedIn limits · Scaling LinkedIn outreach

Michael SalamatovGTM engineerRuns the gtm-api.com blog. Covers LinkedIn limits, account health and the API side of outbound.in

Last updated: October 2026 · Definitions and benchmarks verified at time of publication