Shopify Proxies: 250 Products Per 1.76 MB Call

Shopify is not one site. It is the storefront engine behind hundreds of thousands of shops, and every one of those storefronts exposes the same JSON. On 28 September 2026 we fetched a real store's /products.json?limit=250 through a residential exit in the United States: 200 OK, 1,759,991 bytes, 250 products and 2,720 variants with price and availability, in 2.2 seconds, with no key and no browser. The same call from Germany returned the same 1,759,991 bytes. That one endpoint is the whole monitoring job; the proxy question is only about how many stores and how often.

Two different things are called a Shopify proxy

The Google results for "shopify proxies" answer a question most buyers are not asking. Rank 1 is Shopify's own developer documentation on app proxies: a feature that takes a request to a storefront URL such as /apps/my-custom-path and forwards it to an app's server, so the app can show dynamic data inside the store's theme. Autocomplete agrees: "shopify app proxies", "shopify app proxy example". That is a developer mechanism, not a network product, and the rank 2 vendor guide spends half its length explaining it.

The rest of the first page is sneaker bots: Reddit threads about running eight to twelve checkout tasks, and vendors selling IPs to "cop anything you want". We ship static ISP addresses for fast Shopify checkouts, and that is a separate page for a separate job.

This post is about the third thing, the one the "shopify scraper" and "shopify products.json" searches are actually looking for: reading what public storefronts publish, for price monitoring, catalogue tracking, stock alerts and competitor research. It is the cheapest data job on the web, and we can show the number.

products.json hands you 250 products per call

Every Shopify online store answers /products.json on its own domain. We chose allbirds.com because its response headers say powered-by: Shopify and because it is a real catalogue, not a demo. Over plain HTTP, engine: tls, from a United States residential exit:

Request	Status	Bytes	Time	What it contains
/products.json?limit=250	200	1,759,991	2.2 s	250 products, 2,720 variants (676 in stock), 1,194 images, prices from 4.00 to 165.00
/products.json?limit=250&page=2	200	1,804,729	8.6 s	the next 250 products
/products/womens-allbirds-flip-flop-dusty-pink.json	200	8,133	3.9 s	one product with every variant and image
shopify.com, no JavaScript	200	866,383	5.9 s	749 words, Corporation JSON-LD (the company site, not a store)
shopify.com, rendered	200	470,264	57.3 s	776 words in our audit; 27 more than plain HTTP

Each product row carries id, title, handle, body_html, vendor, product_type, tags, created, published and updated timestamps, the options, the images, and a variants array where every variant has its own id, sku, price, compare_at_price, available flag, grams and position. That is the full catalogue with stock, 250 products at a time, paginated with page=, and it needed no login, no token and no JavaScript. The response is uncached at the edge (cdn-cache-control: no-cache, no-store), so every request is a live read of the store, not a stale snapshot.

Three parser traps we hit in the first 250 rows:

• Prices are decimal strings here and integers elsewhere. products.json returned "price":"25.00". Shopify's Ajax reference for the sibling endpoint /products/{handle}.js documents price in cents, 12900 for $129.00. Two endpoints, two number formats, one store; a parser written against one will be off by a factor of a hundred on the other.
• updated_at is not a change signal on its own. All 250 products in our page carried the identical updated_at, 2026-09-28T10:05:10-07:00, because a store-wide sync touches every row. Diff the variant fields you care about, price and available, rather than trusting the timestamp.
• available is per variant, not per product. 676 of 2,720 variants were in stock. A product is "available" only in the sense that some size in some colour is; stock alerts live on the variant.

The exit country does not change the catalogue, it changes the edge

We repeated the 250-product call from a German residential exit. Same status, same 1,759,991 bytes, same content-language: en-US. The only differences were in the server-timing header: the request was served from Shopify's europe-west region through a Düsseldorf edge instead of a New York one, and it took 7.5 seconds instead of 2.2.

That is the geo rule for this target, and it is the opposite of an exchange or a bookmaker. A single-market store serves one catalogue to the world; the exit country changes latency, not data. Where it does change data is a store that sells in several markets, because Shopify's Ajax documentation says monetary properties are returned in the customer's presentment currency; there, a German exit gets euro prices and a US exit gets dollars, and you must pin the exit to the market whose prices you are recording. The check is one header: if content-language follows your exit, the store is localised and the country matters; if it stays en-US, as it did here, it does not.

shopify.com itself does localise. The same root URL sent a US exit 749 words under "Shopify: The All-in-One Commerce Platform" and a German exit 726 words on /de under "Shopify Deutschland". Nobody monitors the corporate homepage for data, but it is the same lesson: the storefronts you care about may or may not do this, and the header tells you which.

Rendering buys 27 words and costs 57 seconds

The company homepage is the only Shopify surface where a render is even tempting, and it is not worth it: 749 words without JavaScript, 776 rendered, 57.3 seconds in the browser. A storefront's products.json has no JavaScript in it at all. Every byte in this post came over plain HTTP, and nothing we sent to shopify.com, allbirds.com or the JSON endpoints was challenged from either country. Skip the browser on this target; it has nothing to add.

Rate limits are per app per store, and the terms are for account holders

The other half of the "shopify proxies" market sells IPs for the Admin API, so we read what the API is limited on. Shopify's REST Admin API reference says the limit is 40 requests per app per store per minute, replenished at 2 requests per second, raised by a factor of 10 for Shopify Plus stores, with the running count printed in X-Shopify-Shop-Api-Call-Limit (40/40 at the ceiling) and a 429 that carries Retry-After. The bucket is keyed to your app and the store, not to the address you call from. A proxy changes nothing about that limit, and no vendor can sell you around it. If you are building on the Admin API, spend on backoff logic, not on IPs; our note on 429 Too Many Requests is the same loop.

The terms are worth reading precisely. Shopify's Terms of Service, section 1.9, has the merchant agree not to access the Services or monitor any material from them "using any robot, spider, scraper, or other automated means", and the API License and Terms of Use, section 2.3.14, forbid using the Shopify API for systematic or automated data collection. Both bind the account holder: the merchant who signed up, the developer who took API credentials. A storefront's products.json is served by the merchant's shop to any visitor, which is why price-comparison engines, affiliate feeds and Google Shopping all read it; a merchant's own terms of sale may say otherwise for their store, and that is the document to check per domain. There is no personal data in a product feed, so the privacy question that shadows social platforms does not arise here. What we will not help with is the checkout side of the SERP: circumventing purchase limits or bot protection on a drop is the merchant's rule to set, and a proxy that helps you break it is not something we sell as such.

shopify.com/robots.txt, 3,516 bytes, is the corporate site's file: it blocks a document crawler entirely, excludes account, admin, checkout and search paths, and lists one sitemap index. Each storefront has its own robots.txt on its own domain, generated by Shopify, and that is the one that governs a store.

The cost of a gigabyte on Shopify storefronts

All fetches went through residential proxies on the Basic line at $0.80/GB, counting a gigabyte as 10^9 bytes. Bytes are what our scraper metered per request, excluding TLS handshake overhead.

Job	Bytes per request	Requests per GB	Cost per request	Cost per 1,000 products
Catalogue page, 250 products	1,759,991	about 568	$0.0014	$0.0056
One product .json	8,133	about 123,000	$0.0000065	$0.0065
shopify.com homepage, no JavaScript	866,383	about 1,150	$0.00069	n/a
Catalogue page via the web scraping API	n/a	n/a	$0.0002	$0.0008

A gigabyte is 568 catalogue pages, about 142,000 products with stock and price, for $0.80. The last row is the one to notice: at this page weight the web scraping API at $0.0002 per successful page is seven times cheaper than the raw bytes, because it bills per page rather than per byte and never bills a failed fetch. Raw rotating proxies win on the 8 KB single-product call; the API wins on the 1.76 MB catalogue page. Pick per endpoint, not per project.

When one store is not the question

products.json answers "what does this store sell, at what price, in stock or not" for one domain at a time. For the questions around it we have the pieces already built. Cross-store price checks on a named product run through the price comparison collector and the Google Shopping collector, which return offers per merchant rather than one merchant's catalogue. The method for turning a feed into an alert, thresholds, cadence and what to diff, is in how to price monitor, and the service page for the whole loop is competitor price monitoring.

Finding the stores in the first place is a different job: there is no registry of Shopify shops, but the powered-by: Shopify response header and the shape of /products.json identify one in a single request, and a list of competitor domains becomes a list of catalogues at 2.2 seconds each.

The setting that works on Shopify

• Network: rotating residential Basic at $0.80/GB. Nothing we sent to a storefront or to shopify.com was challenged from either country, so the cheap line is the right line; the pool is for spreading many stores and many pages, not for disguise.
• Fetch mode: engine: tls. A storefront's /products.json?limit=250 is 1,759,991 bytes of pure JSON with 250 products; shopify.com is 749 words without JavaScript and 776 rendered at 57.3 seconds. Never render.
• Country to pin: the market whose prices you record. On a single-market store the bytes were identical from the US and Germany (1,759,991 both) and content-language stayed en-US; on a multi-market store the presentment currency follows the exit, so pin it and check the header.
• When the proxy is not enough: for a 1.76 MB catalogue page the web scraping API at $0.0002 per successful page costs a seventh of the raw bytes; for offers across merchants, the price comparison collector and the Google Shopping collector.
• Every account gets $2 of free API usage per month.