DiecastRadarBot

Diecast Radar is a freemium hobby tool for diecast collectors. It shows collectors which shops currently carry a given car, at what price, and alerts them when something they are hunting comes back in stock.

To do that we read the public product pages of the shops we list. We are a referrer: we link collectors straight to your product page to buy. We do not resell your products or run a competing storefront. We do cache product images so listings stay usable when a CDN URL rotates; tell us if you would rather we hotlinked or dropped them.

Every request we make carries this exact User-Agent:

Mozilla/5.0 (compatible; DiecastRadarBot/1.0; +https://diecastradar.app/bot)

Grepping your access logs for DiecastRadarBot will match all of it. We originate from Vercel's serverless IP ranges, which are shared infrastructure, so the User-Agent is the reliable discriminator, not the IP.

We do not send a browser User-Agent and we do not send browser client hints. If you block or rate-limit that string, it takes effect. There is no path of ours that will keep getting through by looking like Chrome.

On a Shopify store, these public endpoints:

• /products.json (paged), or /collections/<handle>/products.json when we can scope to a diecast-only collection, to discover which products exist
• /collections.json once per discovery run, to find that collection
• /products/<handle>.json to read a single product's price and availability
• /products/<handle>.js when the .json and the page HTML do not settle whether an item is actually purchasable (most often on pre-orders)
• the product page HTML, to read the customer-facing localized price and the structured-data availability

These are GET requests. We never add to cart, never begin a checkout, and never submit a form.

One exception worth naming: for Mattel Creations specifically we use the Shopify Storefront API, which is a POST carrying a Storefront access token. That is a public read-only API used with the merchant's own published token, and it is the only place we authenticate to any store.

Discovery runs every two days. Routine stock and price checks run on a rotation, so an individual product page is typically requested somewhere between once a day and once every few days depending on how large your catalog is.

The exception is a launch or a restock. For the 24 hours around a product's release date, or after we detect a restock, we poll that one product much harder: as often as once a minute while we are waiting for it to go live, then easing to 5 minutes, 15 minutes, and hourly. This applies to a handful of products at a time, not your whole catalog, but on release day it is the single biggest load we place on you.

For shops whose WAF already rate-limits us, we additionally sort the rotation so products a collector is actively watching are checked first.

An HTTP 429, 503, or a connection error is treated as a signal to slow down, not as a failure to retry through:

• On the catalog discovery fetch we read Retry-After when you send it, and otherwise use exponential backoff. Be aware we currently cap that wait at 10 seconds, so a longer Retry-After is not fully respected. Tell us if you need it honoured in full and we will raise the cap.
• Each block widens the gap between our requests, within a run, up to a floor of one request every 15 seconds for shops we know rate-limit us (4 seconds elsewhere). That widening resets at the start of the next scheduled run.
• A product that was rejected is set aside and not retried for 12 hours, so a block is never hammered.
• If a meaningful share of a run is being rejected, we abandon the rest of that run entirely and wait for the next scheduled one.

Two honest gaps, so you know what to expect. On the per-product stock check we do not currently read Retry-After at all. We set that product aside for 12 hours instead, which is more conservative in practice but ignores a shorter window you may have asked for. And we do not currently parse robots.txt, so a Crawl-delay you add will not reach us on its own. Email us and we will set the limit directly.

If our traffic is causing you a problem, or you want us to slow down, change what we fetch, or stop entirely, email bot@diecastradar.app and we will act on it. A request to stop is honoured, no justification needed.

We would rather take a data feed than crawl you. If you can expose a product feed or an API, tell us and we will switch to it and drop the crawl entirely.