Linkedin posting as oraganziation but getting non existent version error

Questions
1

my workflow generates linkedin post content which is then posted. the content is all text. i am using n8n on cloud

Describe the problem/error/question

i am the super admin of the organization to which i am posting and i am using linkedin create post node. when that post node executes it gives an error that:
Your request is invalid or could not be processed by the service
Requested version 20250401 is not active
Error code
426
Full message
{ “status”: 426, “code”: “NONEXISTENT_VERSION”, “message”: “Requested version 20250401 is not active” }
i tried the http node as well but still i get the same error. please help

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
3

That error usually points to the LinkedIn API version header, not just the organization-admin role.

I would split the check into a small evidence packet first:

1. Capture the failed execution timestamp, n8n Cloud/runtime info, operation name, and the exact response body showing `426` / `NONEXISTENT_VERSION`.

2. Check whether the native LinkedIn node is sending a stale `Linkedin-Version` value. LinkedIn’s current docs show versioned calls need an explicit `Linkedin-Version` header, and deprecated versions return this kind of 426 response.

3. Try one controlled HTTP Request probe with fake/minimal text only, not production content. Use the same author/org shape, add the currently supported LinkedIn version header from the docs, and include `X-Restli-Protocol-Version: 2.0.0` if the endpoint requires it.

4. If the HTTP probe gets past the version error but the native node does not, you have evidence for a native-node/API-version drift issue.

5. If HTTP also fails, then look next at organization URN, product/API access, scopes/permissions, and payload shape before retrying a real post.

For the workflow itself, I would add a safe fallback state:

- content generated,

- human review pending,

- LinkedIn publish attempted,

- version/permission blocked,

- manual publish needed,

- posted.

That way this does not become an invisible retry loop or silently dropped social post while the connector/version issue is being sorted out.

4

Welcome @Naimah_Rehman to our community! I’m Jay and I am a n8n verified creator.

This is a known API version drift issue with n8n’s native LinkedIn node - the node has a hardcoded LinkedIn-Version header that’s no longer active. The 426 NONEXISTENT_VERSION confirms this exactly.

The cleanest workaround right now is to bypass the native LinkedIn node and use an HTTP Request node calling the LinkedIn v2 ugcPosts API directly. Set the header LinkedIn-Version: 202504 (or the latest supported version from LinkedIn docs) and X-Restli-Protocol-Version: 2.0.0. The payload for an organization post looks like this:

{
  "author": "urn:li:organization:YOUR_ORG_ID",
  "lifecycleState": "PUBLISHED",
  "specificContent": {
    "com.linkedin.ugc.ShareContent": {
      "shareCommentary": { "text": "your post content" },
      "shareMediaCategory": "NONE"
    }
  },
  "visibility": { "com.linkedin.ugc.MemberNetworkVisibility": "PUBLIC" }
}

This will work until n8n updates the native node to support the current API version.