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

Most teams only care about proxies once something starts getting blocked: 403s, endless captchas, or “unusual activity” warnings in the middle of a checkout flow. If you’re running MultiOn agents against login-heavy sites with real bot protection, you want proxy behavior to be explicit, testable, and tied to the same unit of reliability as everything else in MultiOn: the remote session.

Below is how I’d approach configuring proxy support for MultiOn remote sessions when you’re targeting sites with bot protection, plus the operational habits that keep those sessions alive in production.

Why proxy support matters for MultiOn remote sessions

MultiOn’s Agent API (V1 Beta) executes in secure remote sessions—real browser instances you control through calls like:

POST https://api.multion.ai/v1/web/browse
X_MULTION_API_KEY: <your-key>
Content-Type: application/json

You send a cmd + url, MultiOn runs the actions in a remote browser, and you get back:

A session_id to keep the workflow alive across steps (e.g., login → add to cart → checkout).
A snapshot of the state and any structured data you requested (via Retrieve).

For sites with bot protection, you need:

A stable network identity for a given session, so risk engines don’t see you “teleporting” between IPs.
Alignment between your proxy strategy and the site’s trust model (region, ASN, residential vs datacenter).
Back-pressure or failure detection when a particular proxy/IP gets flagged.

MultiOn’s native proxy support is built for that: you configure which egress behavior you want, the platform runs the secure remote session behind that network, and your session_id continuity keeps the identity consistent across calls.

The core pattern: session continuity + proxy stability

The critical pattern for sites with bot protection is:

Start a session behind a consistent proxy profile.
Reuse the returned session_id for all subsequent Agent API calls in that workflow.
Avoid mixing proxy strategies for the same session_id; treat “proxy changed mid-session” as a bug.

At a high level, the lifecycle looks like:

Initialize session (optionally with a specific proxy strategy).
Step through critical flows (login, wishlist navigation, cart operations, checkout).
Retrieve structured data as needed (product metadata, order status).
Terminate or reuse session based on your app’s UX and risk tolerance.

You wire proxy behavior into the step where you create or first use the session.

Configuring proxy support in MultiOn remote sessions

Implementation details will evolve as MultiOn exposes more fine-grained controls, but there are three practical models you should design for.

1. Use MultiOn’s native proxy support (default for most teams)

When you don’t pass any custom proxy configuration, MultiOn’s infrastructure handles egress for you. For many sites, especially those with moderate bot protection, this is enough—MultiOn’s secure remote sessions and “native proxy support” are tuned for general reliability.

Example web/browse call using the default routing:

POST https://api.multion.ai/v1/web/browse
X_MULTION_API_KEY: <your-key>
Content-Type: application/json

{
  "url": "https://www.amazon.com",
  "cmd": "Search for 'noise cancelling headphones' and open the first product page."
}

Sample response (truncated):

{
  "session_id": "sess_abc123",
  "status": "ok",
  "result": {
    "pageTitle": "Amazon.com: noise cancelling headphones",
    "currentUrl": "https://www.amazon.com/..."
  }
}

Under the hood:

MultiOn picks an appropriate outbound path.
The session_id pinches together browser state and network identity.
Bot protection sees a consistent client across subsequent calls that reuse session_id: "sess_abc123".

When this is enough:

You’re targeting mainstream ecommerce or SaaS sites.
You don’t need strict regional control (e.g., “must appear EU-based”).
You just want your brittle Playwright/Selenium scripts to go away.

2. Attach a proxy profile per session (for region/ASN-sensitive sites)

Some sites adjust bot scores based on geolocation, ISP, or ASN. For those, you want to bind your MultiOn session to a proxy profile that matches what a “real” user looks like for that service.

MultiOn’s network layer is designed to support “native proxy support” for tricky bot protection. The recommended pattern is:

Treat proxy selection as a session-level attribute.
Choose the profile at session creation (first call).
Reuse that session_id without changing the profile.

Conceptually, your call might look like this (pseudo-parameters; exact shapes follow your account’s proxy configuration options):

POST https://api.multion.ai/v1/web/browse
X_MULTION_API_KEY: <your-key>
Content-Type: application/json

{
  "url": "https://www.lululemon.com",
  "cmd": "Open my wishlist page.",
  "proxy": {
    "region": "us",
    "type": "residential",
    "pool": "lululemon_checkout_pool"
  }
}

Response:

{
  "session_id": "sess_lulu_001",
  "status": "ok"
}

Every subsequent call in that checkout flow:

POST https://api.multion.ai/v1/web/browse
X_MULTION_API_KEY: <your-key>
Content-Type: application/json

{
  "session_id": "sess_lulu_001",
  "cmd": "Add the most recently saved wishlist item to cart."
}

Key behaviors you want to enforce in your integration:

No mixing sessions across proxies. Don’t reuse sess_lulu_001 for a different region or pool.
No proxy changes mid-session. If you need to rotate, treat it as a new session and log out the old one.

Explicit mapping in your app. For example, store:

{
  "user_id": "user_123",
  "session_id": "sess_lulu_001",
  "proxy_profile": "lululemon_us_residential"
}

That way, your backend always knows which network identity a given session_id is supposed to use.

3. Rotate proxies across sessions, not steps (for scaling and risk management)

When you scale to many concurrent agents, you need to avoid both:

Overusing a single IP and triggering rate limits.
Rotating so aggressively that each user/session looks suspicious.

The correct unit of rotation is the session, not the HTTP call. A resilient pattern looks like:

Pick a proxy profile (e.g., “EU retail pool”).
Allocate it to a new MultiOn session.
Run the entire workflow behind that profile.
Retire the session and potentially the IP after a configurable number of workflows or time.

In code/pseudocode:

// 1. Select a proxy profile for this new workflow
const proxyProfile = selectProxyProfile("hm_eu_checkouts");

// 2. Start a MultiOn session using that profile
const session = await browse({
  url: "https://www2.hm.com/en_eur/index.html",
  cmd: "Open the women's dresses category.",
  proxy: proxyProfile
});

// 3. Step through the flow, reusing session_id
await browse({
  session_id: session.session_id,
  cmd: "Filter for 'black' dresses under 50 EUR and open the first result."
});

// 4. Use Retrieve to get structured data from the product page
const extraction = await retrieve({
  session_id: session.session_id,
  cmd: "Extract product name, price, available sizes, colors, and main image URL as JSON.",
  renderJs: true,
  scrollToBottom: true,
  maxItems: 1
});

Here, proxy rotation happens at the “new session for new workflow” boundary, not at each browse call.

Bot protection–aware configuration strategies

If you’re coming from Playwright/Selenium, think of MultiOn’s secure remote sessions as “headless Chrome + network stack you don’t have to own.” For sites with serious bot protection, you still need to design a strategy.

I typically follow these steps.

1. Align proxy geography and device posture

Bot systems cross-check:

IP geolocation vs shipping address vs billing address.
IP ASN vs expected device (mobile vs desktop).
Historical behavior from that IP pool.

With MultiOn:

Use proxy profiles that match your user base (e.g., US for Amazon US).
Keep mobile-style flows behind IPs that look reasonable for that device posture if you’re mixing with mobile control surfaces.
Avoid “exotic” locations unless your product actually has users there.

2. Treat captchas and 4xx as observability signals

MultiOn will surface HTTP-level failures and errors like “402 Payment Required” in its responses. For bot protection:

Watch for repeated 403 / 429 / captcha pages in the returned HTML or status.
If a specific proxy profile starts failing, mark it unhealthy and stop creating new sessions with it.
Expose these metrics in your own observability stack: bot_block_rate per proxy pool, per site.

You can implement a simple circuit breaker around proxy pools:

if (metrics.botBlockRate("lululemon_us_residential") > 0.2) {
  markPoolUnhealthy("lululemon_us_residential");
  routeNewSessionsTo("lululemon_us_residential_backup");
}

3. Avoid “hard-reload loops” that look like bots

Remember: MultiOn is operating a real browser. If your cmd patterns cause:

Rapid back/forward navigation.
Many identical searches in a short time.
Unnecessary page reloads.

…you look more like a bot.

Keep commands high-level and purposeful:

Good: cmd: "Log in using the stored credentials and go to my wishlist page."
Bad: cmd: "Reload the page until prices change."

You still get the reliability of a real browser, but you avoid tripping rate-based defenses.

Working with Retrieve behind bot protection

MultiOn’s Retrieve endpoint is your tool to turn dynamic, JavaScript-heavy pages into structured JSON arrays of objects. On bot-protected sites, you almost always want to:

Establish a session and pass through any required auth/flows.
Then call Retrieve with that session_id so extraction happens in the already-trusted session context.

Example sequence against an H&M-like catalog:

POST https://api.multion.ai/v1/web/browse
X_MULTION_API_KEY: <your-key>
Content-Type: application/json

{
  "url": "https://www2.hm.com/en_eur/women/products/dresses.html",
  "cmd": "Open the women's dresses category.",
  "proxy": {
    "region": "eu",
    "type": "residential",
    "pool": "hm_eu_catalog_pool"
  }
}

Response:

{
  "session_id": "sess_hm_001",
  "status": "ok"
}

Now extract:

POST https://api.multion.ai/v1/web/retrieve
X_MULTION_API_KEY: <your-key>
Content-Type: application/json

{
  "session_id": "sess_hm_001",
  "cmd": "Return a JSON array of objects with fields: name, price, colors, productUrl, imageUrl for visible dresses.",
  "renderJs": true,
  "scrollToBottom": true,
  "maxItems": 50
}

Retrieve benefits from the same proxy/session identity that loaded the catalog page, which:

Reduces bot-protection surprises (no new fingerprint).
Lets you paginate or scroll deeper while staying “the same user.”

Operational checklist for MultiOn proxy support

When you wire this into a production system, treat proxy + session as first-class configuration, not an afterthought. My go-to checklist:

Design the session model
- Map user or workflow → session_id + proxy_profile.
- Decide session lifetime (per request, per flow, per user).
Define proxy pools per site
- E.g., amazon_us_residential, lululemon_us_residential, hm_eu_catalog_pool.
- Encode region and type in the name for debugging.
Enforce proxy consistency
- On any web/browse with session_id, assert that the proxy profile matches what you initially assigned.
- If you must change proxy, create a new session.
Instrument failures
- Log 4xx/5xx by site and proxy pool.
- Track captcha hits and unusual redirects.
- Alert on sudden spikes in blocks.
Throttle aggressive patterns
- Add rate limits on how often a single user/workflow can hit the same path.
- Back off or change behavior when sites start returning warnings.

How to integrate this into your app today

To get practical:

Install and configure MultiOn
- Add the SDK or call the raw HTTP endpoints.
- Store X_MULTION_API_KEY securely.
Create a session wrapper
- A small service that:
  - Allocates a proxy profile.
  - Calls POST /v1/web/browse to start a session.
  - Returns session_id and records the mapping.
Build site-specific workflows
- For Amazon, Lululemon, H&M, etc., define high-level cmd sequences.
- Use Sessions + Step mode for multi-step flows (login → wishlist → cart → checkout).
- Use Retrieve for structured JSON outputs where you used to maintain brittle selectors.
Iterate on proxy strategy
- Start with MultiOn’s default native proxy behavior.
- Introduce site-specific proxy profiles as you hit bot limits.
- Fold metrics back into your routing logic.

With this approach, proxy support in MultiOn stops being a guessing game and becomes another explicit lever in your remote session design. You keep intent in, actions executed in a real browser, and structured JSON out—without turning your team into a proxy and selector maintenance shop.

Next Step

Get Started