Skip to main content
asobeast is built on public store data. A product built that way and unwilling to discuss how looks evasive, so this page states the position plainly and in advance. The code is open, so anyone can check that the position matches the behaviour.

​
What the service does

It collects publicly visible store search results and listing metadata on a customer’s behalf: the same search result pages and app pages any visitor sees, read on a schedule and stored so that changes over time become visible. Concretely, per tracked keyword and market, one search per day. Per tracked app, a listing snapshot, its public reviews and its category positions.

​
The one request that is not a store request

A deployment can opt in to an hourly poll of a store status document the maintainer publishes, by setting STORE_STATUS_URL. It exists so a store breakage the maintainer already knows about reaches every opted in installation by editing one file, rather than arriving as issues one at a time. It is empty by default, and while it is empty no request is ever made. The poll is not even scheduled. apps/api/test/no-outbound.e2e-spec.ts asserts exactly that, and it is one of four opt in outbound integrations alongside webhook alerts, email and OpenAI assistance. When it is set, what leaves the deployment is a bare GET of that url. No request body, no query string, no identifying header: no instance id, no version, no workspace count, no telemetry of any kind. The maintainer’s server therefore learns the requesting IP address, the same thing any web server learns, and nothing else. Changing that would be a new decision, a new paragraph here and a new consent, never an implementation detail.

​
What the service does not do

These are commitments, not aspirations, and each is visible in the code.
  • No authenticated access. Nothing signs in to a store, uses a developer account, or reads anything behind a login.
  • No private data. The one private field asobeast handles, the iOS keyword field, is typed in by the app’s owner because it cannot be read from anywhere. That is the exception that proves the rule.
  • No circumvention of access controls. No paywall bypass, no token forging, no undocumented internal endpoint that a store protects.
  • No CAPTCHA solving. If a store challenges a request, the request fails and the job retries later. There is no solver, no third party solving service and no plan to add either.
  • No republishing. Collected data is shown to the customer who asked for it. It is not sold, syndicated or offered as a dataset, and the terms forbid customers doing so.

​
Rate limiting is good citizenship, not just cost control

Collection is deliberately slow. The App Store worker runs one job at a time behind a limiter defaulting to 15 requests per minute; Google Play runs at 10 job starts per minute, and a Play job fans out to several requests, so its effective ceiling is lower still. Those limits exist because a store serving a request for free should not have to absorb a burst. They also happen to protect the collection, since an address that gets throttled stops producing data. The two interests point the same way, which is the comfortable case. The daily run sheds load rather than pushing harder. When demand passes capacity it drops the least valuable work first and lets the run finish late, and registration on the hosted service is gated before capacity is exceeded rather than after.

​
Self hosted and hosted are not the same thing

Pretending they are would not be credible. A developer checking their own app’s rank from their own machine is an ordinary use of a public page. A service making a large volume of requests through a proxy pool is a different thing, and it carries obligations that the first case does not: keeping the rate down, keeping the volume attributable, and answering for it. The hosted service uses datacenter addresses, not residential ones. Residential egress routes requests through other people’s connections, and beyond the cost, borrowing a stranger’s address to make a request they did not ask for is not a position worth defending. It stays configured as a small emergency fallback with a hard monthly cap, never as the primary path.

​
If a store objects

The honest answer is that Apple and Google decide what they serve, and neither owes this service anything.
  • If a store blocks the collection, collection stops. There is no escalation, no evasion and no rotation designed to defeat a block.
  • If a store asks the service to stop, it stops, and customers are told what changed and what it means for their plan.
  • If a store changes what it serves, the service changes with it, which may mean reduced depth or a store that is no longer covered.
That is also why the terms of service disclaim accuracy and state the dependence on Apple and Google directly rather than in a footnote. A product whose input can be withdrawn should say so before a customer depends on it.

​
Why the licence matters here

The code is AGPL-3.0-only. Every claim on this page is checkable against the source, including the ones that would be convenient to break quietly. It also means the collection is available without paying anyone: a developer who wants only their own data can run the whole thing themselves, from their own address, at their own volume. Charging for hosting rather than for features keeps that path real, and a real self hosted path is what makes this posture something other than a marketing statement.
Last modified on August 29, 2026