If you've tried to build something on top of LinkedIn, you already know the pain. You want to pull profile data, send messages, or trigger actions from your own app.

So you go looking for "the LinkedIn API." Most people end up more confused than when they started.

I get asked about this a lot, especially by GTM engineers building their own outreach stacks. So let me walk you through how this actually works in 2026, without the fluff.

TL;DR

LinkedIn's official API is real, but it's narrow and slow to get approved for. Most developers end up using infrastructure APIs like Unipile instead.

These connect to LinkedIn through your own session rather than through a partner deal. There are three legal categories that matter here, and most tools quietly fall into the risky one.

AI agents and MCP servers add a new twist this year, but they don't actually change the underlying rules. I'll break all of this down, and show where SalesRobot's own API fits if you'd rather not build the compliance layer yourself.

Why Isn't the Official LinkedIn API Enough?

Let's start with the obvious question. Why can't you just use LinkedIn's own API and call it a day?

LinkedIn's developer program is split into five tiers, and each one gives you access to something different. There's a free Consumer tier, but it only covers login and basic profile data.

Share on LinkedIn is also free, and it lets you publish posts on someone's behalf. Then things get harder.

The Marketing Developer Platform covers ads and analytics, but you have to apply and get approved as a partner first. Talent and Learning APIs are locked to enterprise partnerships.

And the Sales Navigator API is closed to new partners entirely right now. The Marketing Developer Platform is the one most developers actually want, since it's the closest thing to general purpose access.

Getting into it is not fast though. Approval is manual, and LinkedIn doesn't publish a timeline.

Realistically you're looking at four weeks if you're lucky and up to four months if you're not. Rejections happen often, and LinkedIn rarely explains why.

So if your plan was "I'll just build on the official API," you probably need a backup plan. Most GTM engineers do.

What Do Developers Actually Build On Instead?

This is where things get interesting, and where most real outreach tools actually live. There's a category of products built specifically for developers who need LinkedIn connectivity without waiting months for partner approval, since the Sales Navigator API route is closed off to most of them anyway.

Unipile is probably the best known example. These tools aren't outreach platforms themselves.

They're infrastructure, more like the plumbing that sits between your app and LinkedIn's messaging, connections, and inbox. Here's a fact that tells you everything you need to know about this space.

Companies like Lemlist and Artisan don't build their own LinkedIn integrations. They use Unipile underneath, because it's the layer other SaaS companies pay for so they don't have to build it themselves.

Pricing for tools like this usually starts small, often under 50 euros a month for a handful of connected accounts. It scales per seat as you grow.

That works well if you're a small engineering team building a product. It's a different world from a sales team just running campaigns.

But before you pick any of these, there's a distinction that matters a lot more than most people realize.

Is LinkedIn Automation Actually Allowed?

Most articles treat this as one simple yes or no question, and that's why they get it wrong. There are really three separate categories here, and LinkedIn treats each one very differently.

The first is acting on your own content through an approved API. You granted the permission yourself through LinkedIn's normal login flow, and this is completely fine.

LinkedIn even built a specific permission for exactly this. The second is automating your own session.

This means software that holds onto your login cookie or drives a browser to click around as if it were you. This is the one LinkedIn explicitly bans in its user agreement.

The third is data extraction about other people, things like scraping profiles or exporting engagement lists into a database you keep. This is also prohibited, and it's separately restricted even for developers who do have official access.

Here's the part that surprises people. Most open source LinkedIn tools, including a lot of the new AI agent tools floating around, fall into that second risky category.

They ask you to paste in your session cookie, simply because there's no public API that does what they're trying to build. That's not because these builders are trying to break rules on purpose.

It's that the official API doesn't expose the features people actually want. So the cookie becomes the only path available, even though it carries real account risk.

Before you plug any tool into your LinkedIn account, check whether it logs in through OAuth or asks for your session cookie. That one detail tells you exactly which category you're in.

What Actually Gets an Account Restricted?

I want to be straight about this part because a lot of posts on this topic dance around it. LinkedIn's rules cover more than scraping.

They also cover bots sending connection requests, automated commenting, and coordinated engagement between accounts. Restrictions tend to follow a pattern.

High volume automated connection requests, a high rate of people ignoring or reporting them, and browser extensions that automate clicks on your behalf are the usual suspects. What doesn't seem to trigger anything, based on what LinkedIn actually publishes, is using a scheduler, drafting with AI, or publishing through an app you personally authorized.

So the line isn't really "automation bad, manual good." It's closer to "acting through your own permissions is fine, acting by impersonating your login is not."

A handful of well known scraping and automation tools have actually been removed from LinkedIn's platform over the past year for exactly this reason. That should tell you this isn't just a theoretical risk.

Does MCP and AI Agent Access Change Anything?

This is the part that's genuinely new, and honestly the reason GTM engineers are asking about this topic in the first place. MCP, short for Model Context Protocol, is the standard that lets AI assistants like Claude connect to outside tools and services.

A lot of people assumed this would somehow rewrite the rules around LinkedIn automation. It doesn't.

MCP is just a wrapper. 

It's a standardized way for an AI to call a tool.

What actually matters is what sits behind that wrapper, an approved API or your browser session pretending to be you. Most LinkedIn MCP servers being built right now still rely on that session cookie, for the same reason as before.

There's no public API for reading someone's profile or their post history. So builders reach for the cookie because it's the only thing that works.

There's also a risk here that nobody was really talking about before AI agents showed up. 

If you give an assistant the ability to publish on your behalf, and it reads content from somewhere untrusted, like a pasted email or a scraped webpage, there's a real chance that content could contain hidden instructions meant to trick the AI.

If nothing stands between the AI's decision and the actual publish action, you could end up with something posted under your name that you never approved. The fix is simple in theory.

Any tool that lets an AI publish something should show you the exact final text and destination first, and require a fresh confirmation before it goes live. If a tool skips that step, I'd treat it as a red flag.

This is actually why SalesRobot built its own MCP server instead of going the cookie route. 

It connects Claude to your SalesRobot account using your API key, not your LinkedIn session, so you can create campaigns, check prospect status, or send a message just by asking Claude in plain language. Every action still runs through SalesRobot's own safeguards, so you're not handing an AI raw access to your LinkedIn login.

How Do You Evaluate a LinkedIn Tool Before Connecting It?

Before you connect anything to your LinkedIn account, run it through a few quick questions. 

Does it log in through LinkedIn's own OAuth screen, or does it ask for your session cookie?

Can it take action, like posting or messaging, without showing you the exact content first? 

What does it store about other people, and can you actually go delete it if you want to?

And can you revoke its access in one click from your LinkedIn settings, or is it stuck sitting in some config file somewhere you can't reach? 

If a tool fails most of these, it's probably operating outside what LinkedIn actually allows.

That doesn't automatically mean you shouldn't use it. It just means you should know exactly what you're signing up for.

So Which Path Should You Actually Build On?

If you're building a custom outreach stack, you basically have three paths in front of you. 

You can apply for LinkedIn's official API and wait out the approval process, which works if you have months to spare and a narrow enough use case.

You can build on top of an infrastructure API like Unipile, which gets you moving a lot faster. But it still leaves you managing the compliance risk yourself.

Or you can plug into a platform that's already solved this problem and just use its API. That third option is honestly where a lot of engineering teams end up.

Not because they can't build it themselves, but because they'd rather spend their time on their own product instead of babysitting LinkedIn's detection systems. 

If that's you, SalesRobot has its own REST API and webhooks with token based authentication, plus the MCP server if you'd rather just talk to Claude instead of writing code.

You can create campaigns, manage leads, and trigger workflows straight from your own systems. No session cookie, no waiting on a partner application.

It's built for teams who want the outreach layer handled so they can go focus on everything else. 

Either way, I hope this gave you a clearer picture than most of what's out there right now.

This space moves fast. LinkedIn changes its enforcement patterns often enough that it's worth checking back in every few months.

‍