-
The run log no longer shows the monitoring service's address, its credentials, or the address a failed report was for.
-
A request Shopify refuses through the run's proxy is now sent again from an Apify residential
address, and after three refusals in a row new stores start on one. Runs whose proxy addresses
Shopify refused had ended with no stores.
-
A "(0)" after a phone number's country code — the national trunk digit written the German
way — is no longer kept in the number.
-
The Shop app lookup sends the store's own country as its ships-to filter, so a store that
does not ship to the proxy's exit country is still found under its own name.
-
A phone number a store spells more than once — with and without its country code or a
leading plus — is listed once, in its most complete spelling. A bare local number is never
folded into a longer one.
-
A store Shopify refuses is no longer dropped, and no longer slows the run. Through the
proxy each store's requests leave from one IP, and a 429 is that IP's, but the storefront
client retried it from the same IP and slowed every other request as if the limit were the
run's. On the platform on 2026-09-24 a 30-store keyword run slowed eleven times, seven of
them to one request per 5 s, dropped five stores after three 429s each, and took 359 s;
those five stores then answered at the first try from three other IPs each. A failed
request now goes out again on a new proxy session, which its store keeps, and nothing else
waits. The same run locally through Apify Proxy: three 429s, each answered from the next
IP, no store dropped, 30 in 108 s. On the platform on 2026-09-25, under a tighter limit —
a third of first /meta.json requests refused — clearpath's 100 domains stored 98 in
422 s, against 85 in 1,413 s the day before: 32 of the 35 refused requests were answered
from another IP. Without a proxy, where every request shares one IP, a 429 still slows the
whole run.
-
A keyword search no longer stalls after its first page. Every Shop app request went out
from one IP: an impit instance keeps its connection to a host open, and a session-less
proxy URL changes the IP only per connection. The Shop app refuses an IP after a search
page and a few store pages, so on the platform two coffee runs lost page 2 and both
retries of it, fell back to walking the seed — one store every seven to eight minutes —
and one of them timed out at the hour with 26 of 30. Each Shop app request now goes out
from a new instance on a new proxy session, and a refused one is sent again from another
IP, five times for a search page and three for a lookup or a store page, half a second
apart instead of two. Locally through Apify Proxy, "coffee" with maxItems: 30: 30
stored in 97 s, page 2 at the first try. When the search itself is refused or runs out,
the run ends and says so, with the stores it has.
-
The actor runs in 256 MB. It parsed each store's homepage whole and kept the parsed page
while that store waited on its later requests, and a parsed homepage takes 20–30 times the
memory of its HTML: one coffee roaster's 5.7 MB homepage, most of it inline SVG, came to
162 MB. On 2026-09-23 a 100-store run reached the platform's 512 MB limit, and in a local
container capped at 256 MB the previous build was killed six seconds in. Each page is now
read once, as it arrives, without the scripts, styles and SVG images that no field is read
from, and only what the row needs is kept. In the same container, the same 100 stores:
all stored, peak 112 MB. On 102 saved homepages every field comes out as it did before.
-
A restarted run no longer stores and charges again the stores it had already stored, and
maxItems caps the run rather than each attempt at it. The platform restarts a run that
exits non-zero with the same default dataset but a new process, and the set of stores
already charged and the count against maxItems lived only in memory. Measured on
2026-09-23: a run given 100 domains and maxItems: 100 exited 83 s in, very likely out of
memory, and the restart started the input over — 112 rows and 112 charges for 99 stores.
The crawler now reads its own default dataset back on start, on the platform only, and
restores both.
-
Runs no longer report to Scraper Insight under shopify-scraper's identity. This actor was
forked from that one and carried its app id and secret verbatim, so every store-discovery
run was filed against shopify-scraper and moved its request count, failure rate and
distinct-account count. The actor is now registered as its own app and carries that pair.
First version. Finds and qualifies Shopify stores, one billable row per store.
