DEV Community: yooexo

BigCommerce Multi-Storefront vs Separate Stores: Session Isolation With BitBrowser MCP

yooexo — Mon, 26 Oct 2026 12:58:00 +0000

BigCommerce Multi-Storefront (MSF) runs several storefronts from one store: one control panel, one catalog, one list of staff users, and a separate domain for each storefront. Separate stores are the opposite arrangement. Each one is its own subscription with its own store hash, API credentials, staff list and apps.

Both setups are common, and both end up with the same practical problem for developers, QA people and agencies. You need to be signed in to several things at once (an admin, a test shopper on the German storefront, a different test shopper on the US one) without one session overwriting another or leaking into the next test.

This post maps where sessions live in each setup, works out how many isolated browser identities each one needs, and then builds and audits those identities with BitBrowser and its MCP server, so an AI client can create, open and organise them from plain prompts. There are two short Python scripts along the way: one reads your storefronts from the BigCommerce API, the other checks every profile for cookies that belong to a different store.

Two ways to run several storefronts
What Multi-Storefront shares and what it splits
What separate stores give you
Where sessions collide
How many browser profiles each setup needs
Connect BitBrowser MCP
Pull the storefront list from the API
Build the profiles with prompts
Audit every profile for cookie bleed
Test the customer login rules
Mobile checks on cloud phones
Multi-Storefront or separate stores
FAQ

Two ways to run several storefronts

BigCommerce launched Multi-Storefront on 29 March 2022. Before that, a merchant with two brands or three countries usually ran two or three stores and logged in to each one separately.

With MSF, every extra storefront is a channel inside the same store. You add them in Channel Manager by buying storefront seats, and each seat gives you one active and one inactive storefront. The default storefront counts toward that. Only the store owner can buy seats, and the number you can buy is capped by your subscription plan, so check your plan before you design around ten storefronts.

Separate stores need nothing special. A store owner can open several stores on one account from the Account Dashboard, all billed to the same details, and the dashboard signs in with the same credentials as the stores. Each store still runs as its own instance.

Under the hood the difference shows up in the API. An MSF store has one store hash and many channels: channel 1 is the default storefront and can't be deleted, and every Stencil storefront has a site with its own public URL. Separate stores have one store hash each, and every integration has to be set up once per store.

What Multi-Storefront shares and what it splits

BigCommerce's own comparison of single and multi-storefront setups sorts settings into three groups.

Group	Examples
Always per storefront	domain name, storefront status, the message shown when a storefront is inactive
Global by default, can be overridden per storefront	currencies, checkout, SEO, search engine robots, logo and favicon, customer privacy, order notifications, abandoned cart emails
Managed per storefront in Channel Manager	themes, script manager, web pages, social links, home page carousel

Products are shared, but a product has to be assigned to a channel to appear on that storefront. Shipping methods get a Storefronts tab so you can switch each method on or off per storefront. There are limits too, for example up to 25,000 products per storefront.

Two shared things matter most for session isolation.

Staff permissions are global. BigCommerce says user permissions are shared across all storefronts, and you can't set them for one storefront. A staff member who can edit orders can edit orders from every storefront in the store.

Customer accounts can be global or channel-specific. Every customer record has a channel_ids field. When it is null, the customer can sign in to any channel whose allow_global_logins setting is true. When it holds a list such as [2], the customer can sign in only to those channels, whatever the global setting says. New customers start as null, and the default storefront allows global logins out of the box. So in a fresh MSF store, one shopper account works on every storefront unless you change it.

What separate stores give you

Separate stores give you hard walls. Each store has its own staff list, so a contractor who works on your outlet store doesn't see the main brand's orders. Each store has its own API accounts, so a leaked token for one brand can't touch the other. Apps are installed per store, which is more setup work but also means one app's bug stays in one place.

You pay for those walls with repetition. Product data has to be kept in sync between stores by an integration or by hand. Reporting across brands means pulling from several APIs. Every theme change, every script and every app subscription happens once per store.

For session purposes, though, separate stores are simpler to reason about. Nothing is shared, so the only question is how many logins you need open at once.

Where sessions collide

There are three kinds of session in play, and they collide in different ways.

The admin session. In MSF there is one control panel, so one staff login covers every storefront. That is convenient for the merchant. It is a problem for an agency that wants a contractor to work on one storefront only, because global permissions make that impossible inside one store. With separate stores, the merchant can issue a different staff user per store, and an agency often ends up holding several BigCommerce logins of its own: its own user, plus users that clients created for it. A browser keeps one BigCommerce login at a time, so moving between them means signing out and in again.

The shopper session. A Stencil storefront tracks the shopper with a session cookie (SHOP_SESSION_TOKEN) on that storefront's domain. Catalyst storefronts keep the session in an Auth.js cookie instead, starting with authjs.anonymous-session-token before sign-in. Because each MSF storefront has its own domain, two storefronts in the same browser don't share a cart. They do share everything else in that browser, though: the same IP address, the same language headers, the same leftover cookies from last week's test.

The test identity. This is where single-browser testing falls apart. Say the US storefront also sells to Canada, and its Canadian dollar has Canada in the "Default to [currency] in these countries" list. BigCommerce doesn't spell out how it decides where a visitor is, but location usually comes from the IP address, so the reliable way to check that default is to browse through a Canadian proxy. To test that a channel-specific customer is refused on the US storefront, you need a clean session with no earlier login on that domain. Doing both in one browser means clearing cookies between every step and remembering which VPN location you left switched on.

Incognito windows help for one test. They don't help when you want to keep a German test shopper signed in all week while you work on the US checkout.

How many browser profiles each setup needs

Here is a practical count. A "profile" means one isolated browser identity: its own cookies, local storage and proxy.

Setup	Profiles you need	Why
MSF store, internal team	1 admin profile, plus 1 test profile per storefront and customer type	one admin login covers everything; test shoppers need clean, located sessions
Separate stores, internal team	1 profile per store	each profile holds that store's admin and its storefront
Agency with client-issued logins	1 profile per client user	keeps each client's credentials and cookies apart

Take an MSF store with two storefronts (US and Germany), two customer types (global and channel-specific) and one extra check of the US storefront as seen from Canada. That is one admin profile plus five test profiles. For a merchant with three separate stores, it is three.

Connect BitBrowser MCP

The profile count gets annoying to manage by hand around the tenth profile. That is the job the MCP server takes over.

BitBrowser is the tool this guide uses because each profile already carries its own cookies, storage, fingerprint and proxy, and because from version 7.1.5 the desktop app ships an MCP server. Its tool groups cover profiles (create, update, open, close, delete, query), fingerprints, proxies (configure, update, check status), groups, tags, window positions and cloud phones. None of those tools act inside a web page: the agent manages the profiles, and you or your test scripts do the clicking.

To connect it:

Open Settings, then Browser Settings, then Local API.
Switch on Enable Authentication Control and copy the API token.
Add the server to your MCP client.

With Claude Code:

claude mcp add --transport http bitbrowser http://127.0.0.1:54345/mcp \
  --header "x-api-key: YOUR_API_TOKEN"

Cursor, Codex and OpenCode take the same address and header in their own config files. The server listens on your own machine. Keep the token out of prompts, screenshots and repositories, as BitBrowser's guide asks.

Pull the storefront list from the API

Typing storefront URLs into prompts invites typos. The Channels and Sites APIs already know them, so read them from there. You need an API account with read-only access to channels and sites.

"""List the storefront channels and site URLs of one BigCommerce store.

Prints a starter profiles.json: one entry per storefront, with profile_id left
empty so you can fill it in after BitBrowser MCP creates the profiles.
"""
import json
import os
from urllib.parse import urlparse

import httpx

STORE_HASH = os.environ["BC_STORE_HASH"]
TOKEN = os.environ["BC_TOKEN"]
API_ROOT = os.environ.get("BC_API_ROOT", "https://api.bigcommerce.com")
BASE = f"{API_ROOT}/stores/{STORE_HASH}/v3"
HEADERS = {"X-Auth-Token": TOKEN, "Accept": "application/json"}


def get_all(client, path):
    """Read every page of a v3 collection."""
    items, url = [], BASE + path
    while url:
        resp = client.get(url, headers=HEADERS)
        resp.raise_for_status()
        body = resp.json()
        items.extend(body.get("data", []))
        nxt = body.get("meta", {}).get("pagination", {}).get("links", {}).get("next")
        url = BASE + path.split("?")[0] + nxt if nxt else None
    return items


def main():
    with httpx.Client(timeout=30) as client:
        channels = {
            ch["id"]: ch
            for ch in get_all(client, "/channels")
            if ch.get("type") == "storefront"
        }
        sites = get_all(client, "/sites")

    rows = []
    for site in sites:
        channel = channels.get(site.get("channel_id"))
        if channel is None:
            continue
        rows.append({
            "label": f"{STORE_HASH}-ch{channel['id']}",
            "channel": channel.get("name"),
            "status": channel.get("status"),
            "hosts": [urlparse(site["url"]).hostname],
            "profile_id": "",
        })
    print(json.dumps(rows, indent=2))


if __name__ == "__main__":
    main()

Run it once per store hash. For an MSF store you get one row per storefront. For separate stores you get one file per store, which you can merge. Marketplace and POS channels are skipped because they have no site to browse.

Add the admin host to each row by hand if that profile will also hold the control panel login (for example store-abc123.mybigcommerce.com). The audit script later uses the hosts list to decide which cookies belong where. If your admins also preview storefronts from the admin profile, list those storefront hosts in the admin entry too, or the audit will report them.

Build the profiles with prompts

Start the session with a ground rule, then build. These prompts are for the Acme example above: an MSF store with a US and a German storefront.

Before you create, update or delete anything, show me the plan and wait for me to type "go".

Create a group named BC-Acme.

In BC-Acme, create these profiles, each with its own fingerprint:
acme-admin, acme-us-global, acme-us-channel, acme-us-from-ca, acme-de-global, acme-de-channel.

Create tags: bc-admin, bc-test, geo-us, geo-de, geo-ca.

Tag acme-admin with bc-admin and the other five with bc-test. Add geo-de to the two acme-de profiles, geo-ca to acme-us-from-ca and geo-us to acme-us-global and acme-us-channel.

Set a German proxy on the geo-de profiles, a Canadian proxy on the geo-ca profile and a US proxy on the geo-us profiles. Leave every other setting unchanged. Then check the proxy status of all five test profiles.

List every profile in BC-Acme as JSON with id, name and tags.

The "leave every other setting unchanged" line comes from BitBrowser's own advice for partial updates. Without it, an agent may reset fields you didn't mention. If a change doesn't show up in the app, refresh and ask the agent to query the profile again before repeating the command.

Copy the IDs from the last answer into the profile_id fields of your profiles.json. Then sign in by hand: the admin profile gets your staff login, each test profile gets its test shopper. The sessions stay in the profile from then on.

For separate stores, the same pattern gets shorter: one group per merchant, one profile per store, and the admin and storefront hosts of that store in the same profiles.json entry.

Audit every profile for cookie bleed

Profiles keep sessions apart only as long as people use them correctly. The most common slip is opening a different storefront inside the wrong profile, say checking the US checkout from the German test profile "just for a second". From then on that profile carries US cookies, and the next German test isn't clean.

This script opens each profile through BitBrowser's Local API, attaches Playwright over CDP, reads every cookie, and flags the ones whose domain belongs to another entry in profiles.json. A cookie set on a parent domain that covers the profile's own host (like .acme-shop.example) is not flagged.

"""Check that each BitBrowser profile only holds cookies for its own stores.

Exit codes: 0 all clean, 1 at least one profile holds another store's cookies,
2 no leaks found but some profiles could not be checked.
Run it when nobody is working in the profiles: it opens and closes each one.
"""
import json
import os
import sys

import httpx
from playwright.sync_api import sync_playwright

API = os.environ.get("BITBROWSER_API", "http://127.0.0.1:54345")
TOKEN = os.environ.get("BITBROWSER_TOKEN")  # set it if authentication is on
HEADERS = {"x-api-key": TOKEN} if TOKEN else {}


def covers(cookie_domain, host):
    domain = cookie_domain.lstrip(".").lower()
    host = host.lower()
    return host == domain or host.endswith("." + domain)


def foreign_cookies(entry, entries, cookies):
    others = {h: e["label"] for e in entries if e is not entry for h in e["hosts"]}
    found = {}
    for cookie in cookies:
        if any(covers(cookie["domain"], h) for h in entry["hosts"]):
            continue
        for host, label in others.items():
            if covers(cookie["domain"], host):
                found.setdefault(label, set()).add(cookie["domain"])
    return found


def read_cookies(pw, client, profile_id):
    resp = client.post(f"{API}/browser/open", json={"id": profile_id}, headers=HEADERS)
    body = resp.json()
    if not body.get("success"):
        raise RuntimeError(body.get("msg", "open failed"))
    browser = pw.chromium.connect_over_cdp(body["data"]["ws"])
    try:
        return browser.contexts[0].cookies()
    finally:
        browser.close()
        client.post(f"{API}/browser/close", json={"id": profile_id}, headers=HEADERS)


def main(path):
    with open(path) as f:
        entries = json.load(f)
    leaks = skipped = 0
    with sync_playwright() as pw, httpx.Client(timeout=60) as client:
        for entry in entries:
            try:
                cookies = read_cookies(pw, client, entry["profile_id"])
            except Exception as exc:  # keep going, report at the end
                print(f"SKIP  {entry['label']}: {exc}")
                skipped += 1
                continue
            found = foreign_cookies(entry, entries, cookies)
            if not found:
                print(f"OK    {entry['label']}: {len(cookies)} cookies, none from other stores")
                continue
            leaks += 1
            for label, domains in sorted(found.items()):
                print(f"LEAK  {entry['label']}: cookies from {label} ({', '.join(sorted(domains))})")
    sys.exit(1 if leaks else 2 if skipped else 0)


if __name__ == "__main__":
    main(sys.argv[1] if len(sys.argv) > 1 else "profiles.json")

A run against a small profiles.json prints something like this:

LEAK  acme-de-global: cookies from acme-us-global (us.acme-shop.example)
OK    acme-us-global: 9 cookies, none from other stores
SKIP  client-b-admin: profile not found

When a profile leaks, the fix is boring and reliable: clear that profile's cookies for the foreign domain, or delete the profile and let the agent recreate it from the same prompt. The exit codes make the script easy to drop into a weekly scheduled job.

Both scripts were run against local stand-ins for the BigCommerce and BitBrowser APIs (with real Chromium instances holding test cookies), not against a live store, so try them on one profile before pointing them at a client's setup. If you work with attribution across many profiles, there is a longer write-up on cross-profile cookie bleed in multi-account attribution that covers the analytics side of the same problem.

Test the customer login rules

With clean, located profiles, the MSF customer rules become a short test matrix.

Customer	`channel_ids`	US storefront (allows global logins)	DE storefront (global logins off)
Global test shopper	`null`	can sign in	refused
DE-only test shopper	`[3]`	refused	can sign in
Explicit both	`[1, 3]`	can sign in	can sign in

To switch global logins off for one storefront, call the channel settings endpoint:

curl -X PUT "https://api.bigcommerce.com/stores/$BC_STORE_HASH/v3/customers/settings/channels/3" \
  -H "X-Auth-Token: $BC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"allow_global_logins": false}'

Then let the agent lay out the windows so you can read both results at once:

Open acme-us-global and acme-de-global and place them side by side on my main screen.

Close every open profile tagged bc-test.

Sign in with the same test shopper in both windows and compare. Each profile has its own cookies and proxy, so neither login touches the other, and any difference in currency or tax you see comes from the storefront settings and the location, not from a leftover session. Open acme-us-from-ca the same way to check the Canadian dollar default.

Channel IDs above are examples. Read yours from the starter profiles.json.

Mobile checks on cloud phones

Desktop profiles cover most storefront testing, but a mobile checkout behaves differently: smaller layouts, the system keyboard over form fields, and payment sheets that only appear on a real phone browser.

A cloud phone is a remote Android or iOS device you open from your desktop. When BitBrowser is already running your profiles, BitCloudPhone for Android and BitCloudPhone-iOS for iPhone are the natural pick, because the same MCP server that builds your profiles can start and stop the phones too:

Open the cloud phone named qa-android-de.

Shut down every running cloud phone and tell me which ones were on.

Give each storefront market its own phone, the same way you gave it its own desktop profile, and the German mobile checkout stays separate from the US one. Shutting phones down at the end of a session is worth turning into habit, since a forgotten device keeps running.

Multi-Storefront or separate stores

If the brands share most of their catalog and one team runs them, MSF saves a lot of duplicated work. One product update reaches every storefront it is assigned to, one app install covers the store (if the app supports MSF), and reporting starts in one place. Your session setup is one admin profile and a set of test profiles.

Pick separate stores when the walls matter more than the shared work. That usually means different legal entities, different teams that shouldn't see each other's orders, or a contractor who must only touch one brand. Global staff permissions in MSF make that last case impossible inside one store. Your session setup is one profile per store, and there is less to audit.

A mixed setup is normal too. Plenty of merchants run their main brands in one MSF store and keep a wholesale or outlet operation in a store of its own. In that case, give each store its own BitBrowser group and run the cookie audit across all of them, since leaks between stores are the ones that hurt.

FAQ

Does BigCommerce Multi-Storefront share customer accounts between storefronts?
By default, yes. New customers have channel_ids set to null, which lets them sign in to every channel that allows global logins, and the default storefront allows them. Set allow_global_logins to false on a channel, or give customers a specific channel_ids list, to keep accounts apart.

Can I limit a staff user to one storefront in Multi-Storefront?
No. User permissions are global across all storefronts in an MSF store. If a person must only see one brand, that brand needs its own store.

Do two storefronts in one browser share a cart?
Not when they are on different domains, because the session cookie belongs to each storefront's domain. They still share the browser's IP address, language and any leftover cookies, which is what spoils location and login tests.

What does BitBrowser MCP actually do here?
It lets an AI client create, tag, group, open, close and arrange browser profiles and cloud phones, and set or check their proxies. It doesn't click inside pages or sign in for you.

Do I need a separate proxy for every profile?
Only for the profiles where location matters, such as currency and tax tests for a specific country. An admin profile can use your normal connection.

Which MCP clients work with BitBrowser?
BitBrowser's guide lists Claude Code, Codex, Cursor, OpenCode and several others, plus a general configuration for any client that supports custom MCP servers.

Disclosure: I do content work for BitBrowser and BitCloudPhone, and the BitBrowser link in this post is a referral link.

Building a Proxy Health-Check Dashboard for 1000+ Residential IPs

yooexo — Wed, 30 Sep 2026 03:24:00 +0000

A rotating residential pool with 1,000 IPs sounds like abundance until you measure it. On any given hour, 4-7% of the pool is broken: unreachable, geo-drifted, ISP mislabeled, or already on someone else's abuse list. Nobody tells you which ones. Your account gets flagged, you check the proxy provider dashboard, and it shows "all systems operational."

The only fix is your own monitoring stack. This article covers the one that has held up across three production pools: what to check, how often, where to store the data, which Grafana panels actually catch incidents before users do, and how the health signal loops back into the BitBrowser profile fleet so bad IPs stop getting reassigned.

What "proxy health" actually means

Proxy health is not a single metric. It is a rolling composite of five signals, each of which fails independently:

Connectivity. Does the proxy answer a TCP handshake in under 3 seconds?
Egress IP correctness. When you route a request through it, does the destination see the IP the provider promised?
Geolocation accuracy. Does the IP resolve to the country and region the provider claims?
ISP classification. Does the IP register as residential (or mobile) rather than hosting or datacenter?
Reputation status. Is the IP on Spamhaus DROP, on Scamalytics' fraud list, or blocked by Cloudflare's threat score?

A proxy can pass 1-3 and fail 4-5, and the failure is invisible until an account signup gets a CAPTCHA loop or a payment gateway declines the transaction. All five need continuous checks.

The metrics catalog

The dashboard tracks eleven metrics per IP. Nine come from active probes, two from the fleet feedback loop:

proxy_up (0 or 1)
proxy_latency_ms (histogram)
proxy_egress_ip_match (0 or 1)
proxy_geo_country, proxy_geo_region (labels)
proxy_isp_type (residential, mobile, hosting, unknown)
proxy_reputation_score (0-100, lower is worse)
proxy_blocklist_hits (count of lists flagging the IP)
proxy_last_check_timestamp
proxy_bitbrowser_profile_flags_24h (from the fleet feedback loop)
proxy_bitbrowser_session_failures_24h (from the fleet feedback loop)

Eleven metrics, one label set per IP, roughly 11,000 time series for a 1,000-IP pool. Prometheus handles that on a t3.medium without breaking a sweat.

The architecture

   Proxy pool (Proxy-Seller, IPRoyal, Bright Data, ...)
                    │
                    ▼
   ┌───────────────────────────────┐
   │      Check worker (Node.js)   │
   │  ─ Round-robin scheduler       │
   │  ─ HTTP probe (via proxy)      │
   │  ─ Geo lookup (ipinfo.io)      │
   │  ─ Reputation lookup           │
   │  ─ Prometheus /metrics         │
   └───────────────┬───────────────┘
                   │  scrape /metrics every 15s
                   ▼
   ┌───────────────────────────────┐
   │        Prometheus              │
   │  ─ 30d retention               │
   │  ─ Alertmanager rules          │
   └───────────────┬───────────────┘
                   │
                   ▼
   ┌───────────────┴───────────────┐
   │            Grafana             │
   │  ─ Pool overview               │
   │  ─ IP drill-down               │
   │  ─ Provider comparison         │
   └────────────────────────────────┘

One check worker per 500 IPs. Two workers cover a 1,000-IP pool with room to spare. Prometheus scrapes both workers on the same interval so metrics stay aligned.

The check worker

Node.js with axios, prom-client, and a small round-robin queue. The core loop for one proxy:

const axios = require('axios');
const { HttpsProxyAgent } = require('https-proxy-agent');
const client = require('prom-client');

const proxyUp = new client.Gauge({
  name: 'proxy_up',
  help: '1 if the proxy answered, 0 otherwise',
  labelNames: ['proxy_id', 'provider', 'geo_expected']
});

const proxyLatency = new client.Histogram({
  name: 'proxy_latency_ms',
  help: 'Round-trip latency to the probe endpoint',
  labelNames: ['proxy_id', 'provider'],
  buckets: [50, 100, 250, 500, 1000, 2500, 5000]
});

async function checkOne(proxy) {
  const agent = new HttpsProxyAgent(proxy.url);
  const start = Date.now();
  const labels = { proxy_id: proxy.id, provider: proxy.provider, geo_expected: proxy.geo };

  try {
    const res = await axios.get('https://ipinfo.io/json', {
      httpsAgent: agent,
      timeout: 8000
    });
    const elapsed = Date.now() - start;
    proxyUp.set(labels, 1);
    proxyLatency.observe({ proxy_id: proxy.id, provider: proxy.provider }, elapsed);
    return { ok: true, data: res.data, elapsed };
  } catch (err) {
    proxyUp.set(labels, 0);
    return { ok: false, error: err.code || err.message };
  }
}

The probe endpoint is ipinfo.io/json because it returns IP, country, region, city, and ASN in a single call. Free tier gives 50,000 requests per month, enough for a 1,000-IP pool checked every 5 minutes.

Reputation lookups are more expensive. Batch them: pull every distinct IP from the pool once per hour, hit IPQualityScore or Scamalytics in bulk mode, cache results for 60 minutes in Redis. This keeps the reputation API bill under $30/month even at 1,000 IPs.

Storage choice

Prometheus over InfluxDB, TimescaleDB, or Victoria Metrics for a pool this size. Reasons:

The metric cardinality (11 metrics × 1,000 IPs = 11k series) sits comfortably in the middle of Prometheus's sweet spot
Grafana's Prometheus data source is the most polished
The Prometheus query language handles the "IPs currently dead" and "IPs that failed 3 checks in a row" queries in one line each
Alertmanager ships with Prometheus and needs no extra binary

Retention: 30 days. Anything older than a month is not useful for triage and takes up disk. If you need long-term trends, export daily aggregates to a Postgres table and query that instead.

The Grafana dashboard

Four panels. That is it. Adding more panels reduces incident response speed, not increases it.

Panel 1: Pool health heatmap. X-axis is time (last 6 hours). Y-axis is proxy_id. Cell color is proxy_up. A sudden vertical stripe of red means a provider outage. A slowly growing pattern of red dots means IPs are being burned individually.

Panel 2: Failed-probe rate per provider. Line graph, one line per provider (Proxy-Seller, IPRoyal, NetNut, DataImpulse). Y-axis is (1 - avg(proxy_up)) * 100. Any line crossing 8% is a signal to open a support ticket with that provider.

Panel 3: Geo drift table. A table of IPs where proxy_geo_country != geo_expected. If a US IP starts resolving to Panama, remove it from the pool immediately.

Panel 4: Correlation with BitBrowser flags. Scatter plot: X-axis is proxy_reputation_score, Y-axis is proxy_bitbrowser_profile_flags_24h. The cluster of high-flag / low-reputation IPs in the bottom-right is your daily kill list.

Alertmanager rules

Three alerts, no more. Every additional alert dilutes the ones that matter:

groups:
- name: proxy-health
  rules:
  - alert: ProxyPoolDegraded
    expr: (1 - avg by (provider) (proxy_up)) > 0.08
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "{{ $labels.provider }} pool is >8% down for 10 minutes"

  - alert: ProxyGeoDrift
    expr: count(proxy_geo_country != on(proxy_id) group_left proxy_geo_expected) > 20
    for: 5m
    labels:
      severity: warning

  - alert: ProxyReputationCollapse
    expr: avg by (provider) (proxy_reputation_score) < 40
    for: 15m
    labels:
      severity: critical

Route them to a dedicated Slack channel that only fires on proxy issues. Muted-by-default. Anyone whose account gets flagged checks that channel first.

Feeding the signal back into BitBrowser

The dashboard is not the endpoint. It is the input to a decision loop. A small service (also Node.js, also under 300 lines) subscribes to Prometheus queries every 5 minutes and, for any IP flagged as unhealthy:

Calls the BitBrowser LocalAPI to find every profile bound to that IP
Marks each profile as proxy_stale in a local database
Prevents the dispatcher from opening those profiles until a new IP is assigned
Requests a fresh IP from the provider's rotation API
Updates the profile via /browser/update with the new proxy config

This closes the loop. A dying IP takes profiles offline in under 5 minutes instead of after a user complaint. Protocol-level nuances (why HTTP vs SOCKS5 vs Shadowsocks matter here, especially for mobile carrier detection) are covered in this proxy protocol comparison.

Where cloud phones fit in the same pipeline

Mobile pools have a different failure mode: the phone itself can be fine while the carrier's IP block goes on Snapchat's ban list. Extending the dashboard to cover BitCloudPhone Android and BitCloudPhone iOS devices means adding two more probe types:

App-store reachability check. Every 15 minutes, from each cloud phone, hit the App Store or Play Store discovery endpoint. A 403 or 429 means the device's carrier IP is soft-blocked at the app layer, invisible from web-only probes.
In-app CAPTCHA rate. Track how often accounts running on a given device hit CAPTCHAs. Above a threshold, cycle the device.

Both probes return the same Prometheus metric names with a platform=ios or platform=android label. One dashboard covers three worlds.

Scaling notes

The stack above sizes to roughly 5,000 IPs on a single Prometheus instance and a two-worker check fleet. Beyond that:

Layer	Bottleneck	Fix
Check worker	Node event loop under 2,000 concurrent HTTP calls	Split into worker pool via `piscina`
Prometheus	Series cardinality above 100k	Shard by provider onto separate Prometheus instances
Reputation API	Cost per lookup	Extend cache TTL, batch harder, drop reputation for internal-only pools
Grafana	Panel query time above 3 seconds	Add recording rules for expensive expressions

At 10,000 IPs the architecture pattern is the same, the numbers on each box change.

FAQ

Which reputation service is worth paying for?
IPQualityScore for general fraud scoring, Scamalytics for stricter e-commerce use cases, and MaxMind minFraud when payment risk is the specific concern. All three have similar accuracy; the choice comes down to which one your target platforms use themselves.

Can I skip reputation checks entirely?
For internal automation that never touches a payment gateway or an identity-verification vendor, yes. For anything that touches Stripe, Facebook Ads, or account creation on a Tier-1 platform, no. The reputation check catches issues 24-48 hours before the destination platform's own risk engine does.

What if my proxy provider does not expose sticky sessions?
The dashboard still works, but the metric labeling shifts. Instead of proxy_id, label by session_token and expect a much higher series churn. Prometheus handles it up to about 20,000 unique tokens per hour.

How do I probe from the same geo as the proxy claims to be in?
For most checks the probe origin does not matter — ipinfo.io returns the same data whichever direction the query comes from. For app-store and CAPTCHA checks, the probe must originate from the proxy itself; that is what the cloud phone probes cover.

Does this replace the proxy provider's own dashboard?
Yes, and you should stop trusting the provider's dashboard the day you have your own. Provider dashboards report internal health. What matters is what the destination platforms see, and only your own probes measure that.

Where to take it from here

Start with 50 IPs from one provider and the four Grafana panels. Prove the check worker stays under 10% CPU. Prove the alert rules fire on real outages, not on transient blips. Then add the second provider, then the third, then the cloud phone probes.

Every monitoring stack I have shipped in production started as one worker checking one pool with two panels. The stack that tried to cover everything from day one is still in a Git branch nobody merged.

Affiliate disclosure: This post contains affiliate links. If you sign up for a paid BitBrowser or BitCloudPhone plan through the links above, I may earn a small commission at no additional cost to you. All numbers above come from monitoring stacks I run against my own paid accounts.

Wildberries Multi-Seller: A Complete Guide to the Anti-Detect Browser

yooexo — Tue, 18 Aug 2026 17:36:26 +0000

Wildberries blocked over 14,000 seller accounts in Q1 2026 alone, according to their published seller report. Most of those bans weren't for fake products or review fraud. They were triggered by what the platform calls "associated account detection": two or more stores sharing the same device fingerprint, IP range, or browser session data.

If you run more than one Wildberries store, or you're planning to, this guide covers the exact tools and setup that keep accounts isolated. You need an antidetect browser for desktop management, a cloud phone for mobile app access, and a dedicated Russian residential proxy per account. Read on for the specifics.

What is an antidetect browser, and why do Wildberries sellers need one?

A regular browser (Chrome, Firefox, Safari) sends a fingerprint to every website you visit. That fingerprint includes your screen resolution, installed fonts, canvas rendering hash, WebGL vendor string, time zone, language settings, and about 40 other parameters. Wildberries logs this fingerprint when you log into the seller portal.

Open a second Wildberries seller account on the same device and the same browser, the fingerprint matches. Their system flags both accounts as related and suspends them simultaneously.

An antidetect browser solves this by creating isolated browser profiles, each with its own fabricated fingerprint. Account A runs in Profile 1, which shows a Windows 10 machine with a 1920×1080 screen, Calibri font, and a specific canvas hash. Account B runs in Profile 2: different OS, different screen resolution, different canvas signature. Each profile stores cookies and local storage separately, so there's no bleed between sessions.

The antidetect browser doesn't just change the user-agent string. That's what incognito mode does, and it doesn't work. It replaces the entire device identity at the API level.

How Wildberries actually detects related seller accounts

Before setting up anything, it helps to know what you're defending against. Wildberries' association detection looks at several layers:

Browser fingerprint matching. Canvas hash, WebGL renderer, AudioContext fingerprint, font enumeration, and screen parameters. Two accounts with identical values on three or more of these get flagged automatically.

IP address correlation. Two accounts logging in from the same IP address on the same day is a hard trigger. Even if the fingerprints differ, shared IPs create an "association chain" in their system.

Cookie and localStorage sharing. If your browsers share session cookies (common when running multiple tabs), account A's session data can leak into account B's requests. Regular Chrome profiles don't isolate these.

Behavioral timing patterns. Wildberries tracks login times. If Account A and Account B both log in every morning between 9:00 and 9:05 Moscow time from the same approximate IP range, their system marks that as suspicious even without a direct fingerprint match.

Payment method overlap. Accounts that list the same bank card, phone number, or OGRN get linked in their seller database regardless of technical isolation. This one has nothing to do with browsers. It's a business data problem.

A proper antidetect browser handles the first three. A proxy handles the fourth (partially). Business data separation handles the fifth.

Which antidetect browser works best for Wildberries in 2026?

BitBrowser is the strongest option for Wildberries multi-seller setups right now, and it holds that position for three specific reasons.

First, it supports Russian-locale fingerprints natively. You can set the browser language to ru-RU, the time zone to Europe/Moscow, and the keyboard layout to Russian inside each profile. When Wildberries reads your browser's navigator.language property, it gets ru-RU instead of something that contradicts your Russian IP. Mismatched locale and IP is one of the easier ways to get flagged.

Second, BitBrowser has a free tier with up to 10 profiles. That covers most Wildberries multi-sellers who run 3 to 8 stores. You don't need to pay to test the setup or run a small operation. Paid plans start at around $10 per month for more profiles and team access features.

Third, it passes standard fingerprint audit tools. Running a fresh BitBrowser profile through BrowserLeaks, CreepJS, and Pixelscan should show no automation flags, no WebDriver property exposed, and no canvas or WebGL anomalies. Test this before you log into any real account.

The setup process for a Wildberries profile in BitBrowser takes about 4 minutes:

Create a new profile. Name it after the store (e.g., "WB Store 2: Electronics").
Set OS to Windows 10 or Windows 11. Russian sellers overwhelmingly use Windows, so matching that reduces fingerprint suspicion.
Set language to ru-RU, time zone to Europe/Moscow.
Assign your proxy (covered in the next section).
Open the profile, go to browserleaks.com, and confirm the IP, locale, and time zone all match before logging in.

One thing to do before running the profile: open chrome://settings/ inside the profile and disable any auto-fill or sync features. BitBrowser profiles are isolated from Chrome sync, but disabling it explicitly prevents unexpected data requests.

What proxy setup do you need for Wildberries accounts?

The proxy choice matters as much as the browser. A good antidetect browser with a bad proxy still gets flagged. For Wildberries, the rules are clear:

Use Russian residential proxies. Wildberries is headquartered in Moscow and most of its seller base operates from Russian ISPs. A login from a US datacenter IP triggers immediate scrutiny. A residential IP from Rostelecom or MTS looks like a normal Russian internet connection.
One dedicated IP per account. Shared proxy pools rotate IPs between users, which means Account A might occasionally get the same exit IP as another seller's Account B. Dedicated IPs cost a bit more but the isolation is worth it for accounts generating real revenue.
For mobile app access, use Russian mobile proxies. 4G proxies from Russian mobile carriers (MTS, Megafon, Beeline) give you a mobile ASN, which matches the expected IP type when logging in through a phone or cloud phone.

This dev.to article covers how to architect proxy rotation if you're managing a larger number of accounts programmatically:

Digital Growth Pro

Jan 13

Building a Proxy Rotation System for Web Automation: Architecture Patterns and Implementation

#webdev #javascript #proxy #automation

8 min read

For manual multi-seller setups, you just need static residential IPs, one per account.

Assigning the proxy in BitBrowser:

In the profile settings, click the Proxy tab.
Select SOCKS5 (preferred) or HTTP.
Enter the IP, port, username, and password from your proxy provider.
Save, then click Check Proxy inside BitBrowser. It shows you the resolved IP and country. Confirm it shows RU before using the profile.

Do you need a cloud phone for Wildberries?

Desktop browser management covers the Wildberries Partner Portal (partners.wildberries.ru) but the mobile app is a separate channel. Many sellers use the Wildberries Seller app on iOS or Android to handle order fulfillment, buyer messages, and listing updates. The app fingerprints the device separately from the browser: UDID, device model, OS version, and screen resolution.

Log into two different Wildberries seller accounts from the same physical iPhone and those accounts get linked at the device level. The fix is a cloud phone: a virtual mobile device hosted remotely, with its own isolated device identity and a separate IP assignment.

BitCloudPhone (Android) and BitCloudPhone iOS handle this for Wildberries sellers. Each cloud phone instance has its own device fingerprint, its own app environment, and accepts its own proxy assignment. You run it from your regular browser and it presents as a completely separate physical device to Wildberries.

The iOS version specifically matters for the Russian market because iOS penetration among Russian e-commerce buyers and sellers is high. Wildberries iOS app updates ship regularly and sometimes add new device checks. BitCloudPhone iOS keeps pace with those updates. You're not jailbreaking a phone or running an emulator that an app can detect as virtual. The cloud phone environment is designed to look like real device hardware.

For a Wildberries multi-seller operation running 5 stores, the typical setup is:

Component	Tool	Per account
Partner Portal (desktop)	BitBrowser profile	1 Russian residential IP
Mobile seller app	BitCloudPhone iOS	1 Russian 4G mobile IP

You access both from the same laptop. The cloud phones are remote, so there's no local hardware fingerprint from your actual machine.

What account-level separation does Wildberries require?

Technical isolation through an antidetect browser gets you past fingerprint detection. Business data separation keeps you clean at the account-record level. These are different problems.

For each Wildberries seller account, Wildberries stores: the seller's legal entity (IP or OOO), the OGRN/OGRNIP number, the bank account tied to payouts, the phone number for verification, and the email address. Accounts sharing any of these get linked in Wildberries' seller database regardless of how well your browser profiles are isolated.

Each store needs:

Its own phone number for SMS verification
Its own email address (different domain if possible; similar patterns like store1@gmail.com and store2@gmail.com draw less scrutiny than exact matches, but separate domains are cleaner)
Its own payout bank card or account
Its own legal entity (IP or OOO registration with a unique OGRN)

Most Russian multi-sellers operating legally use separate sole proprietor (IP) registrations or different OOO entities. The point is that the paper trail for each account has to be genuinely distinct.

How to warm up a new Wildberries seller account

Wildberries treats brand-new seller accounts with a lower trust score. Account-association detection is more sensitive during the first 30 days. Three things help here:

Log in gradually at first. Don't open all 5 accounts on day one. Start with one, let it run for a week with normal activity, then add the second account, and so on. Accounts that start simultaneously from different profiles on the same day raise a pattern flag.

Match your activity hours to the account's supposed location. If the account's store is listed as being based in Novosibirsk (UTC+7), seller login activity should happen during Novosibirsk business hours, not 2:00 AM Moscow time. BitBrowser lets you set the time zone per profile. Use it.

Don't copy listings between accounts during the warm-up period. Two accounts listing the exact same product with the exact same title, photos, and description on the same day. Wildberries' content matching system flags them as related. Differentiate the listings even for the same product: different main image, different title structure, different keyword emphasis.

Browser automation for Wildberries: is it worth it?

Some sellers automate Wildberries seller tasks: bulk listing uploads, price updates, stock adjustments. BitBrowser exposes a local REST API that automation tools can call to create profiles, assign proxies, and open sessions. You can build scripts using Selenium, Playwright, or Puppeteer that connect to BitBrowser's existing browser instances rather than launching a detectable headless browser.

The advantage of going through BitBrowser's API rather than directly launching Playwright is that the browser instance already has a full human fingerprint. A standard playwright.chromium.launch(headless=True) exposes the navigator.webdriver flag that Wildberries can read. A session launched through BitBrowser's API inherits the profile's fingerprint and doesn't set that flag.

This dev.to article walks through the technical connection pattern for setting up automated sessions with real fingerprints:

Digital Growth Pro

Apr 16

BitBrowser + Selenium: Setting Up Automated Browser Sessions with Real Fingerprints

#selenium #webdev #automation #security

6 min read

For most Wildberries multi-sellers, full automation isn't necessary. Manual management of 5 to 8 accounts through BitBrowser profiles takes maybe 90 minutes per day across all stores. Automation becomes worthwhile at 15+ accounts or when you need bulk price updates across hundreds of SKUs.

What happens if one account gets flagged?

Set up proper isolation and one account still gets a warning or temporary suspension, the other accounts shouldn't be dragged down with it. That's the entire point of isolation. With a proper antidetect browser setup and separate proxies:

The flagged account's cookie data doesn't exist in other profiles
Each account's IP is dedicated, so it can't be traced to other accounts' IPs
Each profile fingerprint is unique, so Wildberries can't find matches to other stores

The investigation stays contained. You lose one account, not all five.

Without isolation, running everything on Chrome with a VPN toggle means a single suspension investigation can unravel every related account, because Wildberries can trace the shared fingerprint and IP history through their logs. That's how sellers lose entire portfolios at once.

Russian marketplace multi-account management: same rules apply

Everything covered here transfers to Ozon, Avito, and Yandex Market. All three use fingerprinting and IP correlation to detect related accounts. That antidetect browser + Russian residential proxy + separate business data stack works across all of them.

Wildberries differs from those platforms in one specific way: the mobile app requirement. More Wildberries sellers manage day-to-day operations through the app than through the Partner Portal web interface. That's why the cloud phone component matters more for Wildberries than it does for Ozon, which has a more complete web-based seller interface.

For sellers managing accounts on multiple Russian marketplaces simultaneously, one practical approach is to extend the naming convention: "WB Store 1," "Ozon Store 1," "Avito Account 1": each gets its own BitBrowser profile and its own proxy, clearly labeled so there's no confusion about which account is active in which profile.

What does a full Wildberries multi-seller setup cost?

Here's a rough monthly cost breakdown for running 5 stores:

Item	Monthly cost
BitBrowser paid plan (10+ profiles)	~$10–$20
5 dedicated Russian residential proxies	~$30–$60
BitCloudPhone iOS (5 instances)	varies by plan, check here
5 virtual phone numbers for verification	~$5–$15
Total	~$50–$120

Against the revenue that 5 active Wildberries stores generate, that's a small operational cost. Losing all accounts to a single suspension wave costs significantly more.

FAQ

What is an antidetect browser and why do Wildberries sellers need one?

An antidetect browser replaces your real device fingerprint with a separate, isolated profile for each session. Wildberries uses fingerprinting to detect related accounts sharing the same device. Running two stores from one regular browser gets both flagged. BitBrowser assigns each store its own unique fingerprint, so the platform sees two completely different devices.

How many Wildberries accounts can I safely run with BitBrowser?

BitBrowser's free tier supports up to 10 isolated profiles. Paid plans start around $10/month and scale to hundreds of profiles. Most Wildberries multi-sellers run 3 to 8 accounts per operator without issues, pairing each profile with a dedicated Russian residential IP.

Do I need a cloud phone to manage Wildberries accounts?

Not for the Partner Portal, but yes for the mobile seller app. The iOS and Android apps use device fingerprinting that a desktop browser can't replicate. BitCloudPhone and BitCloudPhone iOS give each account a completely separate device identity, without needing multiple physical phones.

Which proxy type works best for Wildberries multi-seller accounts?

Russian residential proxies, one dedicated IP per account. For mobile app access, Russian 4G mobile proxies match the expected mobile ASN. Shared proxies and datacenter IPs both get flagged faster for Wildberries seller logins.

Can Wildberries detect BitBrowser?

BitBrowser is designed to pass standard fingerprint tests including BrowserLeaks, CreepJS, and Pixelscan. The key is pairing each browser profile with a matching residential proxy and not reusing fingerprint parameters across accounts. Test every new profile before using it on a real account.

Is using multiple Wildberries accounts against the platform's rules?

Wildberries prohibits one legal entity from operating multiple accounts to exploit promotional systems. Separate legal entities operating separate stores is common practice. The requirement is true isolation: different IPs, different devices or browser profiles, different payment methods, and no shared registration data.

What is BitCloudPhone iOS and how does it help Wildberries sellers?

BitCloudPhone iOS is a cloud-hosted iPhone environment. Each instance has its own iOS device fingerprint, UDID, and IP. For sellers managing orders through the iOS Wildberries app, it removes the need for multiple physical phones. Assign a Russian mobile IP and it presents as a real Russian iPhone to Wildberries.

How do I set up a Russian residential proxy in BitBrowser?

Open your BitBrowser profile settings, go to the Proxy tab, select SOCKS5, paste in your IP:port:user:pass, and set the location tag to RU. Save and run a leak test at browserleaks.com before logging into any Wildberries seller account. The IP shown should be a Russian residential address, not a datacenter range.

Wrapping up

Wildberries' detection systems have gotten more precise over the past 18 months. Sellers getting caught aren't running 10 accounts behind a VPN (Wildberries handled that threat years ago). Sophisticated operators are losing accounts now because they missed one layer of isolation: a shared mobile device, a proxy pool that occasionally assigns duplicate IPs, or business registration data that creates a traceable link between otherwise technically separated accounts.

BitBrowser profiles with Russian residential IPs for the Partner Portal, BitCloudPhone iOS instances with Russian 4G IPs for the mobile app, and genuinely separate business registration data per account. This closes those gaps. Start with the free BitBrowser tier to validate the fingerprint isolation before investing in cloud phones, then scale once you've confirmed the setup passes fingerprint tests.

For a wider comparison of antidetect browsers beyond Wildberries use cases:

Best Anti-Detect Browsers in 2026: Why BitBrowser Took the Top Spot This Year - GoToProxy - Expert Proxy Service Reviews & Privacy Tools

Best Anti-Detect Browsers in 2026: Why BitBrowser Took the Top Spot This Year A hands-on ranking of the 5 anti-detect browsers we tested across 26,400 profiles,

gotoproxy.com