A practical product-risk guide

So You Want to Build Another LinkedIn Tool?

Most LinkedIn tools look harmless. You connect your account, click a button and the tool starts finding leads or sending messages.

I’ve reviewed enough of them to know that what happens after that click can vary considerably. Some use LinkedIn’s official API. Some scrape public pages. Others ask the customer to install a browser extension, provide a session cookie or hand over their LinkedIn password. Some also use proxies to hide where the activity is coming from.

This is where the risk begins.

To the customer, these products can look almost identical. They find prospects, collect profile information, send connection requests, follow people or export Sales Navigator searches.

The risk depends on how the product does it.

When I review one of these tools, I start with one question:

Exactly whose computer, credentials, session and IP address are touching LinkedIn?

The answer tells me whose account could get restricted, whether the customer’s login information is at risk and how easily LinkedIn could stop the product from working.

Acceptable and safe are two different decisions

“Safe” gets used too casually in this category. A founder will explain that activity is randomized, spread throughout the working day and kept below a conservative daily limit. Each account may receive its own residential proxy. New accounts are warmed up slowly.

Those controls may reduce detection. They do not provide LinkedIn’s permission.

LinkedIn’s current User Agreement prohibits sharing login credentials or copying cookies, using crawlers, scripts, browser plugins and similar technology to scrape the service, bypassing access controls or usage limits, and using unauthorized automation. LinkedIn can restrict or terminate accounts that breach the agreement.

We separate the decision into four risks:

  • Permission risk: Has LinkedIn approved the access?
  • Account risk: Could the customer’s account be restricted?
  • Credential risk: Does another company hold a password, cookie or authenticated session?
  • Product risk: Can LinkedIn disable the product by changing a page, blocking an IP or enforcing its rules?

1. LinkedIn’s approved API

Customer AUTHORIZE Approved scopes in APPROVED API Your product LinkedIn controls the scopes, endpoints and limits

If LinkedIn’s official API supports what you want to build, use it. Confirm which endpoints and permissions your application will receive before you start developing the feature.

Most founders avoid LinkedIn’s official API because it gives them very limited access. Any developer can use it to sign users in, retrieve basic profile information and publish content. Access to Sales Navigator, advertising, recruiting and other LinkedIn data requires approval for one of LinkedIn’s partner programs. And many of the things these tools want to do, such as searching profiles, exporting search results, sending connection requests or reading messages, are unavailable through the API. The founder then has two choices: remove those features or find another way to access LinkedIn.

And don’t assume a product uses LinkedIn’s API just because it has a “Sign in with LinkedIn” button. It may use LinkedIn to identify the customer, then scrape the data separately. Ask which API endpoints and permissions the product uses and whether it belongs to LinkedIn’s Partner Program. Unless Closely, WebClaw or ConnectSafely can provide those details, I would treat their LinkedIn features as unofficial.

2. Public URL scraping without a login

linkedin.com/in/profile SUBMIT URL Customer browser Vendor server No customer session in Public page LI Account is absent. Platform risk remains.

Use the public URL method when it gives the tool the information it needs. Tell customers that LinkedIn still prohibits scraping, and only collect and store the information required for the feature.

WebClaw is a good example of this method. The customer gives it a LinkedIn URL, and WebClaw scrapes the page without logging into the customer’s LinkedIn account. Since the account is never used, it can’t be flagged or restricted because of the scraping.

LinkedIn can still block WebClaw’s servers because scraping public pages is against its terms. And just because information appears on a public profile doesn’t mean you can store it, resell it or add the person to an outreach campaign.

3. A Chrome extension in the customer’s browser

in EXTENSION in LI ACCOUNT Customer IP The session stays local. The customer’s account still performs the activity.

Choose this only when the approved API cannot support the feature and the customer knowingly accepts account risk.

ConnectSafely also offers a Chrome extension. With this option, the customer stays logged in through their own browser and doesn’t give ConnectSafely their LinkedIn password or session cookie.

That distinction is important. The extension operates inside the customer’s existing browser session, on their own computer and IP address. The password and session cookie remain on the customer’s device, and the customer can remove access by disabling the extension.

LinkedIn explicitly includes browser extensions among the prohibited technologies when they scrape or automate activity. The extension protects the secret better. It does not protect the account from enforcement.

Closely has been offering LinkedIn automation for years, so these tools can clearly continue operating for a long time. That still doesn’t mean LinkedIn allows them.

4. Copy a session cookie to the vendor

Session cookie Live account access Customer browser Vendor cloud Holds the session in LI ACCOUNT A leak can expose the authenticated account

Don’t ask customers for their LinkedIn session cookie if the tool can get the same information from a public URL.

A cookie sounds harmless because browsers collect hundreds of them. An authenticated session cookie is closer to a temporary key. Anyone able to use it may be able to enter the account without typing the password and sometimes without repeating 2FA.

WebClaw shows why architecture choices count. Its unauthenticated URL method avoids customer-account exposure. Adding a cookie workflow moves the same product into a much more dangerous category. LinkedIn specifically mentions copying cookies in its prohibition against using another person’s account.

5. Give the vendor a LinkedIn password

Password Vendor cloud Dedicated proxy in LI ACCOUNT The vendor holds the secret. The customer receives the restriction.

Avoid this architecture. It combines the highest account exposure with the highest credential exposure.

ConnectSafely has offered options where the user provides LinkedIn credentials, with a dedicated proxy assigned to each account. It also describes human-style pacing, variable sessions, working-hour activity, conservative limits and gradual warm-up.

All of this may make the automation harder for LinkedIn to detect. The problem is that the product still has the customer’s login credentials and uses a proxy to access LinkedIn on their behalf.

Closely and similar tools have been doing this for years. That still doesn’t mean LinkedIn allows it.

What if the product uses another service?

I found that some LinkedIn products connect through other services such as Unipile or PhantomBuster.

Unipile or PhantomBuster can be used instead of building the actual connection logic into the product itself. Unipile can log in with the customer’s LinkedIn username and password. PhantomBuster runs automations through the customer’s LinkedIn session cookie.

Neither method uses LinkedIn’s official API. The customer’s account is still doing the work, so LinkedIn can restrict or ban it.

There is another catch: the customer needs a separate paid subscription to Unipile or PhantomBuster. If that subscription is not included, say so before the customer buys your product, rather than waiting until they reach the connection screen.

My advice: Treat both options like any other unofficial login or cookie workflow. Explain the LinkedIn account risk and the extra subscription cost before purchase.

The five ways a tool can connect to LinkedIn

How it works Example Risk to the customer Recommendation
The tool uses LinkedIn’s official API An application approved by LinkedIn Very little account risk when the tool stays within the permissions LinkedIn gave it. Use this whenever it supports what you want to build.
The tool scrapes a public page without logging in WebClaw’s public URL method The customer’s account is never used. LinkedIn may block the tool’s servers, although the customer’s account should be unaffected. Use it when public information is enough, and tell customers that LinkedIn prohibits scraping.
A browser extension uses the customer’s logged-in account ConnectSafely’s Chrome extension The password and cookie stay inside the customer’s browser. LinkedIn may still restrict the account because the extension performs the activity through it. Use it only when the API and public pages cannot support the feature, and explain the account risk.
The customer gives the tool a session cookie Authenticated scraping workflows The vendor may be able to enter and use the customer’s LinkedIn account. The account may be restricted, and a leaked cookie may give someone else access. Avoid it. Remove the cookie requirement when a public URL can do the job.
The customer gives the vendor a password ConnectSafely’s credential methods and tools such as Closely The vendor logs in and performs activity as the customer. The customer risks both an account restriction and exposure of their password. Avoid it and choose another way to build the feature.

How I assess a tool without LinkedIn API approval

Lacking an approved LinkedIn API connection does not automatically disqualify a tool. Many of the features these products offer are unavailable through LinkedIn’s official API. I look at how the product connects to LinkedIn and what the customer must give up for it to work.

A product that asks customers for their LinkedIn email and password creates a serious credential risk. The vendor may store those credentials and keep access to the authenticated account. If the password or session is exposed, someone else could enter the customer’s LinkedIn account.

There is also account risk. When the activity runs through the vendor’s browser profile and proxy, LinkedIn may detect an unfamiliar device or location. The restriction lands on the customer’s account, even though the vendor performed the activity.

And encrypting the customer’s password aftr collecting it does not mitigate that risk.

One alternative is a local Chrome extension. It operates through the customer’s existing LinkedIn session in their own browser, on their own computer and IP address. The password and session cookie stay on the customer’s device. Access can also be removed by disabling the extension.

The extension still operates without LinkedIn’s permission, and the customer’s account may still be restricted. Its advantage is narrower: the customer keeps control of their credentials and authenticated session.

When a product relies on collecting LinkedIn passwords, I would ask the company to provide an alternative connection method and explain the remaining account risk. I would ask if their tool can provide a working local option.

API approval is one part of the assessment. The connection method, access to customer credentials and consequences for the customer determine whether the product puts the customer’s account at risk or not.

Questions to ask you before you build it

Before you start building, I would want to answer these questions:

  1. What do you want the tool to do on LinkedIn?
    Show me the exact list. Reading a public profile, collecting search results, sending an invitation and messaging someone are four different jobs. Each one creates a different level of risk.
  2. Have you checked what LinkedIn’s official API can do?
    I would want the names of the API endpoints and the permissions LinkedIn gives you. An OAuth button only proves that the user signed in. It tells me nothing about how the product collects its data or sends its messages.
  3. Does the customer need to connect a LinkedIn account at all?
    If the feature works by visiting a public URL, leave the customer’s account out of it. LinkedIn may block your scraper one day, although the customer’s account will be unaffected.
  4. What are you asking the customer to give you?
    A local browser extension, a session cookie and a LinkedIn password may all be presented as ways to “connect an account.” They are very different. The extension keeps the login on the customer’s computer. A cookie or password gives your company access to the account.
  5. Where will the LinkedIn activity happen?
    Will it happen inside the customer’s browser, from your servers or through a residential proxy? I want to know which account and IP address LinkedIn will see. That tells me who receives the restriction if the automation is detected.
  6. What happens when LinkedIn detects it?
    Assume this will happen eventually. A blocked vendor IP means your product stops working until you fix it. A restricted customer account means someone may lose years of contacts, messages and history. Those are very different support tickets.
  7. Can you build a useful product without the riskiest feature?
    Sometimes almost everything works from public pages, while one extra feature requires a password or cookie. Make that feature optional, redesign it or remove it. Do not put every customer at risk for the sake of one checkbox on the pricing page.
  8. What will you tell customers before they connect?
    Say plainly that LinkedIn prohibits unauthorized scraping and automation, and that their account may be restricted. “Use responsibly” tells them nothing. It mainly gives the warning a nice place to hide.
  9. Does the customer need to pay for another service?
    If the LinkedIn feature depends on a separate automation provider, find out who pays for it. A feature advertised as part of your product should not surprise the customer with another monthly subscription during setup.

Use the lowest-risk method that can support the feature. Start with LinkedIn’s official API. If the API can’t do it, check whether the tool can get what it needs from a public page without logging into the customer’s account. If the tool must use the customer’s account, a browser extension is safer than collecting their password or session cookie. I would avoid storing either one on your servers.

Sources and a necessary disclaimer

LinkedIn’s User Agreement was effective November 3, 2025 when this article was written. Its prohibited software and extensions guidance describes the tools it prohibits and the account consequences. Check both again before launching because platform rules and enforcement change.

Note: This is product and technical risk advice. It is not legal advice. Privacy, intellectual-property, anti-spam and computer-access laws vary by location, data and use case.