Every public JSON endpoint on a Shopify storefront

Why these endpoints exist at all

Shopify themes are rendered server-side in Liquid, but modern themes also need to update the page without reloading: adding to cart, swapping variants, filtering a collection. Rather than invent a private channel for that, Shopify exposes the same data as plain JSON on the storefront. Anything the theme can read, anyone can read.

This is worth stating clearly because it gets misreported. These are not leaks, and finding them is not a security discovery. They are documented, intentional, and functionally equivalent to the storefront HTML that already contains most of the same information. A product page already renders its price, variants and images. /products/handle.js just gives you those as structured data instead of markup.

The practical consequence for anyone building tooling: you get a decent read-only API on any Shopify store with zero setup. No app registration, no OAuth handshake, no access token, no rate-limit budget to negotiate. That is unusual, and it is why a whole category of small Shopify utilities exists.

The CORS problem, and the three honest ways around it

Shopify does not send an Access-Control-Allow-Origin header that permits arbitrary origins on these endpoints. So fetch() from your own page is blocked by the browser, not by Shopify. The request often reaches the server and returns fine; the browser simply refuses to hand you the body.

This confuses people because curl works instantly and so does opening the URL in a tab. Neither is subject to the same-origin policy. Only scripted cross-origin reads are, and that is the exact thing you need if you are building a browser tool.

Option 1: your own server-side proxy

The correct answer for anything you intend to keep running. A tiny endpoint on your own domain fetches the JSON server-side and returns it with permissive CORS headers. Same-origin from the browser’s perspective, so no blocking. About sixty lines in PHP or a single serverless function.

Lock it down or you have built an open proxy. The non-negotiables: allow https only, resolve the hostname and reject anything in private or reserved IP ranges to prevent SSRF against your own infrastructure, allow only the specific paths you need, and cap the response size.

// resolve first, then refuse private / reserved space
$ip = gethostbyname($host);
if ($ip === $host || !filter_var(
      $ip, FILTER_VALIDATE_IP,
      FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
  http_response_code(403);
  exit;
}
// without this, ?url=https://169.254.169.254/... reaches
// your cloud metadata endpoint. That is the whole exploit.

Option 2: public CORS relays

Services that fetch a URL and re-serve it with open CORS headers. Fine for a prototype, wrong for production. Rate limits are tight, uptime is nobody’s promise, and every lookup routes a client’s domain through a third party you have no agreement with.

If you must, race several in parallel and take the first success rather than chaining them with fallbacks. Chaining means every failure costs you its full timeout, and a three-deep chain of ten-second timeouts is a thirty-second wait before the error appears.

// resolve on first truthy result, reject only when all fail.
// Promise.any is close but treats a resolved-null as success.
function firstOf(list) {
  return new Promise((res, rej) => {
    let left = list.length, done = false;
    list.forEach(p => p.then(v => {
      if (done) return;
      if (v) { done = true; res(v); }
      else if (--left === 0) rej();
    }, () => { if (!done && --left === 0) rej(); }));
  });
}

Option 3: skip the browser entirely

If the tool is for you and not the public, a shell alias or a five-line script is less work than any of the above. curl -s "$1/meta.json" | jq -r .myshopify_domain solves the whole problem and will still work in five years.

What is not in here

No customer records, no order history, no draft products, no inventory counts, no financial data, no admin credentials. Everything on this list is data the storefront already renders to any visitor. If you need anything beyond it, you need the Admin API and an authenticated app.

Worth being precise about the boundary, because it is the difference between a legitimate tool and a problem:

• Storefront JSON is unauthenticated, read-only, published-content only. What this article covers.
• Storefront API is a GraphQL endpoint requiring a public access token. Still customer-facing data, but rate-limited and app-scoped.
• Admin API is where orders, customers and inventory live. Requires OAuth, an installed app, and explicit merchant-granted scopes.

The endpoints in this article sit firmly in the first bucket. They tell you what a store sells and what it is called. They tell you nothing about who bought it.

Putting it together

A production-grade lookup does four things: normalise whatever the user pasted down to a hostname, try meta.json across both www and apex variants in parallel through a same-origin proxy, fall back to an HTML scrape only if that fails, and validate the response shape rather than trusting a 200.

The ordering matters more than the code. /meta.json first because it is small, structured and authoritative. HTML scraping second because it costs a full page download and a regex. And a hard timeout on both, because a tool that hangs is worse than a tool that admits it failed.

That is exactly how the finder on this site works, if you want to see the pattern in a live implementation.