See what Shopify competitors launched this week, from products.json

A Shopify launch watch is a check that reads the public /products.json of a list of competitor stores and tells you which products went live in the last few days, which ones sat in the back office for weeks before launch, and which ones have survived for years; the service below does that for up to 20 stores per call at $0.01 per store, and a free sample on one fixed store is at /demo.

Author: markedet. I built and sell the service below, so weigh my claims and check the free demo first.

Why products.json

Most Shopify storefronts answer https://<store>/products.json with their published products: title, handle, tags, variants with prices, and three timestamps. Those timestamps are the useful part:

• created_at: when the product record was made in the admin.
• published_at: when it went live on the online store.
• updated_at: the last time anything about the record changed.

The gap between created_at and published_at is a launch signal. A product created and published the same day is often a quick add; a product created 35 days before it went live was prepared, photographed and held for a planned drop. A product created ten years ago and still listed is a long survivor, which usually means it sells.

You can read this by hand with curl and jq. The work is doing it politely for many stores, paginating, handling stores that block or disable the endpoint, and turning raw dates into flags an agent can act on.

What the watch returns

Send {"stores": ["allbirds.com", "deathwishcoffee.com"], "since_days": 7}. Per store you get:

Across stores, a cross_store section groups similar product titles (word overlap, Jaccard 0.6 or more) that two or more of your stores launched in the same window.

A real example

This is the free demo on deathwishcoffee.com, fetched on 24 October 2026 at 21:45 UTC, window 7 days. One page, 153 published products, 3.4 seconds.

Read as a competitor: on 21 October the store launched a "Dark Spirits" seasonal drop in four products within two minutes (coffee, bottle, bundle, long sleeve). The bottle had been ready for two months. The coffee itself is a 2017 product brought back, which the relaunch_likely flag catches. The bundle was created five days before launch and published with a compare-at price, so it is priced as a deal from day one.

The store-level counts: 6 fresh launches, 5 held then published, 1 relaunch, 89 long survivors (its oldest listed product dates from 2013), and 25 products tagged Bundle.

One honest note from the same run: all 153 products had a new updated_at in the last 24 hours. The watch marks this as recently_updated_catalogue_wide: true and says so in plain text, because a store that touches every product daily (usually an inventory or feed sync app) tells you nothing with updated_at. On stores without such a sync, a recent update on a single product is a hint of a price or stock change.

Honest limits

• Only public /products.json is read. Stores can disable it, password-protect the shop or block bots; you then get that status, and it is charged because it is an answer.
• Published products only. Drafts, unlisted and deleted products are invisible, so you see launches, not plans.
• No sales, stock or revenue numbers. long_survivor suggests demand; it does not prove it.
• updated_at changes for many reasons (edits, apps, images), so recently_updated is a hint, not proof.
• At most 4 pages of 250 products per store; bigger catalogues are marked product_count_capped.
• Polite fetching: 1 request per second per store, a 10 minute cache, robots.txt respected. 20 stores can take 10 to 30 seconds.
• Cross-store matching compares title words, not images. Renamed products are missed and generic titles can match by chance.
• Hosted on Render Free: after about 15 minutes idle, the first call takes 30 to 60 seconds.

One paid call

The price is $0.01 USDC per store on Base, paid per call with x402. No account, no API key. Without a payment you get the 402 quote whatever the body; invalid input sent with a payment gets a free 422, and if every store in a call fails you are not charged.

curl -si -X POST https://shopify-launch-watch.onrender.com/check \
  -H 'content-type: application/json' \
  -d '{"stores": ["allbirds.com", "deathwishcoffee.com"], "since_days": 7}'

That returns HTTP 402 with a PAYMENT-REQUIRED header: amount 20000 (2 stores at $0.01), asset USDC, network eip155:8453. An x402 client signs the USDC authorization and resends the same POST with a PAYMENT-SIGNATURE header. You need a Base wallet with a little USDC; the facilitator pays the gas. pip install x402 httpx eth-account:

import asyncio, os
from eth_account import Account
from x402 import x402Client
from x402.http.clients import x402HttpxClient
from x402.mechanisms.evm.exact import register_exact_evm_client
from x402.mechanisms.evm.signers import EthAccountSigner

async def main():
    client = x402Client()
    register_exact_evm_client(client, EthAccountSigner(Account.from_key(os.environ["PRIVATE_KEY"])))
    async with x402HttpxClient(client, timeout=120) as http:
        r = await http.post("https://shopify-launch-watch.onrender.com/check",
                            json={"stores": ["allbirds.com", "deathwishcoffee.com"], "since_days": 7})
        print(r.status_code, r.json()["summary"])

asyncio.run(main())

The 200 carries the results and a PAYMENT-RESPONSE header with the settlement transaction.

For MCP clients the same tool is at https://shopify-launch-watch.onrender.com/mcp (watch_shopify_launches, paid through the x402 MCP transport, plus a free demo tool). The OpenAPI document is at /openapi.json.

If your agent watches competitor stores, run one paid call on the stores you care about and tell me which launch it missed.