Gpc User Management

gpc-user-management

Manage developer account users, permissions, and testers with GPC.

When to use

• Inviting or removing users from a Google Play developer account
• Updating user permissions (developer-level or per-app)
• Listing and auditing who has access to the developer account
• Adding or removing testers from testing tracks (internal, alpha, beta)
• Importing testers in bulk from a CSV file
• Setting up Google Group-based tester access

Inputs required

• Authenticated GPC — gpc auth status must show valid credentials
• Developer account ID — required for user commands (--developer-id or GPC_DEVELOPER_ID)
• App package name — required for tester commands and per-app grants (--app)
• Email addresses — for inviting users or adding testers
• CSV file — for bulk tester import (--file)

Procedure

0. Verify setup

gpc auth status
gpc config get app

User commands require --developer-id. Set it once:

export GPC_DEVELOPER_ID=1234567890

Or pass it per command: gpc users list --developer-id 1234567890.

1. Users — list and inspect

# List all users in the developer account
gpc users list --developer-id 1234567890

# Get details for a specific user
gpc users get user@example.com --developer-id 1234567890

# JSON output for scripting
gpc users list --developer-id 1234567890 --json

2. Users — invite

Invite a new user with developer-level permissions and optional per-app grants:

# Invite with developer-level permissions
gpc users invite user@example.com \
  --role VIEW_APP_INFORMATION VIEW_FINANCIAL_DATA \
  --developer-id 1234567890

# Invite with per-app grants
gpc users invite user@example.com \
  --grant "com.example.app:VIEW_APP_INFORMATION,MANAGE_TESTING" \
  --developer-id 1234567890

# Combine developer-level and per-app permissions
gpc users invite user@example.com \
  --role VIEW_APP_INFORMATION \
  --grant "com.example.app:MANAGE_PRODUCTION_RELEASES" \
  --developer-id 1234567890

# Preview first
gpc users invite user@example.com \
  --role VIEW_APP_INFORMATION \
  --developer-id 1234567890 \
  --dry-run

Read: references/permissions.md for the full list of developer-level and per-app permission constants.

Note: Permission changes may take up to 48 hours to propagate across Google's systems.

3. Users — update permissions

# Update developer-level permissions
gpc users update user@example.com \
  --role VIEW_APP_INFORMATION VIEW_FINANCIAL_DATA MANAGE_ORDERS \
  --developer-id 1234567890

# Update per-app grants
gpc users update user@example.com \
  --grant "com.example.app:MANAGE_PRODUCTION_RELEASES,MANAGE_TESTING" \
  --developer-id 1234567890

# Preview changes
gpc users update user@example.com \
  --role VIEW_APP_INFORMATION \
  --developer-id 1234567890 \
  --dry-run

4. Users — remove

# Preview removal
gpc users remove user@example.com --developer-id 1234567890 --dry-run

# Remove
gpc users remove user@example.com --developer-id 1234567890

5. Testers — list

# List testers for a track
gpc testers list --track internal
gpc testers list --track alpha
gpc testers list --track beta

# JSON output
gpc testers list --track beta --json

6. Testers — add and remove

# Add individual testers (Google Group emails or individual emails)
gpc testers add tester1@gmail.com tester2@gmail.com --track internal

# Add a Google Group
gpc testers add testers-group@googlegroups.com --track beta

# Add testers without auto-submitting changes for review
gpc testers add tester1@gmail.com --track beta --changes-not-sent-for-review

# Fail if the app is currently in review or rejected before modifying testers
gpc testers add tester1@gmail.com --track beta --error-if-in-review

# Remove testers
gpc testers remove tester1@gmail.com --track internal

# Remove testers without auto-submitting changes for review
gpc testers remove tester1@gmail.com --track internal --changes-not-sent-for-review

# Preview changes
gpc testers add tester1@gmail.com --track beta --dry-run

7. Grants — standalone per-app permission management

gpc grants manages per-app permissions independently from user invitations. Use this when you need fine-grained control over what individual users can do on specific apps.

# List all grants for a user
gpc grants list user@example.com --developer-id 1234567890

# List grants for a specific app
gpc grants list user@example.com \
  --developer-id 1234567890 \
  --app com.example.app

# Create a new per-app grant
gpc grants create user@example.com \
  --app com.example.app \
  --permissions MANAGE_PRODUCTION_RELEASES VIEW_APP_INFORMATION \
  --developer-id 1234567890

# Update existing grant permissions
gpc grants patch user@example.com \
  --app com.example.app \
  --permissions VIEW_APP_INFORMATION \
  --developer-id 1234567890

# Remove a per-app grant (revokes app-specific access)
gpc grants delete user@example.com \
  --app com.example.app \
  --developer-id 1234567890

When to use gpc grants vs gpc users update --grant:

• Use gpc grants for managing grants on existing users without modifying their developer-level role
• Use gpc users invite --grant or gpc users update --grant when also changing the user's account-level permissions

New in v0.9.87: grants list and testers list now return the unified --json envelope { <key>, nextPageToken, meta.count, message? }, matching other list commands. Scripts reading a bare array will break — update to destructure the keyed field. testers list also emits googleGroups: [] when a track has no Google Groups configured (the items key is always present). users list shares the same envelope as of GPC v0.9.83.

Read: references/permissions.md for the full list of per-app permission constants.

8. Testers — bulk import from CSV

Import testers from a CSV file containing email addresses:

# Preview import
gpc testers import --track beta --file testers.csv --dry-run

# Import
gpc testers import --track beta --file testers.csv

CSV format — one email per line:

email
tester1@gmail.com
tester2@gmail.com
qa-team@googlegroups.com

Read: references/tester-workflows.md for common tester management patterns and Google Group best practices.

Verification

• gpc users list --developer-id <id> returns current users with their permissions
• gpc users get <email> --developer-id <id> shows the user's current role and grants
• gpc testers list --track <track> returns testers for the specified track
• All --dry-run commands show what would change without modifying data
• JSON output works on all commands (--json flag)
• Permission changes may take up to 48 hours to propagate

Failure modes / debugging

Related skills

• gpc-setup — authentication and developer account configuration
• gpc-release-flow — releasing to testing tracks that testers access
• gpc-ci-integration — automating tester management in CI/CD pipelines