Proxies for Grocery and Delivery Price Data

Proxies for grocery and delivery price data let you read the exact price, delivery fee, and stock status a shopper sees at a specific store and zip code, not the generic national number a single office IP happens to return. Grocery is the hardest retail vertical to price-track because there is no one price for a product. A gallon of milk costs one thing at the store serving 60614, something else two zip codes over, and a third amount once Instacart adds its markup and fees. This guide covers why grocery pricing is scoped to store and zip, how availability and surge delivery fees fit in, and how to build a collection pipeline that returns the number a real shopper actually pays.

Key Takeaways

• Grocery pricing is store-scoped: the same SKU is a different price two zip codes apart, and the store is chosen by your location, not by the product URL.
• The number that matters is the landed cost: base price plus service fee, delivery fee, per-item markup, and surge, all computed in the cart at request time.
• Availability is per store and per fulfillment window. An item that is out of stock at one store is often in stock at another store in the same city.
• Store and zip selection lives in a session cookie, so you need a geo-consistent residential IP and a persistent cookie together, or the site quietly resets you to a default store.

On a marketplace like Amazon, a product URL maps to one price for most shoppers. Grocery does not work that way. A supermarket catalog is keyed to a physical store, and a quick-commerce app (Instacart, DoorDash, Uber Eats) is keyed to the delivery zone around the address you enter. The product page is a template. The price gets filled in only after the site knows which store will fulfill the order.

That single design choice creates most of the difficulty. Enter zip 60614 and a supermarket site resolves to the store that serves that neighborhood, with that store's shelf prices, promotions, and stock. Enter 60622 and you may hit a different store in the same chain with different numbers. Instacart layers a second markup on top: the in-app price for a retailer is frequently higher than the same item on the shelf, and it still varies by the store nearest the entered address.

So the same gallon of milk can read $3.79, $4.29, or "not available" depending purely on location. If you scrape without setting a location, you get whatever store the site guesses from your IP. For a datacenter IP that guess is often a fallback catalog or a metro the IP happens to sit in, not the market you care about. This is the same location sensitivity behind geo-targeting in proxies, applied at a much finer grain than country.

A national price scrape misses all five of these. Tracking a competitor's grocery prices is closer to running hundreds of small, location-specific scrapes than one big catalog pull, which is why it differs from a general price comparison website build.

Price is only half of what grocery buyers, brands, and analysts want. The other half is availability, and in grocery it moves hour to hour. A carton of eggs in stock at 9am can be sold out by noon and restocked overnight. Capturing that signal well means recording more than a single in-stock flag.

Fields worth pulling on every product check:

• Stock state: in stock, out of stock, low stock, or "only a few left" hints when the site exposes them.
• Substitutions: when an item is out, delivery apps propose a replacement, often at a different price. The suggested substitute changes the effective basket cost, so record it.
• Fulfillment options: delivery, curbside pickup, in-store pickup, same-day versus scheduled.
• Earliest window and ETA: the first available delivery or pickup slot, plus the quoted arrival time.

The store-scoped nature applies here too. An item out of stock at the store serving one zip is regularly in stock at another store in the same metro, so availability is a per-store, per-window fact, not a per-product one. Assortment and share-of-shelf analysis lean on this: which SKUs a store actually carries, how often they go out of stock, and how fast they come back. A price-only scraper throws that away. Pairing price with availability from the same session is what makes the dataset useful for demand forecasting rather than just a spot check.

The shelf price is not what the shopper pays. Delivery and quick-commerce apps assemble a landed cost from a stack of fees, and several of them are dynamic. Read the product page alone and you capture the smallest part of the total.

The components that make up the real number:

• Item price: inside a delivery app this frequently runs 10 percent to 20 percent above the in-store shelf price, and it is set per retailer and store.
• Service fee: usually a percentage of the subtotal.
• Delivery fee: varies with distance from the store and current demand.
• Small-basket fee: added below a minimum subtotal.
• Busy or surge pricing: raised during peak hours, bad weather, and staffing crunches.
• Heavy or bulky surcharges: applied to cases of water, litter, and similar items.
• Membership pricing: a paid tier can waive delivery and lower service fees.

Busy pricing and delivery fees are computed at request time from location, time of day, and live demand. Two identical requests a few minutes apart can return different totals. To capture the honest landed cost you have to read the cart or checkout summary, not the product page, and you have to sample across dayparts to see the surge curve rather than one frozen moment.

Here is the part most guides skip. Setting a location is not one action, it is two facts that have to agree:

1. The location you tell the site (a zip or a chosen store), stored in a cookie or session.
2. The geolocation of your exit IP.

Grocery and delivery sites often cross-check the two. Tell the site you are in zip 60614 while your exit IP geolocates to a datacenter in another state or country, and the site can ignore your zip, snap back to an IP-derived store, show a "we do not deliver to your area" state, or flag the session as suspicious. The location cookie and the IP have to tell the same story. A residential IP in the target metro is what makes them consistent, because the IP itself geolocates near the zip you set.

The second half is persistence. Store choice lives in a session cookie, and the flow spans several requests: load the home page, set the zip, browse a category, open a product, add to cart. Drop the cookie or switch to a fresh IP between those steps and the site bounces you back to its default store, discarding the location you set. So the requirement is specific: geo-consistent residential IPs at the right granularity, plus a session that carries the store cookie across every request.

Datacenter IPs still have a place. Where a supermarket site accepts a location cookie without cross-checking the IP, cheap datacenter proxies handle the volume fine. The sites that matter most for delivery pricing usually do check, which is where residential IPs earn their cost.

There are three ways to pin a session to a store, in rough order of speed. Each API call is independent, so you carry the store selection yourself and keep the exit geography fixed.

1. Inject the store or zip cookie with the cookies parameter when you know the cookie names. Fastest, no UI interaction.
2. Hit the store-locator endpoint with the zip as a query parameter, then reuse the returned store on later requests.
3. Drive the UI with js_scenario: click the location control, fill the zip, apply, and wait for the store to confirm. Use this when there is no cookie or endpoint shortcut.

Across all three, set premium_proxy=true for a residential exit IP and hold country_code fixed so every request leaves from the same country. Then request the product, category, and cart pages with the same injected cookie so the store selection follows you. The SparkProxy Scraping API exposes exactly these controls, documented at the Scraping API reference.

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 delivery app URL you actually track.

A geo-targeted residential fetch of a store-scoped product page, rendering JavaScript and returning JSON:

curl -X GET "https://scrape.sparkproxy.io/api/v1?url=https://www.sparkproxy.io/demo-grocery/pdp/milk-1gal&country_code=US&premium_proxy=true&render_js=true&format=json" \
  -H "X-API-Key: sk-xxxxxxxxxxxxxxxx"

To make the catalog resolve to a specific store, inject the store and zip cookies so the site treats the request as coming from a shopper in that market:

import requests, json

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

def fetch_store_price(product_url, store_id, zip_code, country="US"):
    payload = {
        "url": product_url,
        "country_code": country,
        "premium_proxy": True,       # residential exit IP in-country
        "render_js": True,
        "format": "json",
        "cookies": json.dumps([
            {"name": "store_id",     "value": store_id, "domain": "sparkproxy.io"},
            {"name": "delivery_zip", "value": zip_code, "domain": "sparkproxy.io"},
        ]),
    }
    r = requests.get(API, headers={"X-API-Key": API_KEY}, params=payload)
    return r.json()

data = fetch_store_price(
    "https://www.sparkproxy.io/demo-grocery/pdp/milk-1gal",
    store_id="01844", zip_code="60614",
)

When there is no cookie shortcut, set the zip through the interface with a js_scenario. The steps click the location control, fill the field, apply, and pause for the store to load:

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

payload = {
    "url": "https://www.sparkproxy.io/demo-grocery/home",
    "country_code": "US",
    "premium_proxy": True,
    "render_js": True,
    "js_scenario": json.dumps(scenario),
    "wait_for": ".store-confirmed",
    "format": "json",
}
r = requests.get(API, headers={"X-API-Key": API_KEY}, params=payload)

The landed cost only appears in the cart. Add the item, open the cart, and pull the fee stack with extract_rules so you get structured fields instead of raw HTML:

payload = {
    "url": "https://www.sparkproxy.io/demo-grocery/cart",
    "country_code": "US",
    "premium_proxy": True,
    "render_js": True,
    "cookies": json.dumps([
        {"name": "store_id", "value": "01844", "domain": "sparkproxy.io"},
        {"name": "cart_id",  "value": "c-77213", "domain": "sparkproxy.io"},
    ]),
    "extract_rules": json.dumps({
        "subtotal":     ".summary .subtotal",
        "service_fee":  ".summary .service-fee",
        "delivery_fee": ".summary .delivery-fee",
        "surge_note":   ".summary .busy-pricing",
        "total":        ".summary .grand-total",
    }),
    "format": "json",
}
r = requests.get(API, headers={"X-API-Key": API_KEY}, params=payload)

For a dated record of a price and availability at one store and moment, capture a screenshot straight to a file:

curl -X GET "https://scrape.sparkproxy.io/api/v1?url=https://www.sparkproxy.io/demo-grocery/pdp/milk-1gal&country_code=US&premium_proxy=true&format=screenshot" \
  -H "X-API-Key: sk-xxxxxxxxxxxxxxxx" \
  --output milk_60614_2026-07-30.png

The same extraction pattern works for any store-scoped catalog. If you are starting from a general retail scrape, the mechanics carry over from scraping ecommerce prices and from scraping Walmart product data, with the store and zip session layered on top.

A working pipeline treats store resolution, price, availability, and landed cost as separate stages with their own cadence. Cheap stages run often and wide. Expensive cart checks run only on items the cheaper stages have already flagged.

The pattern keeps cost sane. You are not driving a full browser add-to-cart flow on every SKU every hour. You run cheap price and availability sweeps broadly, then spend the expensive residential cart requests only where a price moved or a surge window opened.

Grocery is one of the clearest cases where proxy type is a per-target decision, not a blanket one.

Use datacenter proxies for the high-volume, low-sensitivity work: building the store map, and sweeping supermarket sites that honor a location cookie without checking the IP. Switch to residential for the delivery apps and for any site where the zip you set has to match the IP you arrive on. Many teams run both from one codebase, choosing per target, which mirrors the hybrid approach covered in how ecommerce companies use proxies for competitive intelligence.

Collecting publicly visible grocery prices and availability is generally 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 enters a zip is public in that sense. That is the legal footing most price-monitoring programs stand on. It is not a blanket permission slip, so keep the work inside sensible limits.

Practical boundaries that keep a grocery data program clean:

• Stay on public pages. Read catalog, product, and cart-summary pages that any visitor reaches by entering a zip. Do not create accounts to bypass gates, and do not scrape authenticated account areas.
• Do not transact. Read the cart summary for fee data. Never place, modify, or cancel real orders.
• Respect terms of service. Many delivery apps restrict automated access in their terms. Scraping public catalog pages is legally distinct from account access, but weigh each target's terms, target public pages, and avoid logged-in flows.
• Rate-limit and be gentle. Space requests, cache aggressively, and do not degrade the service for real shoppers.
• Keep it product data. Grocery catalogs are product and price data, not personal data. Do not harvest shopper information, reviews tied to individuals, or driver details.

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 availability data, collected at a polite rate, with no account access and no orders.