User reviews for an app
app_reviews is a $0.20 GET request on the Wuthering AI API. Read what users actually say about an app, filtered by rating. It answers complete JSON, and a call that fails is not charged.
Endpoint
GET /v1/app_reviews
Price per successful call
$0.20
Failed calls
Not charged
curl 'https://wutheringai.com/v1/app_reviews?platform=…&token=YOUR_TOKEN'
What does app_reviews return, and when should you call it?
Return recent user reviews for an app, with rating, title, body text, version, and date.
The highest signal per unit of spend in this whole catalogue: low-star reviews name the unmet need in the buyer's own words, which is exactly the language that belongs in positioning and keyword work.
Returns: rating, title, review_text, profile_name, version, timestamp, and on Android also helpful_count and dev_response.
Use to find the complaint a competitor has not fixed. Don't use for aggregate scores, which wuthering_app_details already carries.
What parameters does app_reviews take?
app_reviews accepts 7 parameters, of which 2 are required. Array values are comma-separated on the query string.
| Parameter | Type | Required | Description |
|---|---|---|---|
| platform | string | yes | Which store to query: 'ios' for the Apple App Store, 'android' for Google Play.One of: ios, android |
| app_id | string | yes | App identifier, in the format the chosen platform uses: a numeric id for 'ios' (for example 284882215), a reverse-DNS package name for 'android' (for example com.example.app). An identifier in the wrong format is billed rather than rejected, so confirm it before calling: your own web search finds it fastest (site:apps.apple.com "Acme", where the id is the number after /id in the URL), and wuthering_app_search does the same for a billed call. |
| depth | number | no | Maximum rows to return (1 to 1000, default 100). Ask for the fewest that answer the question: every row is billed and spends the caller's context.Defaults to 100 |
| sort_by | string | no | Review ordering. 'most_recent' surfaces current problems; 'most_helpful' surfaces the ones other users voted up.One of: most_recent, most_helpfulDefaults to most_recent |
| location_code | number | no | Numeric location code to scope results to. Defaults to 2840 (United States). Search volume and competition vary sharply by country, so set this when the question is about a specific market.Defaults to 2840 |
| language_code | string | no | ISO language code for results, for example 'en' or 'de'. Defaults to 'en'.Defaults to en |
| task_id | string | no | Only for resuming, and normally omitted. These store endpoints are queued rather than immediate: the tool submits the request and waits up to 90 seconds for it. That is enough for almost every call, but a large review or chart request can exceed it, in which case the tool fails with a message containing a task id. Passing that id here collects the finished result without submitting, or being billed for, the work a second time. |
Which playbooks call app_reviews?
5 of the research playbooks name app_reviews in their method. Each is free to read and says where in the sequence the call belongs.
- Is there real demand for this?Test an idea against the cheapest evidence that could kill it — search demand, sustained ad spend, posted salaries, and the words buyers use — and return a verdict with the number that decides it.
- Where is the unoccupied position in this category?Map the category around one domain as an idea maze — the forks it has already run, who took each branch, which walls are still walls and which have moved — then return the one open position with the offer that takes it: buyer, bundle, price metric and message, decided together.
- Who are we really up against?Work April Dunford's positioning sequence from public evidence: the alternatives a prospect would actually use, what only you do, the value that follows, who cares most, and the category that makes all of it obvious.
- What do we charge, and does the money work?Anchor price against what competitors actually charge and meter on, size willingness to pay from what the problem costs today, then run CAC, LTV and payback across three scenarios.
- What should we build next?Gather the language of people switching into and out of this category, code every quote to the force that drives it, size each theme against real search demand, and return a 50/50 roadmap.
Reference for app_reviews · last updated · published by Wuthering AI