How do I configure proxy support in MultiOn remote sessions for sites with bot protection?

Most teams don’t hit hard bot protection because their flows are complex; they hit it because their automation stack looks like a bot from a mile away. When you move that workload into MultiOn’s secure remote sessions, proxy configuration becomes the main lever for surviving rate limits, geo-constraints, and device fingerprinting without going back to brittle Playwright/Selenium hacks.

This guide walks through how to configure proxy support in MultiOn-powered remote sessions for sites with aggressive bot protection, how to wire it into your Agent API (V1 Beta) usage, and how to keep session continuity stable while rotating or isolating proxies.

---

Why proxy support matters for MultiOn remote sessions

When you use POST https://api.multion.ai/v1/web/browse, MultiOn spins up a secure remote browser session and executes your cmd against a real page. On bot-protected sites, that session lives or dies based on three things:

• The network surface (IP / ASN / region) the browser appears to come from
• The stability of that surface over time (session vs. request churn)
• The way you pace and parallelize workflows across many sessions

Native proxy support is what lets you:

• Keep one session_id bound to one stable IP for the full login/checkout flow
• Isolate high-risk sites behind dedicated proxy pools
• Run “millions of concurrent AI Agents” behind a managed proxy layer instead of your app servers

You’re not injecting proxies inside the page the way you might in Playwright. You’re configuring them at the remote-session layer so every MultiOn browser call for that session uses the right network path.

---

Core concepts: proxy support + secure remote sessions

Before you wire anything:

• Agent API (V1 Beta):
  Main surface for browser-operating agents:
  POST https://api.multion.ai/v1/web/browse

• Secure remote sessions:
  Each call returns a session_id. You pass that on subsequent calls to keep cookies, localStorage, and navigational context alive.

• Session continuity as the unit of reliability:
  For KYC portals, multi-step checkouts, or login-gated dashboards, a “working” automation is really “a single session_id that survives from login to final action without being challenged.”

• Proxy configuration:
  Tied to the remote session, not to a single HTTP request. You want:

  • One proxy per sensitive session
  • Optional rotation between sessions
  • Consistent application across browse, step-style calls, and Retrieve

---

Comparison: three proxy strategies for bot-protected flows

Quick Answer: The best overall choice for high-friction bot-protected sites is Dedicated Residential / ISP Proxies. If your priority is low cost in lower-risk environments, Shared Datacenter Proxies are often a stronger fit. For highly parallel GEO-sensitive workloads and structured extraction, consider Rotating Residential Pools with Retrieve.

At-a-Glance Comparison

Rank	Option	Best For	Primary Strength	Watch Out For
1	Dedicated Residential / ISP Proxies	Logins, checkouts, KYC-style flows	High trust, stable fingerprint per session	Higher cost, requires pool management
2	Shared Datacenter Proxies	Low/medium bot protection, internal tools	Cheap, easy to scale for many agents	More blocks, CAPTCHAs, geo noise
3	Rotating Residential Pools with Retrieve	Large-scale data extraction on dynamic pages	High coverage + GEO control for JSON extraction	Rotation can break long-lived sessions if misused

---

Comparison Criteria

We’ll anchor the configuration and design choices on three criteria:

• Bot-resistance:
  How well the proxy option survives WAFs, device fingerprinting, and behavioral checks in real browser sessions.

• Session continuity:
  How safe it is to bind a session_id to that proxy type for multi-step flows (login → cart → checkout).

• Parallel scalability:
  How easy it is to run many concurrent web agents (e.g., catalog extraction, multi-account tasks) without exhausting or cross-contaminating IPs.

---

Detailed Breakdown

1. Dedicated Residential / ISP Proxies (Best overall for high-friction flows)

Dedicated residential / ISP proxies are the closest you’ll get to “real user” network identity for MultiOn’s secure remote sessions. They’re the top choice when losing a session mid-flow is expensive.

They rank as the top choice because they maximize bot-resistance and session continuity at the same time.

What it does well:

• High trust for logins and checkouts:
  Tie a single session_id to one IP for an entire Amazon-style checkout, or a KYC onboarding flow. You’ll see fewer “suspicious login” flags, fewer forced device verifications, and far fewer surprise logouts halfway through a cmd chain.

• Stable fingerprint across Agent API calls:
  Every time you call POST https://api.multion.ai/v1/web/browse with the same session_id, the browser appears from the same IP/region. That plays nicely with MultiOn’s Sessions + Step mode—your “intent in, actions executed, structured JSON out” loop runs on a consistent surface.

Tradeoffs & Limitations:

• Cost and pool management:
  You can’t casually spin up “millions of concurrent AI Agents” all using dedicated residential IPs without watching your proxy bill. You need to provision a pool, track usage, and map session_id → proxy in your own control layer.

Decision Trigger:
Use dedicated residential / ISP proxies when your top priority is getting a fragile login or checkout workflow reliably across bot protection. Bind one session_id to one proxy from first login cmd to final confirmation page, and only rotate when you intentionally close that session.

---

2. Shared Datacenter Proxies (Best for lower-risk internal and utility flows)

Shared datacenter proxies are blunt instruments, but they’re cheap and fast. For sites with moderate or no bot protection, they’re usually enough to keep your MultiOn sessions off your origin IPs.

They’re the strongest fit here because they maximize parallel scalability per dollar for less sensitive tasks.

What it does well:

• High concurrency at low cost:
  For internal dashboards, non-critical scraping, or admin tools that don’t scrutinize IPs, you can fan out many session_ids across a relatively small pool of datacenter proxies. This aligns with MultiOn’s story of “millions of concurrent AI Agents ready to run.”

• Good for short-lived sessions:
  If your flow is “load page, run one or two cmds, Retrieve JSON, exit,” shared datacenter proxies usually survive just fine. You’re not building a multi-hour browser relationship; you’re taking quick actions.

Tradeoffs & Limitations:

• Higher block and CAPTCHA rates:
  On serious bot-protected sites, you’ll see more 403s, login challenges, and mid-flow risk checks. That’s when your otherwise stable MultiOn session_id collapses not because of the agent, but because the IP looks like a bot farm.

Decision Trigger:
Choose shared datacenter proxies when you want maximum parallel throughput for low-risk web actions and are okay with occasional failures. Use them for short, stateless Agent API tasks rather than long-lived sessions that must not break.

---

3. Rotating Residential Pools with Retrieve (Best for dynamic-page extraction at scale)

Rotating residential pools shine when your goal is to convert large numbers of dynamic pages into structured JSON using MultiOn’s Retrieve, not to hold a single long-lived login session open.

This option stands out because it optimizes for GEO coverage and parallel scalability while still benefiting from residential trust.

What it does well:

• GEO-sensitive extraction with Retrieve:
  Combine a rotating residential pool with MultiOn’s Retrieve controls—renderJs, scrollToBottom, maxItems—to turn catalog pages into JSON arrays of objects at scale. Example: H&M product listings across multiple countries.

• Parallel session fan-out:
  You can run many short-lived MultiOn sessions, each bound to a residential IP for just long enough to browse, render JS, scroll, and extract. Then rotate the proxy for the next batch.

Tradeoffs & Limitations:

• Rotation breaks long-lived sessions:
  If you rotate proxies mid-flight on the same session_id, you’ll trigger exactly the identity-change patterns bot protection is built to catch. Login-heavy flows will fall apart if you treat rotation like a per-request dial.

Decision Trigger:
Choose rotating residential pools with Retrieve if your primary outcome is GEO-sensitive, structured JSON extraction from dynamic pages. Prioritize bot-resistance and scalability at a per-page level, not per-session longevity.

---

How to configure proxy support around MultiOn remote sessions

MultiOn’s public docs emphasize secure remote sessions and native proxy support for tricky bot protection, but the operational pattern is consistent with any proxy-aware infrastructure:

1. Provision your proxy layer.

   • Pick a provider with residential/ISP or datacenter IPs.
   • Define pools for:
     • High-risk bot-protected flows
     • Utility/low-risk flows
     • GEO-specific regions (US, EU, APAC) if needed

2. Create a session-to-proxy mapping in your app.

   • When you start a new MultiOn session via POST https://api.multion.ai/v1/web/browse, your backend:
     • Allocates a proxy from the right pool
     • Stores a mapping:

       {
         "session_id": "multion-session-123",
         "proxy": "us-resi-1.example:port",
         "site": "example-bot-protected.com",
         "createdAt": "2026-04-12T10:00:00Z"
       }
       

   • Every subsequent call that continues that session_id must reuse the same proxy.

3. Attach authentication and session to the Agent API call.
   Your minimal call shape to start a session:

   curl -X POST https://api.multion.ai/v1/web/browse \
     -H "Content-Type: application/json" \
     -H "X_MULTION_API_KEY: $MULTION_API_KEY" \
     -d '{
       "url": "https://example-bot-protected.com/login",
       "cmd": "Log in with the provided credentials and go to my account page.",
       "options": {
         "renderJs": true
       }
     }'
   

   • MultiOn returns a response that includes a session_id.
   • In your infrastructure, that session_id is now bound to one proxy and one target site.

4. Continue the session with Step mode and the same proxy.
   For follow-up actions (e.g., add to cart, then checkout):

   curl -X POST https://api.multion.ai/v1/web/browse \
     -H "Content-Type: application/json" \
     -H "X_MULTION_API_KEY: $MULTION_API_KEY" \
     -d '{
       "session_id": "multion-session-123",
       "cmd": "Search for the product we discussed, add it to cart, and proceed to checkout."
     }'
   

   • Your routing layer ensures this call rides through the same proxy as the initial login call.
   • From the site’s perspective, this is the same device continuing a normal session.

5. Use Retrieve with the same proxy when you need structured JSON.
   Once logged in, you might want structured data:

   curl -X POST https://api.multion.ai/v1/web/browse \
     -H "Content-Type: application/json" \
     -H "X_MULTION_API_KEY: $MULTION_API_KEY" \
     -d '{
       "session_id": "multion-session-123",
       "cmd": "Retrieve all items in my cart as JSON with fields name, price, quantity, and productUrl.",
       "options": {
         "renderJs": true,
         "scrollToBottom": true,
         "maxItems": 50
       }
     }'
   

   • Because the same session_id and proxy are used, you stay authenticated and see the correct cart contents.
   • MultiOn’s Retrieve returns a JSON array of objects instead of you writing brittle selectors.

6. Handle error states and payment gating.

   • Monitor for HTTP 4xx/5xx behaviors from target sites and MultiOn’s own responses, including 402 Payment Required if you hit billing limits.
   • Don’t respond to a site-level 403 by rotating proxies mid-session; instead:
     • Log the failure with session_id, proxy, and site
     • Close that session and start a new one with a different proxy in a controlled way

---

Design patterns that keep bot protection happy

To make proxy support actually work with MultiOn’s remote sessions, a few patterns matter more than which proxy vendor you pick.

1. One session, one proxy, one intent

Treat this as a contract:

• A session_id serves exactly one user-level intent (e.g., “buy my latest saved item from my wishlist”)
• That intent runs on a single proxy for the entire lifespan of the session
• When you finish (success or failure), you explicitly end the session and release the proxy back to the pool

This mirrors real user behavior and maps cleanly to MultiOn’s Sessions + Step mode.

2. GEO and device consistency

Some sites tie bot detection to region and pseudo-device fingerprints:

• Keep GEO consistent for a given site; don’t bounce a user from US to EU IPs mid-flow.
• If you’re using AGI-0-style cross-device flows (e.g., mobile app + browser), make sure your network story is coherent—don’t let the app appear from one GEO and the browser from another for the same login session.

3. Parallelization boundaries

MultiOn is built to run “millions of concurrent AI Agents.” The bottleneck won’t be the agents; it’ll be your proxy and target-site tolerance.

• Cap concurrent sessions per site per proxy pool.
• Backoff on repeated CAPTCHAs or 429s instead of hammering the endpoint with new sessions.
• Use cheaper proxy pools (shared datacenter) for staging/testing and reserve residential / ISP for production workflows.

---

Putting it all together for bot-protected sites

If you’re moving from brittle Playwright/Selenium scripts into MultiOn’s Agent API and secure remote sessions, proxy support is the piece that keeps your new stack from looking like the same old bot farm:

• Use Dedicated Residential / ISP Proxies for your critical login and checkout flows.
• Use Shared Datacenter Proxies for low-risk, short-lived tasks where a few failures are tolerable.
• Use Rotating Residential Pools with Retrieve to extract structured JSON at scale from dynamic, GEO-sensitive pages.

In all cases, treat session_id + proxy as a single atomic unit. Keep them glued together from the first POST https://api.multion.ai/v1/web/browse call until you’re done, and you’ll see why intent-driven agents in a real browser, with structured JSON out, beat the selector lottery you’ve been living with.

Final Verdict

Configuring proxy support for MultiOn remote sessions isn’t about inventing a new proxy strategy. It’s about respecting session continuity and letting MultiOn’s secure remote sessions and native proxy support do the heavy lifting. Bind each session_id to an appropriate proxy class, keep that binding stable through your Agent API calls, and use Retrieve to turn the browser’s view into JSON instead of wrestling with selectors.

Next Step

Get Started