List all tracked mobile applications. Returns each app with its store metadata: title, description, app_id (bundle ID), store (ITUNES or GPLAY), country, lang (BCP-47), icon URL, screenshots, developer name, genre, version, rating score, number of ratings, the count of tracked keywords, and aso_health (the listing audit: global score plus its coverage, targeting and appeal axes, or null on an app the audit has not reached yet; get_aso_health returns the breakdown behind it). Usually the first call of a workflow: the numeric internal ID it returns is what track_keywords, add_competitor, get_app_score_history and the other app-scoped tools expect, whereas add_application takes the store bundle ID instead. Read-only.

Track a new mobile application by its store bundle ID. The app metadata is fetched from the store, an initial visibility score is computed, and the app is linked to the user workspace. Counts against the plan app cap.

List tracked keywords with ASO metrics. Returns each keyword with: keyword text, store, country, lang, difficulty_score (0-100), traffic_score (0-100), current_rank, ahead/behind (the apps ranked immediately above and below yours), the top 5 apps ranking for this keyword (in ranking order, rank 1 to 5), is_favorite flag, and the tracking start date. current_rank comes from the latest daily ranking snapshot and is null when the app is not in the top 100 for that keyword, in which case ahead and behind are null too. A null rank always means "not ranked", never "unknown": the tool errors out rather than returning partial rank data. Paginated.

Deep-analyze any keyword (even ones you don't track). Returns difficulty_score (0-100), traffic_score (0-100), KEI with score and level (e.g. "good"), the top 20 apps currently ranking for it (with rank, app_id, title, icon, genre, rating), related keyword suggestions from search and keyword sources, and whether you already track this keyword. Inspecting a keyword you already track does not consume the inspection quota.

List the keywords you have previously inspected, with their last inspection date and current difficulty/traffic scores. Useful to revisit past keyword research without consuming the inspection quota again.

Get the daily rank history of one tracked keyword, with one series per app that tracks it. Returns keyword, store, country, lang, the resolved from/to dates, and apps[] entries holding app_id, app_title and history[] of { date (YYYY-MM-DD), rank }, one entry per day a ranking run measured: rank is null on days the app did not rank, and a day not measured yet (today before the daily update) is omitted. Each app entry also has events { notes[], app_updates[], store_updates[] } over the range: the user's notes on the app, its updates detected, and the store algorithm updates of the keyword's market, what may explain a move. Defaults to the last 30 days, shortened to the plan's history window. An explicit start date older than the plan's history returns a PLAN_LIMIT result; any request reaches back 400 days at most. Reversed dates are swapped and future dates are clamped to today. Pass keyword_id from list_keywords, and app_id to narrow the output to one app. For the visibility of a whole app rather than one keyword, use get_app_score_history.

Mark or unmark a tracked keyword as favorite for a specific app. Favorites are stored per tracking row (profile + app + keyword), so a keyword tracked across multiple apps has independent favorite states. Both keyword_id and app_id come from list_keywords results.

Track up to 20 new keywords for one of your applications in a single call. Each keyword triggers an immediate ranking fetch. Already-tracked keywords return a per-keyword error in results; previously removed keywords are reactivated automatically. Use app_id from list_applications results.

Stop tracking a keyword for the specified app (soft delete). The historical ranking data is preserved; re-adding the same keyword reactivates the row. Idempotent: calling on an already-removed row returns success.

Get the daily visibility score history of one application. The visibility score (0-100) summarises how discoverable the app is across a stable set of keywords from its niche, the same set over time, so two dates are directly comparable. Returns app_id, app_title, the resolved from/to dates, and history[] of { date (YYYY-MM-DD), score }, where score is null on days with no snapshot, plus events { notes[], app_updates[], store_updates[] } over the range: the user's notes, the app updates detected and the store algorithm updates of its market, what may explain a move. To measure what followed each event, use compare_events. Defaults to the last 30 days, shortened to the plan's history window. An explicit start date older than the plan's history returns a PLAN_LIMIT result; any request reaches back 400 days at most. Reversed dates are swapped and future dates are clamped to today. Pass the numeric internal ID from list_applications, not the store bundle ID. For one keyword rank over time, use get_keyword_rank_history.

List the notes on an application's charts: what the user did on a day ("launched a Reddit giveaway", "changed keywords"), to read the visibility and ranks against it. Returns app_id and notes[] of { id, number, day (YYYY-MM-DD), text, scope }, oldest first. number is the note's rank among all the app's notes, the number the charts print on its flag; scope is "app" for a note shown on every market of the app, "market" for one shown on this market only. Pass the numeric internal ID from list_applications. To see what followed each note, use compare_events. Read-only.

Add a note to an application's charts for something done on a day: a campaign, a metadata change, a launch, a price change. It shows as a flag on the visibility and keyword rank charts, and compare_events then measures the visibility and ranks before and after it. Returns { app_id, note: { id, day, text, scope } }. The day is today or earlier; a future day is refused.

Change the text, the day or both of a note; a field left out keeps its value. Pass the note id from list_notes. A note moved to an earlier or later day can renumber the others. Returns { note: { id, day, text, scope } }.

Delete a note from an application's charts. Pass the note id from list_notes. The notes after it are renumbered. Returns { id, deleted: true }.

Measure what followed each event of an application: the user's notes and the app updates detected, newest first, over the last year. For each event, the average over the window days before against the same number of days after (the event day itself in neither): the app's visibility score (0-100, higher is better) by default, or with keyword_id, that keyword's rank for the app (lower is better, so a negative change means the app climbed; a day outside the top 100 counts as #101, and unranked_days says how many there were). Returns metric, window_days, history_start, total (how many events there are) and comparisons[] (the newest limit) of { day, notes[], app_updates[], before, after, change, locked, alongside }, where before/after hold { from, to, average, measured_days, pending_days (not measured yet), hidden_days (before the plan's history) }. alongside names the other notes, app updates and store algorithm updates inside the same days: a comparison describes what followed an event, not what caused it, so read it with them. Read-only.

Get the full ASO Health audit of one tracked app: how well its listing is WRITTEN, as opposed to how it currently ranks. Returns app (id, app_id, title, store, country, lang) so a score is always attributable, global (0-100), the three axes, the maturity tier with its label, every field, the terms it targets, flags[], and timeline[] of past releases with their score. THE AXES: coverage = how much searched vocabulary the indexed fields carry; targeting = whether the terms it aims at are winnable AT THIS APP'S SIZE; appeal = rating, screenshots and freshness. TIER drives targeting: 1 Emerging, 2 Growing, 3 Established. The verdict threshold moves with it, so the same term can be "ambitious" for a tier 2 app and "out-of-reach" for a tier 1 one, and a tier 3 app can reasonably aim higher. Say that when you explain a verdict. fields[].state is "scored", "empty" (blank on the store) or "missing" (the iOS keywords field, which Apple never publishes: we only know it if the user gave it to us). fields[].key stays "subtitle" on Google Play, where the store calls that field the short description: use the store's name when you talk to the user. fields[].text is TRUNCATED to a preview and fields[].truncated says so; the full text is on list_applications. targeting.keywords[].verdict is "reachable", "ambitious" or "out-of-reach"; traffic and difficulty are both 0-100. targeting.ungraded counts searched terms we have no competition data for; targeting.unsearched counts words nobody types, listed in unsearched_words. phrases[] lists the searched PHRASES the listing forms across its indexed fields (text, traffic 0-100, words with the field each comes from): a word nobody types alone still earns coverage when it completes one, and removing it breaks the phrase. targeting.assessable is false when the listing holds no searched term at all, and then there is no targeting to judge. report is null on an app the audit has never reached, which is not a score of zero. The audit is kept up to date automatically, so this reads a stored result and answers in milliseconds: call it as often as you need. For visibility over time instead, use get_app_score_history; to score a listing that does not exist yet, use simulate_metadata.

Check draft listing text against the stores' own rules, before spending a run measuring it. Per field: the length as the STORE counts it (UTF-16 code units, which is not what a character count gives you in most languages), the limit, what is left, and warnings[]. warnings[].level is "error" (the store would refuse this as it stands), "warning" (it costs you something, or a reviewer may object) or "info" (worth knowing, often counter-intuitive: emoji are allowed in a Google Play description but banned in the app name). warnings[].rule names the policy when one fired: "price", "ranking", "play-program", "call-to-action", "kids", "rival-platform", or null for a limit or formatting warning. THE TWO STORES ARE NOT SYMMETRICAL, and this is the most actionable thing the tool tells you: Google NAMES forbidden words and rejects, so the same term is an error there; Apple publishes no list and a reviewer decides, so it is a warning. A draft can be perfectly valid on one store and refused on the other. valid is false only when at least one field carries an ERROR: a draft can be valid and still carry warnings worth acting on, so read them. notes[] carries anything wrong with the request itself, such as sending a keywords field to Google Play, which has none. On the iOS keywords field it also returns keywords{terms, duplicates, too_short, phrases, wasted_on_spaces, wasted_on_duplicates}: phrases are multi-word entries, which Apple splits apart and recombines itself, so they gain nothing over their words. It is pure arithmetic over the text you pass, with no store lookup, so it answers instantly: run it on every draft you write, in a loop if that helps, and call simulate_metadata only once it comes back valid.

Score a listing that does not exist yet, on the same engine that audits the real ones, and see the gain or loss against the app's current score. WITH app_id: every field you leave out is read from that app's live listing AND its real context (rating, screenshots, age, languages), so { app_id, title } is a complete request and the delta is meaningful. This is the mode to use to answer "is my draft better than my listing". WITHOUT app_id: you must pass store, country and lang, and the context defaults to a listing NOBODY HAS PUBLISHED: no rating, no screenshot, one language. That deliberately floors the appeal axis, so the global score is NOT comparable to a real app's score and you must not present it as one. Compare the coverage axis instead, or pass context yourself to describe the app you have in mind. context works in both modes: any key you send overrides, any key you omit keeps the app's value (or the blank default). Returns app (null without app_id), aso_health with the three axes and the tier, delta against the app's stored score (null for a draft from scratch, and each axis is independently null when it was never computed), flags[], lost_phrases[] (with app_id: the searched phrases the live listing forms that the draft breaks, with the words it dropped and the app's rank when it tracks the phrase; the score alone does not warn about these, so always report them), the saved run, and notes[] for anything wrong with the request that did not stop it (a kw_field sent for a Google Play listing, which has none, is ignored and reported there). words_probed is how many words the run weighed; words_fetched is how many of those had to be read from the store for the first time. words_fetched: 0 means everything was already known and the call was fast; a high one is why a call took several seconds, and it warms the cache for everyone afterwards. Expect a few seconds per call. Check the draft with check_metadata first, and change something meaningful between two calls rather than polling it. Re-read a past run in full with get_metadata_simulation, or list them with list_metadata_simulations.

List the listing drafts already scored on this account, newest first, whether they were run from here or from the Metadata Simulator in the dashboard. Each row holds the draft TITLE ONLY, its market, the score it reached with the three axes, the app score it was measured against, whether it differed from the live listing, and how many times it has been re-run. It does NOT carry the subtitle, keywords field or description: pass a row's "id" to get_metadata_simulation to read a draft in full. Use this to find a past score without re-running it.

Read one saved listing draft in full: the four fields it was scored on, the context it assumed, the score it reached, and the findings behind it. This is what list_metadata_simulations cannot carry, and it is what makes a past run worth picking up: the text is here. Pass the "id" of a row from list_metadata_simulations, or the "saved.id" a simulate_metadata call returned. Read-only and instant.

List competitor tracking pairs. Each pair holds your app (id, app_id, title, icon, store only) and the competitor app with its full store metadata (title, description, url, icon, screenshots, developer_name, genre, version, score, ratings), plus both apps' visibility scores (app_score vs competitor_score, 0-100) for direct ASO comparison. Use list_applications to get the full metadata of your own app.

Add a competitor app to one of your applications, identified by the competitor's store bundle ID. The competitor metadata is fetched from the store and ranking entries are backfilled for every keyword tracked on the main app.

Remove a competitor relationship by its internal relation ID (the id field returned by list_competitors or add_competitor — note that this is the relation row id, not the competitor app id).

Fetch autocomplete suggestions from the App Store or Google Play for a given prefix (1-60 characters). Useful to discover what users are searching for that starts with a given seed. Consumes one autocomplete query and one API request.

List the autocomplete queries you have previously run, with the prefix, store, country, lang, suggestion count and last query date.

Run a niche analysis on a topic: discovers relevant keywords, clusters them into sub-niches, and scores each cluster's opportunity. Returns clusters with their keywords, opportunity scores, intent type, and an app concept suggestion. Cache hits (recent identical analyses, less than 7 days old) are returned instantly without consuming the niche analysis quota. Fresh analyses can take a few minutes.

List the niche analyses previously run, with topic, store, country, lang, cluster count, keyword count, top opportunity score and creation date. Paginated through page and per_page. Read-only: it re-reads work already done, so call it before run_niche_analysis to check whether a topic was already covered. It returns summary rows only, not the clusters and keywords themselves.

Get a store top-chart ranking (App Store or Google Play) for a country, category and collection, with daily rank movement. Returns the snapshot date and ranked apps (rank, app_id, apple_id, title, developer, icon, rating, price, currency, delta vs. yesterday, is_new). Category: pass "OVERALL" (default) for the overall chart, or a store category value (iTunes genre id e.g. "6014" for Games, or a Google Play category e.g. "GAME"). Collection: free (default), paid, or grossing.

List the categories and collections supported by the top_charts tool, per store. Use a returned category "key" (e.g. "OVERALL" for the overall chart, or a store value like "6014" / "GAME") and a collection (free, paid, grossing) as inputs to top_charts.

Get current account usage and plan limits: number of applications, keywords, competitors, keyword inspections, niche analyses, autocomplete queries and metadata simulations used vs. allowed, plus API request count for the current billing period.