I published eleven Actors on Apify at the end of August. A week later they had, between them, zero users who were not me or Apify's own daily QA run.
I did the things you do. I rewrote the store descriptions around the words buyers type. I published two articles under the Apify organisation on DEV. I posted in the Discord. Nothing moved, and I kept telling myself it was a discovery problem — the Actors were fine, nobody knew they existed yet.
That was true. It was just not true in the way I thought. Nobody knew they existed because, for anyone searching Apify Store, they did not.
This post is the diagnosis, the one API call that made it certain, the fix, and a warning for anyone publishing from outside the US or EU. It took about four hours to resolve once I knew what to ask. It took a week to know what to ask.
The symptom that finally looked wrong
Store search ranks by usage, so a new Actor being buried under established ones is normal. I did not expect to see mine on page one for "linkedin jobs". I did expect to see them somewhere.
The check that broke the "just buried" story was searching for one of my own Actor slugs, exactly:
GET https://api.apify.com/v2/store?search=linkedin-company-jobs-scraper
→ 12 results. None of them mine.
To make sure that was not simply what happens to small Actors, I searched the exact slug of another creator's Actor that had four users in total. It came back first, alone. So an Actor with four users is findable by its own name, and mine — public, passing QA, 98.8% run success — were not.
Two more checks, both negative:
-
sortBy=lastUpdatedid not include my Actors minutes after I rebuilt two of them. Whatever was hiding them was not a ranking problem. - The web Store search behaved identically to the API. My profile page listed all eleven as public. The Actor pages loaded fine by direct URL.
Public, reachable, working, and absent from every list. That is not "buried". That is a filter.
The parameter
The Store endpoint has a parameter I had never read past:
includeUnrunnableActors — By default, search results exclude Actors that are not safe to run automatically (e.g. Actors from developers who haven't passed KYC, or full-permission Actors without a large user base). Set to
trueto bypass this safety filtering and include all Actors in the results.
So I ran the pair that settles it:
GET /v2/store?username=northbell
→ 0 Actors
GET /v2/store?username=northbell&includeUnrunnableActors=true
→ 11 Actors
The same eleven Actors appear and disappear on one flag. Nothing about indexing, nothing about ranking. The Store had them; it was choosing not to show them.
The parameter's own description names two causes. All eleven of my Actors run with LIMITED_PERMISSIONS, so it was not the second one. That leaves the first: I had not completed identity verification.
If you take one thing from this post, take the pair of requests above. It is a ten-second test, it returns a yes or a no, and it tells you whether any amount of work on titles, READMEs, categories or promotion can help you at all. For a week, in my case, it could not have.
Where the verification actually lives
I went looking for it in Settings. /settings/payouts and /settings/monetization both redirect to the account page, which is where I concluded the feature was not enabled for my account and stopped.
It is under Actors → Insights → Payouts, as a banner that says Identity verification required with a Verify Identity button. I only found it after a support reply mentioned "Insights – Payouts", and I had been looking at that sidebar entry for a week without opening it, because "Insights" did not sound like a place where a gate would be.
Why my documents failed, and why yours might
The verification portal accepts a passport, a driving licence, or a national ID card. I am in Japan. I tried my driving licence, then my national ID card, several times each, in good light, flat, all four corners in frame. Every attempt came back rejected, with a reviewer note that the provider "does not support verification through this type of document" and a banner reading Mismatch between the data you declared and the data from the verification.
The two messages together are the explanation. Japanese driving licences and national ID cards print the holder's name in Japanese characters only — there is no romanised name anywhere on the card. My account name is in Latin script. The automated check had nothing on the document to match it against, and reported a mismatch. In Japan the passport is essentially the only widely held ID that carries a romanised name, and I do not have one.
So this was never a photography problem, and retrying with a better photo was never going to work. If your country's ID does not carry your name in the script your account uses, expect the same, and go straight to support rather than re-submitting.
What support did
I wrote to support with the structural explanation above — not "it failed", but why it could not succeed. The first three replies were from an AI assistant that could not answer a policy question, and said so. When I asked it to pass the case to a person, it did. A support engineer acknowledged within half an hour, asked the verification team, and about four hours after my first email I had this in the console:
Identity verified. Your identity has been successfully verified. You're all set to receive payouts.
I re-ran the pair of requests. ?username=northbell returned eleven.
What visibility bought, measured
Being listed is necessary. I want to be precise about how far it is from sufficient, because the next trap looks a lot like success.
An hour after verification, my Actors ranked in Store search like this:
| query | rank |
|---|---|
google play rating |
1 |
linkedin applicants |
1 |
linkedin headcount |
2 |
shopify app reviews |
5 |
linkedin company jobs |
10 |
First place, with zero users, on the first day. It would have been easy to post that table and stop.
But rank on a query only matters if people type the query. So for each one I added up the 30-day users of the ten Actors that rank for it — a rough measure of how many people actually arrive through that phrase:
| query | my rank | 30-day users, top 10 combined |
|---|---|---|
google play rating |
1 | 18 |
linkedin applicants |
1 | 22 |
linkedin jobs salary |
6 | 51 |
linkedin jobs |
not in top 25 | 31,870 |
linkedin scraper |
not in top 25 | 37,833 |
I am first on phrases that a few dozen people a month use, and absent from the phrases that thirty thousand use. The phrases I win are, more or less, my own product descriptions rephrased. The phrases with traffic are held by Actors with fifteen thousand monthly users, and Store ranking weights usage heavily enough that no wording gets a new Actor past them.
That is not a complaint. It is the shape of the problem now that the filter is gone: the Store shows you, but it does not bring people to you. What does is outside the Store — a Google result for a specific need, an article, a link someone shares. The Store is where they land, not where they start.
The checklist I wish I had on day one
- Run the two requests. If
includeUnrunnableActors=trueis the only way your Actors appear, stop everything else and go to Actors → Insights → Payouts. - If your ID does not carry your name in the script your Apify account uses, do not retry the portal. Write to support with the reason, ask for a human, and ask for manual verification.
- Once you are listed, do not read a first-place rank as demand. Add up the 30-day users of what ranks alongside you. If the total is two digits, you have won an empty room.
- Record the day you became visible. Everything you measured before it was measured against a wall.
My eleven Actors are at apify.com/northbell. As of the day this was written, their combined 30-day users are ten — nearly all of it Apify's QA. That number is the baseline, and it is the first one I have been able to trust.
northbell builds honest web scrapers on Apify. If a derived number has an error margin, the margin ships with it.
Top comments (0)