What permissions Storeline needs

Storeline can’t do anything until you connect a key, so it is fair to want the details before you sign up rather than after. This page lists the exact role and permissions to grant, what Storeline reads, what it writes, and what it never touches.

Grant the narrowest thing that works. Where a permission gives more access than we’d like, that is said plainly below rather than left out.

App Store Connect

Storeline needs an App Store Connect API key: an Issuer ID, a Key ID, and the .p8 private key file. You create it in App Store Connect under Users and Access → Integrations → App Store Connect API. Apple lets you download the .p8 once, and keeps no copy.

Which role to select

Select App Manager, not Admin. Admin can create and delete users on your team; Storeline has no use for that, and a key that can do it is a key you have to guard accordingly. App Manager is the narrowest role that covers every call Storeline makes.

Marketing is narrower again, and may be enough if you only use Storeline for listing metadata and screenshots — but it does not cover in-app purchases, subscriptions, or their pricing, so those features will fail with it. Apple’s role permissions matrix is the authority on what each role reaches.

Team keys reach every app. Individual keys don’t.

This is worth knowing before you generate one. In Apple’s words, “Team API keys can access all apps, regardless of their role”. There is no way to limit a team key to one app. An Individual key, generated from your own user profile, instead carries the access of the user who made it — so a user with App Manager access to only some apps produces a key scoped to only those apps.

Apple excludes three things from individual keys: provisioning endpoints, Sales and Finance, and notarization. Storeline calls none of them, so an individual key works for everything here. If you want the tightest possible setup, that is it.

What Storeline reads and writes

What it never touches

Even with App Manager, a key can reach more than Storeline uses. These are the parts it never calls — no request is made to any of them:

• Sales, finance and payment reports. Storeline never reads your revenue.
• Submitting or releasing a version. Storeline edits the metadata of an editable version. It never creates a version, submits your app for review, releases it, or changes a phased release.
• Your app’s price and availability. Storeline sets in-app purchase and subscription prices when you ask it to. It never changes what the app itself costs or where it sells.
• Builds and TestFlight. No build uploads, no beta groups, no testers.
• Customer reviews, users, and certificates. Storeline neither reads reviews nor touches your team or signing identities.

That list is enforced, not just stated: a test asserts that none of 13 API resources appears anywhere in the code that talks to Apple, so a future feature can’t quietly start calling one.

Google Play

Storeline needs a service-account JSON key file. You create the service account in Google Cloud, then invite it in Play Console under Users and permissions and grant it access to the apps you want Storeline to manage.

Grant permissions per app, not account-wide. Leave every account-level permission unchecked — Storeline needs none of them.

Grant these

• View app information (read-only) — Reads the app and its current listings. Nothing works without it.
• Manage store presence — The listing itself — text, images, and in-app product and subscription details. This is the permission Storeline exists to use.

Only if you use the feature

• Release to production, exclude devices, and use Play App Signing — Only to push “What's new” to the production track. Release notes live on the release object, not the listing, so Play has no narrower permission for them. Skip it and every other feature still works.
• Release apps to testing tracks — The same thing for a testing track instead of production.
• View app quality information (read-only) — Only for the Android vitals panel. Read-only, and unnecessary if you don't open it.

The release permission is the one place Play makes you grant more than you’d want. Release notes are stored on the release, not on the store listing, so there is no “edit release notes” permission to grant instead. If that is more access than you are comfortable giving, leave it off: Storeline will manage your listings, screenshots, subscriptions and translations without it, and only the Play “What’s new” push will be unavailable.

When Storeline does write release notes, it reads the track back first and rewrites it with the version codes, rollout percentage, status and country targeting exactly as they were. It changes the notes and nothing else.

Leave these off

• View financial data — Storeline never reads revenue, orders or payouts.
• Manage orders and subscriptions — This grants refunds and cancellations. Editing subscription listings and prices comes under Manage store presence instead.
• Manage policy declarations — Content ratings and declarations are yours to make.
• Reply to reviews — Storeline does not read or write reviews.
• Admin (all permissions) — Never needed, and it grants everything above.

What Storeline reads and writes

What it never touches

Storeline never uploads an APK or App Bundle, never starts or stops a rollout, never reads orders, purchases or payouts, and never reads or replies to reviews. As with Apple, a test asserts that none of 9 Play API resources appears in the code that talks to Google.

Permission names above are Google’s own; their permissions reference describes what each one grants.

AI provider keys are optional

Storeline does not resell AI. If you want the AI features you connect your own provider key — Anthropic, OpenAI, Google, or another — and the calls run against your account at your cost. No key, no AI features; everything else works exactly the same.

These are the features that need one:

• Translation — Translating your listing, release notes and Studio captions into other languages.
• Keyword and title research — The /keywords finder, title and subtitle suggestions, and description drafting.
• Listing fixes — Rewriting a field that is over its limit, or reads badly in a locale.
• In-app event copy — Drafting event names and descriptions.
• Generated imagery — Studio backgrounds and event artwork, using an image provider key.

Everything else — editing listings in every language, screenshots, Studio, pushing to both stores, version history and undo — works with no AI key connected at all.

Revoking access

Every key you connect can be revoked at the source, without involving Storeline. This is your kill switch, and it does not depend on us doing anything.

• App Store Connect: Users and Access → Integrations → revoke the key. It stops working immediately, for us and for anyone else holding it.
• Google Play: Play Console → Users and permissions → remove the service account, or delete the key in Google Cloud. You can also narrow its permissions instead of removing it.
• AI providers: delete the key in the provider’s dashboard.

Removing a key inside Storeline deletes our stored copy permanently, but it does not revoke the key at Apple or Google — only they can do that. If a key may have been exposed, revoke it at the source too. How Storeline stores your keys is on the security page.

Questions

If something here is unclear, or you want a permission justified before you grant it, email support@storeline.dev.