Hi, I’m having a problem with my n8n installation for LinkedIn posts. I’ll tell you right away that until yesterday there were no problems.
Today, however, the post isn’t working, and I get this message:
Your request is invalid or could not be processed by the service
Requested version 20250401 is not active
I tried reconnecting my LinkedIn account, but nothing changed.
I’m using Version 1.123.9
Thanks. your n8n setup
n8n version: community 1.123.9
Database (default: SQLite): sqlite
n8n EXECUTIONS_PROCESS setting (default: own, main): own
Running n8n via (Docker, npm, n8n cloud, desktop app): npm
This is a classic API deprecation issue. LinkedIn routinely sunsets older versions of their API, and it looks like they just pulled the plug on the 20250401 version today. That is exactly why your workflow ran perfectly yesterday but is throwing this specific error today — LinkedIn flipped the switch on their end.
Since the built-in LinkedIn node has that API version hardcoded into its requests, you have two ways to fix this:
1. Update your n8n instance The n8n team is usually incredibly fast at pushing hotfixes for these LinkedIn version bumps. Check if there is a newer npm release available beyond 1.123.9 and update your instance. A simple update usually contains the newly mapped API version.
2. The HTTP Request workaround (If no patch is out yet) If you can’t wait for a patch, you can bypass the built-in node completely. Just replace it with an HTTP Request node.
Set the authentication to use your existing predefined LinkedIn OAuth2 credential.
Point it to the LinkedIn posts API endpoint.
In the Headers section of the HTTP node, manually add LinkedIn-Version and set it to a currently active version (check LinkedIn’s API docs for the latest stable YYYYMMDD format).
This will get your posts flowing again immediately while waiting for the official node update.
I suggest update n8n to the lastest version stable and recreate the linkedin node.
If you need an immediate workaround , publish via http request using an active linkedin-version header. If reconnecting doesn’t fix it, it means the problem lies with the version header sent by the node itself, not the token.
yeah, unfortunately regressions happen in the newer minor versions sometimes. falling back to the raw http request node is definitely the safest play here until they patch the dedicated node. let me know if you need help formatting the headers or payload for the http call!
@Michel_Morelli in your HTTP Request node set a header Linkedin-Version with value 202604 (the latest active one), LinkedIn sunset 202504 on April 7th so any version from 202505 up to 202604 will work. the built-in node hardcodes the old value so updating n8n alone won’t help until they push a patch for it
Spot on. I actually default to the raw HTTP Request node for most major APIs anyway. Native nodes are great for quick setups, but the HTTP node gives you absolute control over the exact payload and, more importantly, the error handling.
The only caveat for anyone implementing this exact setup: watch out for token rotation. Since you are handling the ACCESS_TOKEN directly in the header, you’ll want to ensure you have a fallback or an error trigger catching any 401 Unauthorized responses. When that token inevitably expires, you want it to fail loudly so you can refresh it, rather than just silently dropping scheduled posts.
Option — Fast + reliable (recommended)