If you work with an agent in a repo, the fastest way to get good results from the AppTweak API is to put the context in the repo rather than re-explaining it every session.
Two mechanisms, and you can use both:
start-here-guide— an MCP tool that returns the current spec map and gotcha list. Always up to date, costs nothing, but only your agent can read it. Have it called at the start of every session.- A context file in your project — persists across sessions, survives context compaction, and you can read and edit it yourself. That's what this page gives you.
Drop this in your project
Save it as AGENTS.md at your repo root, or under whatever filename your tool expects — CLAUDE.md for Claude Code, a rule file for Cursor. Trim the sections you don't need.
# AppTweak API — context for agents
## Connection
MCP server: `https://developers.apptweak.com/mcp`
Auth: `x-apptweak-key` header. Key lives at https://app.apptweak.com/apt-api
Rate limit: 60 requests / 10 seconds.
Call `start-here-guide` first in every session — it carries the current gotcha list,
which may be ahead of this file.
## Which spec
Three OpenAPI specs are indexed. Pass the exact title to `get-endpoint` / `list-endpoints`.
- `apptweak-store-api` — the main ASO dataset: app metadata and metrics, category and
keyword rankings, reviews, keyword metrics, top charts, paid keyword bids.
- `apptweak-integrations-api` — data from accounts the customer has connected
(App Store Connect, Google Play Console). Requires the connection to already exist.
- `apptweak-api` — utilities: credit balance and usage, valid countries and languages,
DNA reference data, tracked-applications CRUD.
## Free vs. paid
Documentation tools (`list-specs`, `list-endpoints`, `search-endpoints`, `get-endpoint`,
`search`, `fetch`, `start-here-guide`, `app-id-lookup`, the `*-guide` tools) cost
nothing and need no API key.
`execute-request` is the only tool that calls the API, the only one that needs the key,
and the only one that spends credits.
Design the whole integration from documentation before executing anything.
## Cost rules — read before executing
- Every request costs 1 credit, plus the price of each datapoint actually returned.
- Historical endpoints: the datapoint's base price for the first available day, then
10% of it per additional day. **One range call is far cheaper than N single-day calls.**
A 10-credit datapoint over 30 days costs 39, not 300.
- Downloads and revenues are the expensive ones: 500 base, 50 per extra day. A 45-day
downloads request for one app is 2,701 credits. Category metrics and conversion
benchmarks are 1,000 base.
- Batch. Most endpoints take several apps or keywords per call and you pay 1 credit per
request regardless.
- Smoke-test new calls with `limit=1`, then read `metadata.request.cost` before scaling.
- Every response carries `cost` (what was charged) and `max_credit_cost` (the pre-flight
worst case). It does **not** carry remaining balance — for that, call the usage/credits
endpoint on `apptweak-api`. **That call is free**, so check the balance at the start of
any heavy session and between large batches.
- Tell me before any single call over 1,000 credits.
## Gotchas — these produce wrong answers, not errors
1. **`country` / `language` are free text, not enums**, and store endpoints link to a static docs page rather than the live list. If a code is rejected, call the
`countries` and `languages` endpoints on `apptweak-api` instead of guessing.
2. **iOS and Android integration reports are not symmetrical.** iOS reports break down by
device and in-app event only. There is no iOS equivalent of the Android
channel / traffic-source breakdown. Don't assume parity.
3. **A 200 with empty data from `apptweak-integrations-api`** usually means the customer's
App Store Connect or Play Console account isn't connected — not a bug, and not
"no data exists".
## Endpoint quirks worth knowing
- Keyword rankings history accepts **max 5 keywords per call**. Batch accordingly.
- Top charts: iOS uses numeric category IDs, Android uses category names. Call
`get-endpoint` for the lists.
- Reviews split across three endpoints — search by keyword or rating
(`/apps/reviews/search.json`, supports `term` and `replied`), ratings distribution over
time (`/apps/reviews/stats.json`), and what's currently on the store page
(`/apps/reviews/top-displayed.json`). To find complaints, run several `term` searches
("crash", "bug", "price", "cancel") rather than one broad pull.
- Don't know an app's store ID? Use `app-id-lookup` — it takes a name or store URL and
costs nothing.
- Google Play Console installs per keyword with a branded / generic / competitor
breakdown: use `gpc-keyword-installs-guide`, don't assemble it from raw endpoints.
## Preferred workflow
For anything that runs more than once: use the MCP to find the endpoints and confirm the response shape, then write code that calls the API directly. Don't route bulk data through the conversation.llms.txt
llms.txtWe publish developers.apptweak.com/llms.txt — an index of every documentation page with a one-line description, in the llms.txt format. Agents that support it can use it to navigate the docs without the MCP at all. Useful when you want documentation context in a tool that isn't MCP-capable.
Recipes
Recipes are ready-made Python and Ruby scripts for concrete use cases. They're a good starting point to hand an agent: "adapt this recipe to do X" produces better results than "write this from scratch", and the recipe already encodes the right endpoint choices.
Keeping it current
The gotcha list changes as we fix things. start-here-guide is the live version; the snippet above is a snapshot. If your agent reports something that contradicts this file, trust the tool and update your copy.