A developer signs up at the LinkedIn Developer Portal, creates an app, copies the client ID and secret, and expects the same experience every other platform offers: generate a key, call an endpoint, ship.
Then the OAuth dialog refuses the scopes. The endpoint returns nothing useful. And there is no billing page to upgrade, no button that unlocks it. LinkedIn is not a key you generate — it is a set of Products you request, an app someone else has to verify, and for the valuable APIs, a review of your company before a single call is allowed.
Almost nothing is self-serve
LinkedIn is unusually blunt about this on its own access page, and it is worth reading before any architecture is committed to:
The Open Permissions list is short enough to memorise. It is the whole of what a developer can reach without asking anyone:
| Product | Permission | What it gives you |
|---|---|---|
| Sign in with LinkedIn (OpenID Connect) | profile | Authenticated member’s name, headline and photo |
| Sign in with LinkedIn (OpenID Connect) | email | Authenticated member’s primary email address |
| Share on LinkedIn | w_member_social | Post, comment and like on behalf of the member |
That is the entire self-serve surface. Anything touching an organisation Page, ad account, lead form, event, conversion or analytics sits behind a Product request that a human at LinkedIn decides on. Product roadmaps written on the assumption that “we will just call the API” usually discover this at integration time rather than planning time.
Gate one: your app has to be claimed by a Page
This is the requirement that stops more projects than any other, because it is not a technical task and it is not owned by the developer.
The developer app must be associated with a real LinkedIn company Page, and the verification must be performed by a super admin of that Page. That person is frequently in marketing, sometimes an ex-employee, and occasionally nobody knows who it is because the Page was created years ago by a contractor. Where the Page super admin is unreachable or the Page itself is unclaimed, the access request cannot proceed at all — there is no alternative route and no ticket that bypasses it.
The same review also checks the organisation itself:
Legal name, registered address, website, domain and privacy policy all have to line up with each other and with the Page. Mismatches between the legal entity on the form, the domain on the website and the organisation behind the Page are a common and entirely avoidable cause of rejection. There is also a naming rule most teams have never read: the application must not include “any portion of the LinkedIn or Microsoft names or logos (e.g. Linked or In).”
Gate two: Development tier is not production
Approval does not mean access. Both the Advertising API and the Community Management API start every application in a Development tier that is deliberately too small to run a business on, and LinkedIn publishes exactly how small.
Advertising API — Development
Unlimited read on ad accounts you administer. Creation of one test ad account through the API; all real accounts must be made in Campaign Manager. Edits limited to five ad accounts.
Community Management — Development
500 API calls per app per 24 hours. 100 API calls per member per 24 hours. BATCH_GET calls not allowed at all. Social-action webhook push notifications disabled.
Those Community Management figures are the ones that catch teams out. A per-member ceiling of 100 calls a day makes a polling-based design unworkable before it ever reaches a customer, and with batch reads switched off, the obvious workaround is closed too. The integration has to be architected for the Standard tier while being built and tested under Development limits.
There is also a clock. LinkedIn states that Community Management developers “are expected to build core business use cases, using the provided permissions and APIs, within twelve (12) months of the provisioning.” Access granted early, then parked while the team works on something else, is access being spent.
Gate three: the tier upgrade is a review, not a form
Standard tier is where the restrictions lift, and reaching it means submitting the integration itself for inspection — company overview, product overview, use-case description, working test credentials, and a screencast that demonstrates every use case claimed on the form.
LinkedIn specifies what the recording has to show, and the requirements differ by use case. For a Page Management integration, for instance, the reviewer expects to watch the complete OAuth flow being approved, a post being published to a Page through the app, a member’s comment on that post appearing inside the app, and an explicit demonstration of which personal data fields from that commenter’s profile are shown to users. Brand Engagement, Page Analytics, Executive Management and Employee Advocacy each have their own script.
That last requirement is the one teams under-prepare. The review is not checking that the integration works — it is checking what member personal data the product exposes and to whom. A recording that demonstrates features without ever showing the data-handling surface answers a question nobody asked.
The rule that makes rejection expensive
Most platforms let a rejected submission be corrected and sent again. LinkedIn does not, and this single sentence should shape how a first submission is prepared:
A rejection does not cost an edit and a resubmission. It costs the app. New client ID, new client secret, new Page verification, redirect URLs updated everywhere they were configured, tokens re-issued, and any environment already wired to the old credentials rebuilt. The same rule is stated again for Standard tier: a rejected Standard request also means starting from a new app at Development tier.
This is why the economics of LinkedIn access are the opposite of most platforms. Iterating cheaply toward approval is not available. The first submission is effectively the only inexpensive one, which puts the value entirely in the preparation.
And some Products are not open at all
Advertising, Community Management, Events Management, Lead Sync and Conversions are described by LinkedIn as open to all approved developers. A second group is not.
Matched Audiences, Audience Insights, Media Planning and Company Intelligence are “available to qualified developers who meet additional criteria for access.” For Matched Audiences, Advertising API approval is an obligatory prerequisite, the request goes through a separate form, and LinkedIn states it “will contact you up to 60 days after the form submission only if we will identify meeting access criteria and a strong partnership fit.” No contact is the answer. The other restricted programs are assessed case by case with no published timeline at all.
Building a product whose core promise depends on a restricted Product is a commercial risk decision, not an engineering one, and it should be made before the roadmap is committed rather than after the ads integration ships.
How the work is sequenced
Establish who controls the Page — first, not last
Identify the Page super admin and confirm they will act. If that person cannot be found, or the Page is unclaimed or mis-named relative to the legal entity, that is the project, and everything else waits.
Map the feature set onto Products before writing code
Each endpoint belongs to a Product with its own availability, its own permissions and its own review. Discovering mid-build that a feature depends on a restricted Product is a roadmap problem with no technical fix.
Align the entity paperwork
Legal name, registered address, website domain, business email, privacy policy and Page identity must tell one consistent story. Reviewers check these against each other, and the app name must stay clear of the LinkedIn and Microsoft naming rule.
Design for Standard, build inside Development
500 calls a day per app and 100 per member, with batch reads disabled, will not support a polling architecture. Rate strategy, caching and webhook readiness are design decisions taken at the start, not optimisations added later.
Prepare the submission as a one-shot deliverable
Because rejection costs the app rather than a resubmission, the use-case descriptions, test credentials and per-use-case screencast are prepared and checked against LinkedIn’s published test cases before anything is sent. This is the part that decides the outcome.
Where LinkedIn access requests go wrong
- Nobody can verify the app. No reachable Page super admin means the request cannot be reviewed, no matter how good the integration is.
- A personal email address was used. LinkedIn states plainly that personal addresses will not pass vetting, and the business address must be verified through an email that can be lost to a spam or promotions tab.
- Entity details do not match. Legal name, domain, website and Page pointing at slightly different organisations reads as unverifiable.
- The use case is restricted. Checking the restricted-use-case list after building is checking it too late.
- The app name breaks the naming rule. Any portion of the LinkedIn or Microsoft names or logos — including fragments such as “Linked” or “In” — is called out explicitly.
- The screencast does not follow the published test cases. Each use case has a prescribed sequence, and the personal-data demonstration is the part most often missing.
- The team assumed a resubmission was possible. A rejected app cannot re-apply. Planning for iteration is planning to rebuild credentials.
- Development-tier access was left to expire. Twelve months is the stated window for Community Management integrations to be completed.
- Compliance was treated as a one-time gate. LinkedIn “retains the right to monitor your application and suspend or discontinue access … even if your application was previously approved.”
Where this sits
LinkedIn access is less a technical problem than a sequencing and evidence problem: the right Products identified before the build, an organisation that verifies cleanly, a Page admin who acts, and a submission assembled once and correctly because the platform does not offer a cheap second attempt.
If that is the work that needs doing, it is described under the LinkedIn API setup service, with scope and pricing set out separately. Where a LinkedIn integration is one platform among several inside a single product, the multi-platform approach used for tools such as Postiz covers the same ground across providers.
An honest note. LinkedIn reviews and decides every access request itself, and states that it “reserves the right to review applications and select partners at its discretion” — a developer may meet the published minimum requirements and still not be upgraded. No consultant controls that decision, and no specific outcome or timeline can be promised. What can be controlled is that the correct Products are requested, that the organisation and Page verify cleanly, that the integration is designed for the tier it will actually run on, and that the submission meets the published requirements the first time. This is review preparation and submission support, and it is not affiliated with or endorsed by LinkedIn or Microsoft.
Sources: LinkedIn — Getting Access to LinkedIn APIs (learn.microsoft.com/en-us/linkedin/shared/authentication/getting-access), Community Management App Review (learn.microsoft.com/en-us/linkedin/marketing/community-management-app-review), Increasing Access (learn.microsoft.com/en-us/linkedin/marketing/increasing-access) and LinkedIn Marketing API Program Access Tiers (learn.microsoft.com/en-us/linkedin/marketing/integrations/marketing-tiers). Reviewed August 2026 — LinkedIn’s documentation and tier limits change; verify against the current pages before acting.