Loading today’s stories
Build1 distinct publisher3 min readPublished
A week of rewriting descriptions could not have moved the number, because Apify's Store endpoint was filtering all eleven Actors out of results by default, and the identity check that lifts the filter rejected every Japanese document the publisher had.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The default is the exclusion. `GET /v2/store` returns the store minus the Actors the platform judges unsafe to run automatically, and the parameter description names two grounds for that judgement: a developer who has not passed KYC, and a full-permission Actor without a large user base [7]. All eleven Actors run with `LIMITED_PERMISSIONS`, which rules out the second [9].
The ranking story was testable, and it failed twice before the flag settled it. A recency sort (`sortBy=lastUpdate`) did not list the Actors minutes after two of them were rebuilt, which is exactly where a fresh build has to appear if ordering is the only thing happening [5]. An exact-slug search returned twelve results, and none of them was the Actor whose slug had been typed [3]. The control is the good part of the diagnosis: the exact slug of another creator's Actor with four total users came back first and alone [4].
Every surface a publisher would check said the listings were healthy. The profile page listed all eleven as public, the Actor pages loaded by direct URL, and the web store search behaved identically to the API [6]. Run success was 98.8% and the Actors passed QA [10]. The filter sits between the store index and the search response, so author-facing views are on the wrong side of it to be diagnostic.
For the ten-second test to transfer, three things have to hold on your marketplace: it filters listings on publisher verification state, it exposes that filter as a parameter you can flip, and it leaves your own profile view unfiltered. Apify's Store endpoint does all three, which is why one request pair moved the count from zero to eleven [8]. A store that filters without a documented bypass gives you no self-serve answer, only a support ticket.
Finding the gate cost more than proving it existed. `/settings/payouts` and `/settings/monetization` both redirect to the account page [11], and the banner that unblocks distribution sits under Actors, then Insights, then Payouts, found only after a support reply named that path [12]. A distribution gate filed under a menu called Insights is a naming decision with consequences.
The document step is where this stops being an Apify story. The verification portal accepts a passport, a driving licence, or a national ID card [13]. The author, writing from Japan, submitted his licence and his national ID card several times each and had every attempt rejected, with a reviewer note that the provider does not support that document type and a banner reporting a mismatch between declared and verified data [14]. By his reading, the two messages combine: Japanese licences and national ID cards print the holder's name in Japanese characters only, his account name is Latin script, and the automated comparison had no field to match against [15]. The passport is essentially the only widely held Japanese ID carrying a romanised name, and he does not hold one [16].
The post says the fix took about four hours once he knew what to ask, and a week to know what to ask [17]. In calendar terms that is 168 hours of framing against four hours of acting, roughly 42 to 1 [1]. The four hours clearly did not include a document that passed, since the account ends in rejections [14]. I have moved the enumerating query to the top of my own publish checklist, because its answer decides whether anything else on that checklist can help.
Ranked by verification strength, evidence, and original report placement.
The author published eleven Actors on Apify at the end of August; a week later they had, between them, zero users who were not him or Apify's own daily QA run.
Apify Store search ranks by usage, so a new Actor being buried under established ones is normal.
GET https://api.apify.com/v2/store?search=linkedin-company-jobs-scraper returned 12 results, none of them the author's.
Searching the exact slug of another creator's Actor that had four users in total returned that Actor first and alone.
A sortBy=lastUpdate query did not include the author's Actors minutes after he rebuilt two of them.
The web Store search behaved identically to the API, the author's profile page listed all eleven Actors as public, and the Actor pages loaded fine by direct URL.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 2, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
A #1 ranking only its author could see, and eleven days spent measuring the wrong end1 distinct publisher
build
Empty tax IDs turned a risk check into eleven clean sellers1 distinct publisher
build
One bookkeeping row turns an empty scrape into a billable event1 distinct publisher
build
Amazon prices by exit IP, and the parser everyone writes deletes the only clue1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Reproducible test, single console
Two requests that differ by one flag — zero Actors, then eleven — carry more weight than most sourcing, because any reader can rerun them in seconds, and Apify's own parameter text names the KYC cause the post lands on. The control search against another creator's four-user Actor closes the obvious alternative explanation. What is absent is anyone else: no Apify statement, no second publisher reporting the same exclusion, and every screenshot from one account.
Nobody arrived, before or after
The only usage figures in the story are the ones being explained. Zero outside users in week one, and after verification lifted the filter, first place on phrases a few dozen people a month type while the phrases thirty thousand people use stayed out of reach. Being listed changed the listing; it did not produce demand, and the post is unusually blunt about that.
One leap, no victory lap
The one stretch is scope: a single publisher's console becomes a statement about how Apify Store treats unverified publishers generally, and only Apify's parameter description supports that generalisation. Everything else runs the other way. The post could have ended on the rank-one table an hour after verification and instead subtracted it by counting who actually searches those phrases, and it names the four-hour fix rather than dramatising the week.
Critique hosted by its subject
A creator whose payouts depend on Apify writes about an Apify gate, and it appears under Apify's own organisation on DEV — the same channel he had already used for two promotional articles. That shapes what the piece is: constructive, fix-forward, generous to the support engineer, and quiet on whether the default filter is a defensible policy. It is not a hidden interest, it is a visible one, and it is the reason nothing here reads as an outside audit.
Internally tight, externally untested
One account, one country, one week, and no word from Apify or the verification vendor beyond the rejection text quoted. The internal reasoning is sound and the key test is repeatable, so we are confident about what happened to these eleven Actors. We cannot say from here whether the Japanese-document failure is deliberate policy, a vendor limitation, or a defect — and that distinction is what a second source would settle.