Permissions and data flow

Know what PubShip can reach before you connect it.

Google decides what your service account may do. Your configuration narrows it further. PubShip never widens either.

Runs
On your computer, started by your client
Credentials
Yours, read from a local file path
Default
Reads only
Project-run service
None

The path of one request

Local, not offline: PubShip calls Google directly, and the result returns to your client.

  1. Client

    1

    You ask. The client calls a PubShip tool, such as list_releases.

  2. PubShip

    2

    Checks the method contract and your app allowlist before any credential is used.

  3. PubShip

    3

    Gets a short-lived token from your configured credentials. Tokens are never printed.

  4. Google

    4

    Checks the service account's Play Console permissions and answers over HTTPS.

  5. Client

    5

    PubShip returns the permitted result to your client, with scope and freshness context where available. Your client's data handling applies.

Three layers decide access

The ceiling

Google Cloud and Play Console

API enablement and the service account's permissions. Enforced on every request.

Narrows access

Your PubShip configuration

Environment allowlists name the apps PubShip may read and, separately, any it may change.

Runs and keeps results

Your MCP client

Starts PubShip, calls its tools and stores the conversation under its own policies.

Reads by default. Changes when you opt in.

Each workflow has its own opt-in. App-based scopes narrow your read allowlist; account administration uses separate exact account, user, app and method scopes. Google permissions still apply.

Read tools available by default; Google access still needs configuration

  • Releases, reviews, Android vitals and catalogGOOGLE_PLAY_PACKAGES
  • Bulk reports (requires your report bucket and Google bulk-report permission)GOOGLE_PLAY_REPORT_BUCKET

Off until you opt in

  • Sensitive reads: orders, purchases, testersGOOGLE_PLAY_SENSITIVE_READ_PACKAGES
  • Stage store-listing textGOOGLE_PLAY_WRITE_PACKAGES
  • Stage track releasesGOOGLE_PLAY_TRACK_PACKAGES
  • Create, validate, discard or commit editsGOOGLE_PLAY_EDIT_PACKAGESAlso requires the app in GOOGLE_PLAY_WRITE_PACKAGES.
  • Other change workflowsEdit resources, products, purchases, users, artifacts: each has its own opt-in.

NeverVoided-purchase data is disabled in every execution path by project policy.

Every method and its opt-in, on GitHub

How a change is applied

  1. Prepare

    Returns the exact request, its effects and a single-use operation ID. Nothing changes yet.

  2. Review

    Check the app, edit and values. Acknowledging records intent; it is not proof of review.

  3. Apply once

    Same ID as confirmation. PubShip rechecks state and sends the request once. No retries.

  4. Read back

    Where supported, a fresh read is reported separately. Staged is not published.

Preparations last up to 10 minutes and are lost on restart. Preparations for existing edits also expire with the edit. Listing and track staging do not publish. Committing an edit requires the separate edit lifecycle opt-in; other write workflows can change live resources. If a write’s outcome is uncertain, inspect the current state before preparing again. PubShip does not retry it.

Data handling, self-hosting and evidence

Where your data goes

From Google to PubShip on your computer, then to your MCP client. Sensitive reads return raw fields, including personal information. The PubShip project receives nothing.

Self-hosting is for your own accounts

pubship-server needs an exact email allowlist and keeps enrollment closed by default. There is no project endpoint.

Self-host guide

Coverage and evidence

170 implemented methods from 172 inventory definitions. Tests use synthetic providers; implementation is not a claim of live Google verification.

Verification index