One Egress IP Per Seller Account: Why Multi-Account Marketplace Integrations Need It

You build a marketplace integration. It runs on one host. It authenticates as twenty different seller accounts and calls the same APIs for each. From your side that's clean, efficient architecture — one deployment, one set of logs.

From the marketplace's side, twenty ostensibly independent businesses are making authenticated API calls from a single IP address, on a schedule, around the clock.

Marketplaces track IP behaviour per account, and shared infrastructure is one of the signals used to relate accounts to each other. Whether that matters to you depends entirely on your situation — a single brand running several of its own storefronts, an agency operating client accounts under proper authorisation, and someone running accounts that are supposed to look unrelated are three very different cases with three very different risk profiles. But in every case, the architectural answer is the same: each account egresses through its own dedicated, stable IP.

The instinct is to reach for a rotating proxy pool. That's the wrong tool. A seller account whose API calls arrive from a different IP every hour, in a different city each time, looks stranger than one that shares an IP with a sibling account.

What you want is boring: one static IP, assigned to one account, that doesn't change, and ideally in a location consistent with where that business actually operates. Rotation is for scraping. This is the opposite problem.

That means the product category you're buying is a static ISP proxy — a residential-class address held long-term — not a datacentre rotating pool, and not a residential rotating pool. This distinction is where the money and most of the mistakes are.

Provisioning APIs for proxy providers tend to be forgiving in the worst way: omit a field and you get a working zone of the wrong type, with no error.

The specific shape of the trap, which generalises across providers:

• Omitting the pool type silently gives you datacentre IPs. The zone is created, the API returns success, requests route fine — and you've bought exactly the category of address you were trying to avoid. Always set the pool type explicitly, and verify it by reading the zone back rather than trusting the create response.
• Allocation calls often need a customer identifier that the docs treat as optional. Omit it and you get a 400 that reads like a malformed request rather than a missing account context.
• Releasing an IP stops the next billing cycle, not the current one. Release something mid-cycle and you keep paying for it until the cycle turns. Deprovisioning is not immediate cost relief, and budgeting as though it is will surprise you.

Treat the provider's list endpoint as your source of truth, not your own database. Reading back the actual set of allocated IPs is usually free, so reconcile against it on a schedule and alert on drift.

Here's the one that will actually bite you, and it has nothing to do with networking.

IP allocation is a billed operation. If the provider account's balance runs low, or the payment method lapses, allocation calls start failing — and they fail per-account, quietly, at the moment you onboard a new seller. The existing accounts keep working, because their IPs are already allocated. So the system looks healthy while every new account silently comes up without a dedicated IP, falling back to the shared server address.

Which is precisely the state you built the whole mechanism to avoid, arrived at without a single error in your application logs.

Two defences:

• Make "account without a dedicated IP" a first-class alert, not an inferred condition. It should be a query you run on a schedule and surface in your health dashboard, with a retry action next to it.
• Monitor the provider balance the way you'd monitor disk space. It's a dependency that fails closed and gives you no application-level signal.

Routing every API call through a third-party proxy adds a hop, and that hop has its own failure modes. The one to plan for is a mid-sync connection drop on long paginated pulls — an SSL EOF partway through fetching thousands of records, even when the proxy itself is perfectly healthy and probe calls succeed.

Don't treat that as an account-level failure. A single transient network error shouldn't leave a red error state on a seller's account card until the next scheduled run hours later. Retry the operation once after a short delay, log a warning, and only escalate if the retry also fails. The difference between "occasional warning in the logs" and "account looks broken all afternoon" is one retry.

The same discipline applies to marketplace throttling generally — see how to pace requests so you stop hitting rate limits, which shares the underlying principle: retry deliberately, with backoff, and distinguish transient from terminal.

Why do multiple seller accounts need separate IP addresses?

Marketplaces track API and login behaviour per account, and a shared IP is one of the signals used to relate accounts to one another. Routing each account through its own dedicated egress IP keeps that signal clean. Whether it matters depends on your situation, but the architecture is the same either way.

Should I use rotating proxies for marketplace APIs?

No. Rotation is designed for scraping. For authenticated seller-account API traffic you want the opposite: one static IP per account that stays the same over time, ideally consistent with where the business operates.

What kind of proxy should I buy for this?

Static ISP or residential-class addresses held long-term and dedicated to you — not a rotating pool and not datacentre addresses. Check the pool type explicitly when provisioning, because omitting it frequently defaults to datacentre without any error.

Why did new seller accounts stop getting dedicated IPs?

Most often the proxy provider account is out of funds or its payment method has lapsed. Allocation is a billed call, so it fails at onboarding time while existing accounts keep working on their already-allocated IPs — meaning the system looks healthy while new accounts silently fall back to a shared address.

Does releasing an IP stop the charges immediately?

Usually not. With most providers, releasing an IP stops billing from the next cycle, so a mid-cycle release still incurs the remainder of the current period.