Proxies for Retail Arbitrage and Reselling

Retail arbitrage means buying a product cheaply at one retailer and reselling it higher on a marketplace. Online arbitrage is the same idea run from a screen instead of a store aisle: you find the gap in data rather than by walking clearance shelves. Either way, the edge is information. The sourcers who win are the ones who know, faster and more accurately than everyone else, where a real spread exists right now.

That makes sourcing a pipeline, not a hobby. A barcode-scanning app in one store checks a few dozen items an hour and only sees that store. A data pipeline checks thousands of SKUs across many retailers on a schedule and flags the ones worth buying. The moment you scale past a single location, you are scraping public price and stock pages, and the moment you scrape at scale from one office IP, retailers start rate-limiting and blocking you. That is the point where proxies stop being optional.

One clarification up front, because it decides everything about how you build. This is research and monitoring, not automated buying. Reading a public price page is a different activity from scripting a checkout to grab limited stock, which is the sneaker-bot pattern covered in datacenter proxies for sneaker botting and retail automation. Arbitrage sourcing needs accurate data at scale. It does not need, and should not use, a bot that clicks "buy" for you.

The whole operation reduces to a loop with five stages. The spread is the product. Everything else is plumbing.

1. Read the buy side. Pull retailer A's current price, the strikethrough "was" price, any clearance or rollback flag, and stock status, scoped to the store that actually serves your buying location.
2. Read the sell side. Pull marketplace B's current sell price (the Buy Box on Amazon, the lowest active listing on eBay), how many sellers are competing, and a demand signal like sales rank.
3. Net out the fees. Subtract the marketplace referral fee, the fulfillment fee, inbound shipping, prep, and the buy cost itself. What remains is net profit, not gross spread.
4. Gate the candidate. Keep only SKUs above a net-margin threshold and above a velocity threshold. A fat margin on an item that sells twice a year ties up cash.
5. Monitor. Watch the survivors for the price drop or restock that turns a "maybe" into a "buy now," because those windows are short.

Skip stage three and you will chase discounts that evaporate the second real fees hit. A product marked down from $50 to $20 looks like a $19 spread against a $39 resale price. After a 15 percent referral fee, a $5.50 fulfillment fee, shipping, and prep, that same deal can net under $3. The discount is loud. The margin is quiet. Sourcing tools that show you the discount and hide the fees are selling excitement, not profit.

Here is the asymmetry that most arbitrage guides never mention, and it is the reason proxies matter for this use case specifically.

Clearance is local. Retailers mark down overstock store by store and region by region, because the excess inventory sits in specific buildings. A shelf tag that reads $8.00 clearance at the store serving one zip code is often $24.00 full price at a store two states away, or simply not carried there. Retailer websites mirror this: many resolve price and stock to the store nearest the location you give them, the same store-scoped behavior described in proxies for grocery and delivery price data. The buy price you can actually get is a local fact.

The resale price is roughly national. When you list that item on a large marketplace, the Buy Box price is close to uniform across the country. Buyers everywhere see about the same number.

Put those together and the spread you can capture depends entirely on reading the localized buy price correctly. Scrape a retailer from a datacenter IP with no location set and the site geolocates you to a default metro or refuses to resolve a store at all, so you see a national or fallback price. Two failure modes follow. You miss real clearance because the deal store never loaded, or you chase a phantom deal because the price you read belongs to a store you cannot buy from. A geo-consistent residential IP in the target metro, plus the store or zip set in the session, is what makes the buy price you read the buy price you can pay. This is geo-targeting applied at store grain rather than country grain.

Net profit is the only number that decides a buy. Gross spread is a headline. Here is a worked example for a single unit sourced on clearance and resold through a marketplace fulfillment program.

The formula behind the table:

net_profit = sell_price
           - referral_fee
           - fulfillment_fee
           - buy_cost
           - inbound_shipping
           - prep_cost

roi    = net_profit / (buy_cost + inbound_shipping + prep_cost)
margin = net_profit / sell_price

Cash outlay here is $18.00 plus $0.80 plus $0.50, which is $19.30, so a $9.19 net is a 47.6 percent return on the money you put at risk. Many sourcers set two hard gates: a floor on ROI (often 30 percent or higher) and a floor on absolute net profit (often $3 per unit, because pennies do not survive a return or a fee change). Both gates run off numbers you scrape, which is why the buy price and the sell price have to be accurate to the cent. Read the buy price from the wrong store and every downstream number is fiction.

Deals decay. A clearance price that shows a healthy margin at 9am can be sold out by lunch, or the marketplace Buy Box can drop $4 when three other sellers pile in, erasing your spread. Sourcing is not a one-time scan, it is a monitor that watches many SKUs and alerts you when a threshold is crossed.

Three signals are worth watching continuously:

• Price drops on the buy side, when a retailer cuts a SKU you already track into profitable range.
• Restocks on hot items that keep selling out, since the window between "back in stock" and "gone again" is where the margin is.
• Sell-side moves that change your exit, mainly the Buy Box price and the number of competing offers.

Running this across thousands of SKUs from a single IP gets you throttled within an hour. Retailers watch request rate per IP, and a spike of catalog hits from one address is the clearest bot signal there is. The fix is not one heroic proxy, it is a pool of rotating IPs plus polite pacing, so your traffic looks like many ordinary shoppers instead of one machine hammering the catalog. Space requests, cache aggressively, and never poll faster than the data actually changes. The same block-avoidance discipline that ecommerce intelligence teams use applies here, and it is covered in depth in how ecommerce companies use proxies for competitive intelligence.

The buy side tells you what a product costs. The sell side tells you whether you can actually flip it and how fast. If you sell into a fulfillment program like Amazon FBA, these signals decide whether a low buy price is a real opportunity or a trap.

The trap this catches is the slow, crowded listing. A product can show a beautiful 50 percent margin and still be a bad buy if its sales rank says it sells a few units a month and eight sellers already share the Buy Box. You would win the race to the bottom and hold inventory for a year. Reading rank and offer depth turns a spreadsheet of spreads into a shortlist of things that will actually sell through. Pulling these fields cleanly is the same extraction work described in how to scrape Amazon product data and how to scrape eBay listings.

The base endpoint is https://scrape.sparkproxy.io/api/v1 and every request authenticates with the X-API-Key header. All target URLs below point at sparkproxy.io demo paths; swap in the retailer or marketplace URL you actually track. Full parameters live in the Scraping API documentation.

Start on the buy side. Read a store-scoped clearance page through a residential IP in the buying market, render JavaScript, and pull structured fields with extract_rules so you get numbers, not raw HTML:

import requests, json

API = "https://scrape.sparkproxy.io/api/v1"
API_KEY = "sk-xxxxxxxxxxxxxxxx"

def read_buy_side(product_url, country="US"):
    payload = {
        "url": product_url,
        "country_code": country,      # keep the exit in the buying market
        "premium_proxy": True,        # residential IP, matches store geography
        "render_js": True,
        "format": "json",
        "extract_rules": json.dumps({
            "price":     ".pdp .price-now",
            "was_price": ".pdp .price-was",
            "clearance": ".pdp .badge-clearance",
            "stock":     ".pdp .availability",
        }),
        "tag": "arb/buy-side",
    }
    r = requests.get(API, headers={"X-API-Key": API_KEY}, params=payload)
    return r.json()

buy = read_buy_side("https://www.sparkproxy.io/demo-retail/pdp/sku-44821")

When clearance is scoped to a store, set the location before you read. Inject the store cookie if you know its name, or drive the store picker with a js_scenario when there is no shortcut:

scenario = {
    "steps": [
        {"click": "#choose-store"},
        {"fill": ["#zip-input", "60614"]},
        {"click": "#apply-store"},
        {"wait": 1500},
    ]
}

payload = {
    "url": "https://www.sparkproxy.io/demo-retail/pdp/sku-44821",
    "country_code": "US",
    "premium_proxy": True,
    "render_js": True,
    "js_scenario": json.dumps(scenario),
    "wait_for": ".store-selected",
    "session_id": "store-60614",     # reuse the same store across requests
    "format": "json",
}
r = requests.get(API, headers={"X-API-Key": API_KEY}, params=payload)

Now the sell side. Read the marketplace listing for the Buy Box price, offer count, and rank:

def read_sell_side(listing_url, country="US"):
    payload = {
        "url": listing_url,
        "country_code": country,
        "premium_proxy": True,
        "render_js": True,
        "format": "json",
        "extract_rules": json.dumps({
            "buy_box":     "#buybox .price",
            "offer_count": "#offers .count",
            "sales_rank":  "#detail .rank",
            "fulfillment": "#buybox .ships-from",
        }),
        "tag": "arb/sell-side",
    }
    r = requests.get(API, headers={"X-API-Key": API_KEY}, params=payload)
    return r.json()

sell = read_sell_side("https://www.sparkproxy.io/demo-market/listing/B0DEMO123")

Combine both sides into the gate. This is the function that decides a buy:

def evaluate(buy, sell, referral_pct=0.15, fulfillment=5.50,
             inbound=0.80, prep=0.50, roi_floor=0.30, net_floor=3.00):
    sell_price = float(sell["buy_box"])
    buy_cost   = float(buy["price"])
    referral   = round(sell_price * referral_pct, 2)

    net = sell_price - referral - fulfillment - buy_cost - inbound - prep
    cash_out = buy_cost + inbound + prep
    roi = net / cash_out if cash_out else 0

    return {
        "net_profit": round(net, 2),
        "roi": round(roi, 3),
        "buy": roi >= roi_floor and net >= net_floor,
    }

print(evaluate(buy, sell))   # -> {'net_profit': 9.19, 'roi': 0.476, 'buy': True}

For a monitor, keep a rotating cheap sweep separate from the expensive confirm. A rotating-proxy fetch without JavaScript is the cheapest request the API offers; a premium residential fetch with JavaScript is the most expensive. Sweep wide and cheap, then confirm narrow and expensive only on flagged SKUs:

def cheap_sweep(list_url):
    # rotating IP, no JS: the low-cost catalog pass
    payload = {"url": list_url, "render_js": False, "format": "json",
               "extract_rules": json.dumps({"skus": ".grid .card"}),
               "tag": "arb/sweep"}
    return requests.get(API, headers={"X-API-Key": API_KEY}, params=payload).json()

For a dated record of a clearance price at one store, capture a screenshot straight to a file so you have proof of the price you sourced against:

curl -X GET "https://scrape.sparkproxy.io/api/v1?url=https://www.sparkproxy.io/demo-retail/pdp/sku-44821&country_code=US&premium_proxy=true&format=screenshot" \
  -H "X-API-Key: sk-xxxxxxxxxxxxxxxx" \
  --output sku-44821_60614_2026-08-10.png

The same buy-side extraction pattern carries over to any retailer catalog; the mechanics are the same as in how to scrape ecommerce prices, with the store session layered on top for localized clearance.

A working pipeline treats catalog discovery, price checks, sell-side research, and restock watching as separate stages with their own cadence and their own proxy cost. Cheap stages run often and wide. Expensive residential stages run only on candidates that already passed a cheaper gate.

The two gates are what keep this profitable and cheap at the same time. The margin gate throws out anything that does not clear your ROI and net-profit floors. The velocity gate throws out anything that will not sell through fast enough to free your cash. Only the SKUs that survive both gates ever reach the expensive residential restock watch, so you spend premium requests on a shortlist, not the whole catalog.

Arbitrage is a clear case where proxy type is a per-target decision, not a blanket one.

Run the cheap datacenter pool for the high-volume, low-sensitivity work: sweeping category and clearance index pages to collect SKUs, and reading marketplace listings that do not tie price to your location. Switch to residential for the parts that decide money: the store-scoped clearance price, any retailer that cross-checks IP against the location you set, and the restock polling where a block costs you the buy. Most sourcers run both from one codebase and choose per target. If you want the reasoning behind that split in a pure price-tracking context, it is laid out in datacenter proxies for price comparison websites.

Two separate questions sit here: is the reselling legal, and is the data collection legal. Keep them apart.

Reselling genuine goods you bought is generally lawful in the United States under the first-sale doctrine (17 U.S.C. section 109), which lets the owner of a lawfully made copy resell it without the rights holder's permission. That is the legal backbone of the entire secondhand and arbitrage market. It is not unlimited: it does not cover counterfeits, it does not override a marketplace's own brand-gating or category-approval rules, and some products carry their own restrictions.

Collecting publicly visible prices and stock is treated as distinct from unauthorized account access. In the United States, the hiQ v. LinkedIn line (9th Circuit, 2022) held that scraping public web data is not a Computer Fraud and Abuse Act violation, and a price shown to any shopper who loads a product page is public in that sense. That is the footing price-monitoring programs stand on. It is a footing, not a blank check, so keep the work inside sensible limits:

• Stay on public pages. Read catalog, product, and listing pages any visitor reaches. Do not create accounts to bypass gates, and do not scrape logged-in account areas.
• Do not automate checkout. Read prices and stock; never script the buy. Automated purchasing is where you cross into scalping behavior, which breaks most retailers' terms and invites the countermeasures aimed at bots.
• Respect terms of service. Many marketplaces restrict automated access in their terms. Public price data is legally distinct from account access, but weigh each target's terms, stay on public pages, and avoid logged-in flows.
• Rate-limit and be gentle. Space requests, cache hard, and do not degrade the site for real shoppers. Polite pacing is also what keeps you unblocked.
• Keep it product data. Prices, stock, ranks, and offers are product data, not personal data. Do not harvest shopper information or seller identities.

Rules vary by jurisdiction and change over time, so confirm your specific plan with counsel. The safe center of the road is public price and stock data, collected at a polite rate, with no account access and no automated buying.