GoLogin Mobile Proxies for Automation: API, SDKs and Rotation

GoLogin pairs an antidetect browser, built on its own Orbita engine, with an API and SDKs on its paid plans, so a profile you set up by hand can also be created, launched and closed from code. Selenium, Puppeteer and Playwright can then drive the running profile like any other browser. That makes it a strong option for scheduled account jobs, geo-specific QA, ad checks and price monitoring. The part GoLogin leaves to you is the network, and in automation the network is where runs quietly fail. NeonProxies supplies US carrier IPs on physical SIMs, sticky until your code says otherwise, with rotation and status available through our own API. This guide covers the hand-built baseline first, then the automated loop.

Proxy fields GoLogin works with

Every GoLogin profile stores one proxy: a type (HTTP, SOCKS4 or SOCKS5), a host, a port, a username and a password. NeonProxies lines expose an HTTP port and a SOCKS5 port, so pick one of those two. The desktop app has a check proxy button and a paste field that accepts host:port:user:pass, and the same values are what you supply when a profile is defined from code.

For automation, treat those five values as data, not configuration typed into a window. Keep them in one place, such as a table of profile names and line identifiers, so a job can look up what it needs at run time and a person can audit it later.

socks5://USERNAME:PASSWORD@HOST:SOCKS5_PORT

http://USERNAME:PASSWORD@HOST:HTTP_PORT

HOST:SOCKS5_PORT:USERNAME:PASSWORD

Prove the line by hand before you script it

A five-minute manual pass saves hours of debugging later. It confirms that the credentials are right, that the port matches the protocol and that the IP lands in the metro you bought, all before any code is involved.

Once the hand-built profile works, every value in it is known good. If an automated run later fails, you can compare against this baseline instead of guessing.

1. Copy the host, SOCKS5 port, username and password for one line from your NeonProxies dashboard.
2. Create a profile in the GoLogin app, choose SOCKS5 and paste the host:port:user:pass string.
3. Press check proxy and confirm a US carrier IP in the expected city.
4. Leave timezone, language and geolocation on automatic so they follow the IP, and set WebRTC to use the proxy's address.
5. Start the profile and load an IP lookup page to confirm the browser agrees with the check.

• Get GoLogin (partner link)

The automated loop with the GoLogin API and SDKs

On paid plans, GoLogin's API and SDKs let your code do what you just did by hand: create or update a profile with its proxy, start it, and get back a connection your automation framework can attach to. Selenium, Puppeteer and Playwright are all supported, so the choice of framework is about your team's habits rather than the browser. Follow GoLogin's own documentation for the exact calls; the flow around them is what matters here.

A dependable job looks like this. The runner reads the profile-to-line pair from your table. It asks the NeonProxies API whether that line is online and, if the job wants a fresh address, triggers a rotation and waits until the line reports online again. Only then does it start the GoLogin profile with the line attached, hand the connection to Selenium, Puppeteer or Playwright, do the work, and stop the profile so its state is saved.

Because the proxy belongs to the profile, your framework code never needs proxy settings of its own. That separation is useful: proxy credentials live with the profile and in your secrets store, not scattered through test scripts.

• Read the profile and line pair from your own mapping table
• Check line status through the NeonProxies API, rotate if wanted
• Start the GoLogin profile through its API or SDK
• Attach Selenium, Puppeteer or Playwright, run, then stop the profile

Rotation strategy per job type

Lines stay sticky until rotated, and rotations are unlimited with no wait between changes, so the only cost of a rotation is the modem's reconnect time. Account maintenance jobs should keep one IP for the whole run and rotate only after the profile is stopped. Monitoring and verification jobs usually want a new IP per iteration, so rotate at the top of the loop.

Never rotate while a request is in flight. A reconnect drops open connections briefly, which can break an upload, a checkout step or a form post. Put the rotation call behind a guard that confirms the profile is stopped, and a whole class of flaky failures goes away.

Workers, locks and scale

When jobs run on several machines, give each line a single owner at any moment. Split the line list across workers, or take a lock per line in your queue, so two workers never rotate the same modem. Group lines by metro and name profiles to match, so a Chicago job cannot accidentally pick up a Miami line.

GoLogin team sharing on paid plans lets an engineer open a profile that a script created and see exactly what the job saw, line included. When a target region changes, use the free self-service location move in your dashboard, update the city in the mapping table, and let the next run pick up the new timezone from the IP.

Debugging failed runs

Most failures fall into a few buckets. Authentication errors usually mean the wrong environment variable was read or the port belongs to the other protocol. Timeouts on the first page often follow a rotation that had not finished; poll the line's status before starting the profile. A city mismatch after a location move usually comes from a timezone hard-coded in the profile definition.

If a run reports an IP nobody expected, look for a second worker or a cron task calling the rotation link. A lock per line fixes it for good.

• Auth error: check the variable source and the port-to-protocol match
• Timeout after rotation: wait for the line to report online
• Wrong city: remove hard-coded timezones after a move
• Unexpected IP: enforce one owner per line

Frequently asked