LinkedIn API 422 Unprocessable Entity
What a 422 response from the LinkedIn API usually indicates about your request body, and how to debug it.
By André LugA LinkedIn API 422 means your request body parsed fine but failed semantic validation — unlike a 400, which means the request could not be read at all. On the Posts API the usual triggers are an author URN that does not match the token, an unrecognized visibility value, a media asset URN in the wrong state, or a field name from a different LinkedIn-Version.
A 422 is a different kind of failure than a 400. LinkedIn parsed your request body successfully — the JSON is well-formed, the required fields are all present, the content type is correct — and rejected it anyway, because something inside that valid structure doesn't hold up semantically. Where a 400 means "this isn't a request I can even read," a 422 means "I read this fine, and it doesn't make sense." The fix for a 400 is almost always a syntax change; the fix for a 422 is a change to what value you're actually sending.
PostGate handles OAuth, publishing and delivery evidence for every network through one API. Start free or read the docs.
What usually triggers it on the LinkedIn Posts API?
- An author URN that doesn't match the token. The
authorfield must be the URN of the exact member or organization the access token is authorized to post as — a mismatched URN (wrong member ID, or a personal URN used where an organization URN is required) is semantically invalid even though it's syntactically a valid URN string. - A visibility value the API doesn't recognize for that endpoint. LinkedIn's post visibility enum is specific (
PUBLIC,CONNECTIONS, and a small set of others depending on the product); a typo'd or unsupported value passes JSON validation but fails LinkedIn's own schema check. - A media asset reference in the wrong state. Posting an image or video requires uploading it first and referencing the resulting asset URN in the post body. An asset URN that's still processing, already expired, or belongs to a different member than the
authoris a valid-looking field pointing at an invalid target. - A field that exists in an older API version but was renamed or restructured. LinkedIn versions its APIs by date header, and the shape of the Posts body has changed across versions — sending a field name from an older or newer version than the one declared in
LinkedIn-Versioncan pass JSON parsing and still fail semantic validation.
How do you debug a 422 methodically?
Read the response body first — LinkedIn's error payload (message, serviceErrorCode, status) usually names the offending field or value directly rather than leaving you to guess. Cross-check that field against LinkedIn's current Posts API schema for the exact LinkedIn-Version header your request declared, since the same field can mean something different — or not exist at all — one version apart. Then verify the value itself resolves: an author or media URN that's syntactically correct but references something the token can't act on is the single most common root cause in practice.
{
"message": "Field 'author' has invalid value 'urn:li:person:XXXXXX'",
"serviceErrorCode": 422,
"status": 422
}How does PostGate avoid most of this by construction?
PostGate resolves the correct author URN itself from the connected profile ID rather than accepting it as a raw field, so a mismatched author URN is not something an integration using PostGate's Posts API can construct. Media assets are uploaded and confirmed ready before PostGate references them in the post body — see the media lifecycle — which rules out the asset-state cause above. What can still reach you is a genuinely invalid options.linkedin field on the unified request; PostGate returns that as a structured validation_error, not a raw LinkedIn 422, with the specific field named. See Errors & retries.
Frequently asked questions
What is the difference between a 400 and a 422 from the LinkedIn API?
A 400 means LinkedIn could not even read the request — malformed JSON, wrong content type, missing required structure. A 422 means the request parsed successfully and was rejected anyway because something inside the valid structure does not hold up semantically. The fix for a 400 is almost always a syntax change; the fix for a 422 is changing the actual value you are sending.
Why does LinkedIn return a 422 for my author URN?
The author field must be the URN of the exact member or organization the access token is authorized to post as. A mismatched URN — the wrong member ID, or a personal URN used where an organization URN is required — is semantically invalid even though it is a syntactically valid URN string. In practice this author/token mismatch is the single most common 422 root cause.
Can the LinkedIn-Version header cause a 422 error?
Yes. LinkedIn versions its APIs by date header, and the shape of the Posts body has changed across versions. Sending a field name from an older or newer version than the one declared in your LinkedIn-Version header can pass JSON parsing and still fail semantic validation — the same field can mean something different, or not exist at all, one version apart.
How do I debug a LinkedIn 422 methodically?
Read the response body first — LinkedIn's error payload (message, serviceErrorCode, status) usually names the offending field or value directly. Cross-check that field against the current Posts API schema for the exact LinkedIn-Version your request declared. Then verify the value itself resolves: an author or media URN that is syntactically correct but references something the token cannot act on is the most common culprit.
