Pricing
from $1.00 / 1,000 results
Retail Store-Locator Expansion Tracker
Pull every store location for retail/F&B chains (one store per row) and a total-count snapshot. Re-run over time for an expansion/contraction signal. Public locator data.
Pricing
from $1.00 / 1,000 results
Rating
0.0
(0)
Developer
Actor stats
0
Bookmarked
2
Total users
1
Monthly active users
23 days ago
Last modified
Categories
Share
Pull every store location for retail and F&B chains — one store per row — plus a total-count snapshot per brand. Re-run on a cadence and the change in store count becomes an expansion / contraction signal (a classic revenue proxy for public chains).
Built for equity analysts and funds, commercial real estate, suppliers, and competitive-intelligence teams.
Why use this actor
- Volume in one run — big chains have thousands–tens of thousands of locations (Chipotle ~4,173 verified). Pull many brands in a single run for tens of thousands of rows.
- Expansion signal — each store carries its open status/date; diff successive runs to see net new vs closed stores.
- No login. Reads public store-locator endpoints.
Input
| Field | Description |
|---|---|
brands | Registry keys. Verified: chipotle. |
emitStores | One STORE row per location (default), or only the BRAND_SNAPSHOT count. |
maxStoresPerBrand | 0 = all. |
proxyConfiguration | Enable residential only if a brand fronts a WAF. |
Output
STORE (one per location) — normalized header (store_id, store_name, status, open_date) + the brand's raw fields verbatim, under the envelope (_input, _source, _scrapedAt, recordType).
BRAND_SNAPSHOT (one per brand) — { brand, total_stores }, the count for your time series.
How it works
- Each brand resolves to an adapter (endpoint + embedded API key + pagination strategy).
- The adapter paginates the locator API and returns every store.
- Stores stream out as rows; a per-brand count snapshot is appended.
Adding brands
This actor is a registry of per-brand adapters (src/constants.py + src/adapters.py). Each brand is reconned individually because every chain uses a different locator backend (in-house API, Yext, Brandify, RIO SEO) with its own embedded — and rotating — API key and pagination style. chipotle is implemented and verified; new brands are added as registry entries (and a fetch function if the response shape is new).
Known limits
- Embedded API keys rotate. Chipotle's
Ocp-Apim-Subscription-Keyis shipped as a fallback default; harvest-on-page + refresh-on-401 should be added per brand for long-term durability. - Per-brand WAF varies. Run WAF triage when adding a brand; escalate to a
curl_cffiTLS profile + residential proxy if blocked. Chipotle works from datacenter IP. - Verified live 2026-06-03: Chipotle —
pagingInfo.totalItems~4,173, 1,000 stores per call (whole US chain in ~5 calls).
