"w_member_social scope not granted": what to check
Why a LinkedIn connection can succeed but still be missing the w_member_social scope needed to post, and how to fix the request that asks for it.
By André LugA LinkedIn token can be valid yet unable to post because w_member_social was never granted — LinkedIn only grants the scopes your OAuth request asked for. Fix: add the 'Share on LinkedIn' product in the Developer Portal, include w_member_social in the authorization URL's scope parameter, use an interactive consent screen, and have previously connected members reconnect once.
w_member_social is the LinkedIn scope that lets an app post, comment, and like on behalf of the authenticated member — it comes from LinkedIn's self-serve "Share on LinkedIn" product, not a manually reviewed partner tier. A connection can complete successfully, return a valid access token, and still be missing this scope, because LinkedIn only ever grants the scopes your OAuth request actually asked for — a successful login says nothing about which scopes came with it.
PostGate handles OAuth, publishing and delivery evidence for every network through one API. Start free or read the docs.
Why can the connection "succeed" without it?
OAuth doesn't fail loudly when a scope is simply absent from the request — it just doesn't grant it, and returns a token scoped to whatever was actually requested. Three request-side causes produce this most often: the "Share on LinkedIn" product was never added to the app in the Developer Portal (so the scope isn't requestable at all, even if your code asks for it); the authorization URL's scope parameter was built without w_member_social in it, often because it only carries identity scopes like openid profile; or the member connected before the app added this scope to its request, and has not been asked to reconnect since — their existing token is frozen at whatever scope set it was issued with.
How do you confirm this is actually the cause?
Decode the access token or inspect the scope your OAuth client stored alongside it — most LinkedIn client libraries surface the granted scope list from the token response. If w_member_social is absent there, that's confirmed, and no amount of retrying the post request will fix it; the token itself was never scoped for it. This is distinct from a 403 caused by an app-level or entity-level problem — here the token is valid and the app has the right product, but this specific grant is narrower than the app's own configuration allows.
What is the fix?
- Confirm "Share on LinkedIn" is added and active on the app in the Developer Portal — this is the product that makes
w_member_socialrequestable at all. - Add
w_member_socialto the authorization URL'sscopeparameter alongside whatever identity scopes you already request. - Send the member through an interactive consent screen, not a silent one — see the related prompt=none failure mode if the request is built with
prompt=none, since that will fail the same way a missing scope does for any member connecting or upgrading for the first time. - Any member who connected before the fix needs to reconnect once through the updated consent screen — their existing token does not retroactively gain the scope.
GET https://www.linkedin.com/oauth/v2/authorization
?client_id=...
&redirect_uri=...
&response_type=code
&state=...
&scope=openid%20profile%20w_member_socialHow does PostGate avoid this?
PostGate requests openid profile w_member_social together on every LinkedIn connection, through an interactive consent screen, so a member connected through PostGate is never left with a token that can identify them but can't post. See LinkedIn API permissions for the full scope breakdown, including where the much heavier Company Page tier diverges from this one.
Frequently asked questions
Why does my LinkedIn token log the user in but fail to post?
Because OAuth doesn’t fail loudly when a scope is absent from the request — it returns a token scoped to whatever was actually requested. The three most common causes: the "Share on LinkedIn" product was never added to the app in the Developer Portal, the authorization URL’s scope parameter only carries identity scopes like openid profile, or the member connected before the app added w_member_social and has not reconnected since.
How do I check which scopes my LinkedIn access token was granted?
Decode the access token or inspect the scope your OAuth client stored alongside it — most LinkedIn client libraries surface the granted scope list from the token response. If w_member_social is absent there, that confirms the cause, and no amount of retrying the post request will fix it: the token itself was never scoped for posting.
Do existing LinkedIn connections gain a scope after I update my OAuth request?
No. A member’s existing token is frozen at whatever scope set it was issued with — it does not retroactively gain w_member_social when you fix your app’s configuration. Any member who connected before the fix needs to reconnect once through the updated interactive consent screen.
Do I need LinkedIn partner approval to get w_member_social?
No. w_member_social comes from LinkedIn’s self-serve "Share on LinkedIn" product, not a manually reviewed partner tier. You add the product to your app in the Developer Portal, which makes the scope requestable, then include it in your authorization request. The much heavier Company Page tier is a separate, different track.
Can a prompt=none authorization request grant w_member_social?
Not for a member connecting or upgrading scopes for the first time — a silent prompt=none request fails the same way a missing scope does. Send the member through an interactive consent screen instead, requesting openid profile w_member_social together, so the token that comes back can both identify the member and post.
