Subscription figures are provider list prices recorded in treg.to’s own catalog grid; per-call prices are what treg.to charges today, with $0.000 added.
set up treg — https://treg.to/llms.txt
Using treg, search the Apple App Store and Google Play for apps matching a habit tracker, show me the price per search first, then put the results from each store in one table with developer, rating, review count and price, and mark the apps that appear in both.
Apple and Google Play are separate calls with separate app ids and separate rankings. One store is one search; both is two.
Store results are per storefront. The US list and the UK list are different lists, and the agent will pick for you if you do not.
The rows carry the developer, the rating, the review count, the price and the link. Name the ones you want or the whole listing comes back.
treg.to prints the rate before the call, so a hundred keywords across two stores has a number on it before anything runs.
treg.to holds the provider keys. Neither you nor the agent sees them.
The provider's own rate, $0.000 markup, from a prepaid balance.
Charged per call. $1.00 free per new team, no card to start.
Already pay Hunter? Register it and those calls are never metered.
Another provider is a different word in the prompt, not a new integration.
No SDK, no OAuth dance per vendor, no seats.
treg.to does not choose for you. It hands ChatGPT this comparison, with the price shown before any call, and ChatGPT picks. Or you tell it how: "cheapest", "most reliable", "the one that takes what I have", or a provider by name.
SerpApi at $0.015 · Apple App Store
| Provider | Success | Median | Sample |
|---|---|---|---|
| 100% | 1.3s | 30 calls | |
| 100% | 1.6s | 47 calls |
Measured on treg.to traffic: real calls, real inputs, and sample sizes differ by provider. Live reliability, not a controlled benchmark.
| Provider | Price | Accepts | Success rate | Verified |
|---|---|---|---|---|
| $0.015 per found | engine, term, country, lang, num, page | 100% (47 calls) | 2026-07-28 |
| Provider | Price | Accepts | Success rate | Verified |
|---|---|---|---|---|
| $0.015 per found | engine, q, gl, hl, apps_category, age | 100% (30 calls) | 2026-07-28 |
treg call serpapi.app-store.search.apps --query engine=apple_app_store --query term=coffee
Swap the id for any provider above. All 2 endpoints behind this job, with their parameters and captured responses, are on the Apple App Store, Google Play shelf.
App store threads are unusually seeded: of the ~140 Reddit and X posts read in August 2026, more than half were builders announcing their own scrapers, one ran the same review-scraper copy through seven subreddits, and one post seeded zero-width spaces at every paragraph break. These five are developers hitting the wall in public.
“The paid SERP APIs go deeper, but tools that don't pay for them and still show you 'rank #63' are interpolating, not measuring.” r/androiddev, 11 points
What this page can do about it: That is the honest ceiling and this page will not pretend past it. The rows return the store's own results in the store's own order, as deep as the store exposes them, and treg.to publishes no rank number of its own.
“As of this morning (April 16), all my requests to the /search endpoint are returning HTTP 404 Not Found.” r/iOSProgramming, 11 points
What this page can do about it: That is Apple's public iTunes Search endpoint, which is free, undocumented in practice, and not in this catalog. The rows here are a paid provider's store engines, billed only on a successful search, with what the live traffic shows rather than an uptime promise.
“To have to scrape them from the app store pages when everything else is so API first seems like a miss.” X, 19 likes
What this page can do about it: Agreed, and that is the whole reason this row exists. The agent sends a keyword and a country and gets rows; the scraping, the proxies and the markup changes are the provider's problem, at a price printed before the call.
“the itunes search api does not give downloads, subscriptions, or any financial metrics, and it does not provide subscription pricing either.” X, 69 likes
What this page can do about it: True, and neither do these rows. Listing price, rating and review count come back; installs and revenue do not exist in any public store response, and no provider on this page can conjure them.
“welp, even using a 1M token context limit, the data is too large.” r/shopifyDev, 77 points
What this page can do about it: Which is the argument for asking for columns rather than everything. Say which fields a row needs in the prompt, cap the result count, and the agent reads a table instead of drowning in a store dump.
SerpApi runs the Apple App Store engine and the Google Play engine at the same flat price per successful search, metered from your team's prepaid balance at SerpApi's own rate with $0.000 added, and its rate card says a failed or cached search is not billed. Both rows were verified against the live API on 2026-07-28. A new team's free dollar is a few dozen searches across both stores.
Apple's engine wants a search term; Google Play's wants a query, and the same row answers the store charts as well as a keyword search depending on what you send. Read the docs linked on each row before an agent loops, because treg.to relays the store's own response verbatim and models neither store's API.
This is search, not rank tracking: nothing stores yesterday's position, and there is no keyword popularity index, no download or revenue estimate and no review feed on these two rows. Google Play also stops exposing results publicly at shallow depth, which android developers have measured for themselves, so a position deeper than the first page or two is not a number any public search can honestly return. An agent can rebuild position over time by running the same search on a schedule you give it and keeping the results.
An app store API returns what a store's search results page holds, as data: the apps matching a keyword, in the store's own order, with the developer, the rating, the review count, the price and the listing link. It is not App Store Connect and it is not the Google Play Developer API. Those are the accounts you own, and they only cover your own apps. It is also not Apple's public iTunes Search endpoint, which is free, answers a different query shape, and is not in this catalog. The two rows here read the two public stores and relay what the store returned.
No. Both rows run on treg.to's own key and bill per successful search from your team's balance at SerpApi's rate with no markup. A developer account is for publishing apps and reading your own; this reads the public store.
No. Those two are your own account's APIs and they only see apps you publish: your installs, your ratings, your revenue. This page is the public store search, so it sees any app but none of the private numbers behind it.
Your agent can, by running the search on a schedule you set and keeping the results. treg.to has no scheduler, no history and no ASO rank tracker. The honest limit is depth: the stores expose only so many results, and a rank below that is a guess wherever you read it.
Not from these two rows. They return the search listing and nothing more. The catalog carries app review and app data endpoints from other providers on their own shelves, and Apple's keyword popularity is a relative index behind an Apple Search Ads account, not a search volume figure anyone can resell.