Kameleo Mobile Proxies for Automation: API and Selenium Setup

Kameleo is an anti-detect browser that was designed with automation in mind. Beyond the desktop app, it exposes a local REST API and client libraries, and it works with Selenium, Puppeteer and Playwright so you can drive profiles the way you would drive plain Chrome. That makes it a natural fit for teams that run scheduled account tasks, regression tests of geo-specific behaviour, ad verification or price monitoring. What every one of those jobs needs is a connection that looks like a real device on a real network, and that is what a mobile proxy from NeonProxies supplies: a carrier IP on a physical SIM, addressable by API, rotated on your command. This guide covers manual setup first and then shows how to create profiles with proxies programmatically.

What Kameleo needs from a proxy

Every Kameleo profile can carry its own proxy, defined by type, host, port, username and password. The app can derive timezone, geolocation and language from the proxy IP, and it tests the proxy before starting the profile. In automation, the same fields are set in the profile creation request, so whatever you can do by hand you can do from a script.

A mobile proxy is a strong match because a carrier IP with a matching timezone is the least surprising combination a site can see. For automation, two more things matter: the proxy should be reachable from the same machine that runs Kameleo with predictable latency, and it should be controllable through an API so your code can rotate it between runs. NeonProxies provides both.

• Per-profile proxy: HTTP or SOCKS5, host, port, username, password
• Automatic timezone and geolocation from the proxy IP
• Proxy check before the profile starts
• The same proxy fields available in the REST API and client libraries

Manual setup in the Kameleo app

Copy the host, ports, username and password from your NeonProxies dashboard. Create a new profile in Kameleo, choose a mobile or desktop base profile depending on what you are emulating, and open the proxy section of the profile settings. Pick SOCKS5 if you want DNS and UDP inside the tunnel, or HTTP if a downstream tool expects it. Enter host, port and credentials, run the proxy test, and confirm the reported city is the metro you ordered.

Leave the timezone and geolocation settings on automatic so they follow the IP. Start the profile, open an IP lookup page and verify the external address matches what the test reported. Once that works by hand, you know the values are correct and can move them into code.

Automating profile creation with the API

Kameleo runs a local API server alongside the app. Your script asks it for a base profile, creates a new profile from it with the proxy fields filled in, starts the profile, and receives a WebDriver or DevTools endpoint. From there, Selenium, Puppeteer or Playwright attaches as it would to any browser.

The proxy object in the creation request holds the same values you typed by hand. Store your NeonProxies credentials in environment variables or a secrets store, never in the script itself. A simple pattern is a table mapping profile names to proxy IDs; the script looks up the proxy, calls our API to confirm it is online, creates the Kameleo profile with that proxy, runs the job, and stops the profile.

Rotation fits in the same loop. Before each run, call the proxy's rotation link or our API endpoint, wait for the modem to come back with a new IP, then start the profile. Because there is no wait between changes and rotations are unlimited, a queue of jobs can each start on a fresh carrier IP without any pacing logic on your side.

• Fetch proxy details from the NeonProxies API
• Create the Kameleo profile with the proxy fields set
• Start the profile and attach Selenium, Puppeteer or Playwright
• Rotate via the link or API between jobs, then stop the profile

Sticky or rotating for automated runs

Match the rotation mode to the job. Account maintenance tasks should run sticky: one IP for the whole session, rotation only after logout. Verification and monitoring tasks benefit from a new IP per run, so rotate at the top of each iteration. Kameleo keeps the profile fingerprint stable between runs regardless, so rotating the IP does not reset cookies or storage.

If a job is long, resist the temptation to rotate part way through. A rotation reconnects the modem, which drops open connections for a moment; a download or a form post in flight can fail. Rotate at natural boundaries and your success rate stays high.

Scaling profiles and proxies together

Keep a one-to-one mapping between Kameleo profiles and NeonProxies proxies for anything account-related. For stateless monitoring, a proxy can serve several sequential profiles as long as you rotate between them. Group proxies by metro in the dashboard and name profiles to match, so a job that targets Los Angeles only ever picks Los Angeles proxies.

When a target moves region, use the free self-service location moves from your dashboard and update the mapping table; nothing else changes. Kameleo supports profile groups and team sharing, so an operator can inspect a profile a script created, with the proxy already attached.

Run Kameleo and the script on the same machine or the same network to keep latency predictable. If you distribute across several workers, each worker can own a slice of the proxy list, avoiding two workers driving the same modem.

Troubleshooting automation runs

Authentication errors from the API usually mean the credentials were read from the wrong variable or the port does not match the type. A profile that starts but times out on the first page is often waiting on a rotation that has not completed; poll the proxy status through our API before starting. Geolocation mismatches happen when a script sets a timezone explicitly and forgets to update it after a location move.

For WebRTC and DNS, rely on Kameleo's per-profile settings and use SOCKS5 with remote DNS. If a run reports a different IP than expected, check whether another worker rotated the same proxy. A lock or a queue per proxy solves that.

• Auth errors: verify variables and the port-to-type match
• Timeouts after rotation: poll proxy status before starting
• Wrong city: clear the manual timezone after a location move
• IP changed unexpectedly: one worker per proxy

Why NeonProxies for Kameleo automation

We run our own 4G and 5G modems with real SIM cards on AT&T, T-Mobile and Verizon in New York, Los Angeles, Chicago, Houston, Phoenix, Miami, North Carolina and Boston. Every proxy has a rotation link and is addressable through our API, which is the piece automation teams care about most. 4G typically delivers 20–45 Mbps, 5G 50+ Mbps, and unlimited data is included on every plan, so long-running jobs are never interrupted by an allowance.

HTTP(S) and SOCKS5 with UDP are available on every proxy, sessions are sticky until you rotate, and plans start at $5/day with weekly and monthly options.

Frequently asked