Table of Contents
- 1. Why the official LinkedIn API cannot do what you want
- 2. What "unofficial" actually means
- 3. What you can build with it
- 4. The risks, and what actually mitigates them
- 4.1. Rate limits and pacing
- 4.2. Session and IP consistency
- 4.3. Failing closed
- 4.4. Breakage
- 4.5. Where the limits live
- 5. API or MCP: which one do you want?
- 6. Frequently asked questions
- 6.1. Is there an unofficial LinkedIn API?
- 6.2. What can the official LinkedIn API not do?
- 6.3. Do I need Partner Program approval for an unofficial API?
- 6.4. Can my LinkedIn account get restricted?
- 6.5. Should I build my own or use a provider?
- 6.6. Does the same apply to X (Twitter)?
Short on time? LinkedIn's official API cannot do most of what people want from it. Searching the feed, reading who engaged with a post, commenting as yourself, sending invites and DMs: none of that is available, and the parts that exist sit behind Partner Program approval with narrow enterprise scopes. An unofficial LinkedIn API works differently. It authenticates your own account and acts as you, which is why it can do broadly anything a person can do on linkedin.com. That power comes with real account risk, and the only thing that makes it survivable is where the rate limits live. Commentify exposes this as an unofficial LinkedIn and X API, and an MCP server for AI agents.
Almost everyone arrives here the same way. You have an idea that needs LinkedIn data or LinkedIn actions, you go looking for the API, you read the documentation, and you slowly realise the thing you want to build is not on the menu. Then you find out you also need to apply for approval to use the parts that are.
Here is the honest picture of what exists, what "unofficial" really means, and how to use one without losing an account.
Why the official LinkedIn API cannot do what you want
LinkedIn's public platform is deliberately narrow. Access runs through the Partner Program, approval is selective and use-case-specific, and the products on offer are built for large integrations rather than individual accounts: advertising and campaign metrics, publishing to a company page, applicant tracking, and limited sign-in and profile scopes.
What is not available, in any generally accessible form:
- Searching the feed or posts by keyword or hashtag
- Reading the people who liked or commented on a post
- Commenting or reacting as yourself
- Sending connection invitations
- Reading or sending direct messages
- Acting as a personal profile at all, rather than a company page
That list is most of what growth, sales, and research tooling needs. Which is why an entire category of products exists that quietly does not use the official API.
What "unofficial" actually means
An unofficial API does not get privileged access. It authenticates your account, using your own session, and then calls the same internal endpoints that linkedin.com calls when you click things. Your agent or script is, from LinkedIn's perspective, you.
Two consequences follow, and they are the whole story:
- The scope is enormous. If you can do it in the browser, it can be done through the API. No approval, no scope negotiation, no company-page-only restriction.
- The account is yours to lose. You are operating inside a normal account's limits, and LinkedIn is actively looking for automation that does not behave like a person.
Anyone telling you only the first half is selling you something.
What you can build with it
The realistic capability surface, and the kinds of products people build on each:
| Capability | Typical use |
|---|---|
| Post and keyword search | Social listening, intent signals, content research |
| Reactors and commenters on a post | Lead sourcing from competitor and event posts |
| Profile and company enrichment | CRM enrichment, ICP scoring, ATS candidate data |
| Comment and react | Engagement-led growth, social selling |
| Publish posts and carousels | Scheduling tools, content distribution |
| Invites and direct messages | Sales engagement, recruiting outreach |
| Inbox and reply detection | Sequence stop conditions, AI SDR follow-up |
The pattern in nearly every successful product here is combining several of these. Sourcing without reply detection produces sequences that keep messaging people who already answered. Publishing without engagement data produces content nobody sees.
The risks, and what actually mitigates them
Restrictions are the real constraint, not endpoints. What gets accounts limited is rarely a single forbidden call. It is volume, rhythm, and inconsistency.
Rate limits and pacing
LinkedIn's ceilings are not published, they vary by account age and history, and they are lower than most people assume, especially for invites and messages. Sustainable use means per-account daily caps, randomised gaps between actions rather than fixed intervals, and activity that stays inside plausible working hours. Bursting sixty comments in ten minutes is the fastest way to get flagged. We covered the practical numbers in the LinkedIn comment frequency limit.
Session and IP consistency
An account that logs in from Berlin on a laptop and then makes API calls from a datacentre in Virginia looks exactly like a compromised account. A sticky residential IP that geographically matches the user, with a consistent device fingerprint, matters as much as request volume.
Failing closed
When LinkedIn does signal a restriction, the only correct response is to stop that account immediately rather than retry. A circuit breaker that freezes activity on the first warning is the difference between a temporary limit and a permanent one.
Breakage
Internal endpoints change without notice, and unofficial integrations do break. What matters is whether someone is monitoring for it and shipping fixes, or whether you find out from a customer. This is the strongest argument for buying rather than building: not that the calls are hard, but that maintaining them forever is.
Where the limits live
If you take one thing from this: rate limits belong below the API, enforced server-side per connected account. Limits that live in your application code, or worse in a prompt you hand to a language model, are advisory. Under load or under an over-eager agent, advisory limits are the same as no limits.
API or MCP: which one do you want?
Both surfaces expose the same capabilities, and the right choice depends on who is calling.
- Choose the REST API if you are embedding LinkedIn into your own product, need webhooks for inbound events, and want to control retries, storage, and user experience yourself.
- Choose MCP if you want an AI assistant to do the work directly. You connect Claude, Cursor, or ChatGPT once and then just ask, with no integration code at all. Our guide to the LinkedIn MCP server covers that path, including the important catch that MCP alone cannot run scheduled work.
Frequently asked questions
Is there an unofficial LinkedIn API?
Yes. Unofficial APIs authenticate your own LinkedIn account and call the same internal endpoints the website uses, which lets them cover actions the official API does not expose, such as post search, engagement data, commenting, invites, and messaging.
What can the official LinkedIn API not do?
It has no generally available way to search the feed, read who reacted to or commented on a post, comment as your personal profile, send connection invitations, or read and send direct messages. Its products focus on advertising metrics, company page publishing, recruiting integrations, and sign-in.
Do I need Partner Program approval for an unofficial API?
No. Approval applies to LinkedIn's official products. An unofficial API acts as your own authenticated account, which is why it needs no approval and is also why per-account safety limits matter so much.
Can my LinkedIn account get restricted?
Yes, and that is the real risk to manage. Restrictions come from volume, unnatural timing, and inconsistent locations rather than from specific endpoints. Daily caps, randomised pacing, working hours, a matching residential IP, and stopping instantly on the first warning are what keep accounts healthy.
Should I build my own or use a provider?
Building the first calls is straightforward. Keeping them working is not, because internal endpoints change without notice and each break is a production incident. If LinkedIn access is not your core product, a maintained provider is usually cheaper than owning the breakage.
Does the same apply to X (Twitter)?
The structure is the same, and X's official API is metered and expensive at useful volumes, which we broke down in the unofficial X API guide. Commentify covers LinkedIn and X through one connection, so you are not maintaining two unrelated integrations and two sets of limits.
The bottom line: the unofficial LinkedIn API is the only realistic way to build anything that behaves like a person on LinkedIn, and the entire engineering problem is safety rather than access. Get the limits, pacing, and breakage handling right and it is dependable. See the capability list and pricing.
