Skip to main content
Much of Appeeky Spec runs on accounts you already have. The providers bill you directly, keys stay on your machine, in your CI secrets or in your server’s .env, and no Appeeky account is needed. These need APPEEKY_API_KEY: keyword popularity and opportunities, Google Play ranks and category chart, analytics and revenue in verify and data pull, reviews, competitors, Meta and TikTok, AI Visibility through Appeeky, social accounts and UGC personas from Appeeky. Run doctor to see what is set up. In CI, add each key as a repository secret; on a server, put it in the Docker .env.

Store keys

Both store CLIs keep named accounts in your user config (~/.config/appstore/, ~/.config/gps/), never in the repo. init offers to save them; by hand:
Pick an account per app with stores.appStore.account and stores.googlePlay.account. In CI, set ASC_KEY_ID, ASC_ISSUER_ID, ASC_PRIVATE_KEY and GOOGLE_APPLICATION_CREDENTIALS instead. See App Store Connect CLI install and Google Play CLI install.

AI visibility

Any of these keys adds that assistant:
--dry-run quotes the cost in USD and asks nothing; without it, the scan asks before spending (--yes skips the question). aiVisibility.models limits which assistants are asked. On a schedule, set VISIBILITY_EVERY (days, for example 7) as a repository variable or in the Docker .env; the daily routine runs visibility scan --local --every $VISIBILITY_EVERY --yes and scans only when a storefront is due. See AI answers.

Google Search Console

  1. In Google Cloud, create a service account and enable the Search Console API.
  2. In Search Console, add the service account’s email as a user of the property.
  3. Set GSC_CREDENTIALS to the JSON key, or to its path.
On your own machine, gcloud auth application-default login with the webmasters.readonly and cloud-platform scopes works too. In CI, the Google Play service account works as well once its email is a user of the Search Console property. Then:
The property is web.searchConsole, or the domain of web.url. The daily routine runs seo pull when GSC_CREDENTIALS is set.

DataForSEO

With your own DataForSEO account, set DATAFORSEO_LOGIN and DATAFORSEO_PASSWORD from its API access page. Each one quotes with --dry-run and asks before spending (--yes skips the question). The daily routine runs seo ranks --every 7 --yes when DATAFORSEO_LOGIN is set; SEO_RANKS_EVERY changes the days. The weekly agent is not allowed to run the paid ones.

Apple Search Ads

  1. In Apple Search Ads → Account Settings → User Management, invite an API user with a read role (for example API Account Read Only).
  2. Sign in as that user, open Account Settings → API and upload the public key of an EC key pair.
  3. Save the key on the same App Store Connect CLI account that holds your App Store Connect key, so the private key never leaves the CLI:
Spec uses stores.appStore.account, or the CLI’s default account. When the key reaches more than one organization, set stores.appStore.searchAds.orgId; campaigns limits it to some campaigns. In CI, where there is no CLI account, set ASA_CLIENT_ID, ASA_TEAM_ID, ASA_KEY_ID and ASA_PRIVATE_KEY (the PEM or its path); they win over the account. Only the campaigns for stores.appStore.appId are read. ads and verify read ad_installs and cpa from appeeky/search-ads/. The daily routine pulls it when ASA_CLIENT_ID is set. Key setup in detail: Apple Search Ads in the App Store Connect CLI.

UGC clips on fal

ugc generate --local makes clips where Spec runs, with your own fal key, instead of in Appeeky with media credits. fal bills your account.
The persona is one from Appeeky (needs APPEEKY_API_KEY) or one kept in appeeky/ugc/personas/. With FAL_KEY as a secret, the push workflow and the Docker push routine render locally too. See UGC clips.