Antidetect browsers and proxies

Every connected LinkedIn account lives in exactly one antidetect browser: an isolated browser profile with a stable device fingerprint and its own proxy. LinkedIn always sees the same device in the same location, which is what keeps automated activity looking like the account’s normal usage. You never hand over the LinkedIn password; the login happens inside that browser.

Browser lifecycle

A browser is created (cloud-minted or bring-your-own), run when work needs it, and stopped when idle.

An idle running browser is suspended automatically after about 15 minutes without activity, and due syncs or actions wake it on their own. See Sync windows and auto-suspend.

If a running browser becomes unhealthy (its LinkedIn tab dies, the profile crashes), the platform marks it with an issue status and powers it off instead of leaving it running blind. Fix the underlying problem, most often the proxy, then run it again. Deleting a browser removes the profile; the bound LinkedIn account can be reconnected later through a new browser.

Where to see all of this

Open the account’s drawer on the Senders page and switch to the Browser tab: the browser block (vendor, owner, status, fails and logouts), the proxy block (latency, uptime), and the event log underneath.

Account drawer Browser tab showing the antidetect browser block, proxy block and browser event log — The Browser tab of the account drawer: browser state on the left, proxy health on the right, the event log below.

Connect a profile you already own

Instead of letting the platform mint a browser, you can bind a GoLogin profile that already exists in your own account. Open Senders, click Connect account, switch to Existing profile ID. The profile keeps its own proxy and its own fingerprint, and it stays yours. The one thing that trips people up: we read that profile through our GoLogin account, not through yours. GoLogin’s API only answers for profiles the calling account can see, so a profile sitting in your account is invisible to us until you share it.

Share the profile with us in GoLogin

Open the profile in GoLogin, click Share, and add pro@getsales.io.The share has to let us RUN the profile, not only see it. Before anything is created we read the profile’s own canBeRunning flag, and a share that cannot launch it is refused right there.

Leave the profile unlocked

GoLogin’s profile lock (lockEnabled) blocks launching. We read it in the same check, so a locked profile is refused at connect too. Turn the lock off first.

Paste the profile ID

Copy the profile ID from GoLogin (the long hex string, e.g. 88857ca36ce45f284aab6213) and paste it into GoLogin profile ID, then click Verify & connect.

Both checks happen before the browser exists, so a refusal costs you nothing:

What you see	What it means
Profile not found, or it is not shared with gtm-api	The ID is wrong, or the share never happened. GoLogin answers the same way for “no such profile” and “not yours to see”, so check both.
This profile is shared with gtm-api but cannot be started	We can see it, but it is not runnable: the share does not allow launching, or the profile lock is on.
This vendor profile ID is already in use	The profile is already bound to a browser, here or in another workspace. One profile drives one sender.

Sharing a profile does not hand over your GoLogin account, and we never change the profile’s proxy or fingerprint. Un-share it in GoLogin whenever you want; the browser stops working on our side and nothing else about your account changes.

Proxies: cloud and BYO

Cloud-minted browsers require a proxy. You pick the country when creating the browser; the platform attaches the least-loaded active proxy from the pool in that country automatically.
Bring-your-own browsers keep their own. An existing vendor profile (for example GoLogin) arrives with its proxy; the platform reads the session and never changes the proxy.

Choose the proxy country to match where the account genuinely operates. A sudden country change is a classic trigger for LinkedIn verification challenges, and changing the proxy of a live browser restarts it: a running session keeps the old proxy until the browser respawns.

Diagnose a proxy

Two checks are available per browser in the drawer:

Check	What it verifies
Connectivity check	The proxy actually answers
Location check	The proxy’s real-world geo matches what is configured

If LinkedIn does not load inside the browser, run the connectivity check first. A browser whose proxy is dead cannot sync or act; parked work resumes automatically once the browser is healthy again.

The same over the API

# List the team's browsers with their status
curl -X POST "https://app.gtm-api.com/linkedin/v4/api/antidetect-browsers/search" \
  -H "Authorization: Bearer gtm_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"filter": {"status": {"eq": "running"}}}'

const res = await fetch(
  "https://app.gtm-api.com/linkedin/v4/api/antidetect-browsers/search",
  {
    method: "POST",
    headers: {
      Authorization: "Bearer gtm_live_YOUR_KEY",
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ filter: { status: { eq: "running" } } }),
  },
);
const { items } = await res.json();

POST /api/antidetect-browsers/run and /stop control the session, /update-proxy moves a browser to another proxy (country included), and /replace-proxy rotates the IP in place. The full contract lives in the API reference.

Start here

Accounts and browsers

Safety and pacing

Finding and enriching

Conversations

Workspace and billing

Troubleshooting

Antidetect browsers and proxies

Browser lifecycle

Where to see all of this

Connect a profile you already own

Proxies: cloud and BYO

Diagnose a proxy

The same over the API

​Browser lifecycle

​Where to see all of this

​Connect a profile you already own

​Proxies: cloud and BYO

​Diagnose a proxy

​The same over the API

​Related

Browser lifecycle

Where to see all of this

Connect a profile you already own

Proxies: cloud and BYO

Diagnose a proxy

The same over the API

Related