Exactly how we run your LinkedIn account.

Your account gets its own cloud browser on our server. It holds your LinkedIn session and sends each action through LinkedIn’s own internal web API, the same one linkedin.com uses in your browser. It never opens profile pages in a scraping loop.

• No browser extension, and nothing to install.
• Your computer can be off. Runs carry on in the cloud.
• One LinkedIn account per workspace.
• Every run has a live log and a cancel button.

The plan has a cap for each kind of action. You can set a lower number for any run, never a higher one. Daily caps reset at midnight India time (IST).

The 7-day cap looks back over the last 7 days, not a calendar week. LinkedIn limits most accounts to about 100 invitations a week, and hitting LinkedIn's limit blocks invitations for about a week. So the plan stops at 100.

Connection requests go out one at a time, with a random wait between each one, at the pace you pick:

• Slow90 to 180 seconds
• Normal30 to 60 seconds
• Fast5 to 15 seconds

Messages and likes also wait a random gap between each one.

Your cloud browser doesn’t reach LinkedIn straight from our server. Each paying account gets its own static IP address in the country it picks, bought for that account and used only by it. Runs on your account go out through that address, so LinkedIn sees your account coming from the same place each time.

• Static: the address stays the same from one run to the next.
• Yours alone: no other customer's account uses it.
• In your country: India, the United States, the United Kingdom, Canada, Germany, France, the Netherlands or Singapore. The default is India.
• Changing the country gives your account a new IP address.

An IP address of your own lowers one kind of risk. It doesn’t make automation safe, and it can’t promise LinkedIn will never ask you to verify your account.

Your li_at cookie is what keeps you signed in to LinkedIn. Anyone who holds it can act as you until you sign out, so we treat it like a password.

• It is encrypted with Fernet (AES-128 with an HMAC check) before it is saved.
• The key is kept in a separate locked file on the server, away from the database and the app settings. A copy of the database on its own reveals no cookie.
• It is never written to logs, and never shown back to you in the app.
• You can delete it any time from the LinkedIn cookie page in your account. That also wipes your cloud browser's session.
• Signing out of all sessions on LinkedIn (Settings, Sign in and security, Where you’re signed in) makes every copy of the cookie useless, ours included.

Encryption can’t protect against someone who takes over the server itself. That is why the last point matters: signing out everywhere on LinkedIn is the one step that always works.

The outside services we use, and what each one receives, are listed on the subprocessors page.

1. Stop your runs. Cancel anything still running from its live log.
2. Log in to LinkedIn yourself, in your usual browser, and complete the check.
3. Wait. Use LinkedIn by hand for a while before you start runs again.
4. Paste a fresh li_at cookie, because the old one may no longer work.

The guide on what to do when your cookie expires walks through the last step, and getting your li_at cookie shows where to find it.