canonical: https://jentic.com/apis/googleapis.com/androidpublisher

# Google Play Android Developer API

The Google Play Android Developer API lets app developers manage their Google Play presence programmatically. The expected workflow is to insert an Edit, make changes (uploading APKs, AABs, listings, screenshots, release tracks), and commit the Edit to publish. The API also covers in-app product and subscription management, voided purchases, app recoveries, internal app sharing artifacts, data safety declarations, and device tier configurations.

## For AI agents

Manage Google Play app releases, in-app products, subscriptions, and store listings via Edits. Useful for agents automating release pipelines, subscription management, and Play Console operations.

## Scope

Does not handle device-side purchase flows, app build compilation, or device management - use for Google Play Console release, listing, and purchase validation operations only.

## Capabilities

- Roll out new APK or AAB releases through Edits and commit them to Play
- Manage in-app products and subscription offers with pricing and free trials
- Validate and acknowledge subscription and product purchases server-side
- Update store listings, screenshots, and graphic assets per locale
- Promote builds across internal, alpha, beta, and production tracks
- Submit data safety declarations and device tier configurations

## Use cases

### Automated release pipeline

CI systems open a Play Edit, upload the AAB, attach the release notes, and commit the Edit on the production track at a staged rollout percentage. This replaces clicking through the Play Console for every release and lets the team ship multiple times a day with auditable history.

Example prompt: Open an Edit for package com.example.app, upload version-code 1042 AAB, set rollout 0.1 on production, and commit the Edit.

### Subscription and purchase validation

Backend services validate subscription and one-time purchase tokens received from the mobile client to grant entitlements. The purchases endpoints return the purchase state, expiry, and renewal info so the backend can lock or unlock features based on real Play data rather than client claims.

Example prompt: Call purchases.subscriptions.get for token TOK_ABC on subscription premium_monthly and grant the user a 30-day entitlement if expiryTime is in the future.

### Localized store listing updates

Marketing teams update titles, descriptions, screenshots, and feature graphics across many locales by opening an Edit and patching each listing. Committing the Edit publishes all locales atomically so the store does not show a half-updated state.

Example prompt: Open an Edit for com.example.app, patch the de-DE listing with a new shortDescription, and commit.

### AI agent release operator via Jentic

An AI agent acting as a release manager opens Edits, uploads builds passed by CI, runs the Play pre-launch checks, and rolls out gradually. Through Jentic the agent searches for 'commit a play edit' and executes the operation without holding the underlying service account.

Example prompt: After CI publishes build 1042, open an Edit, upload the AAB, set rollout 0.05 on production, and commit. Post the new edit ID and rollout link to Slack.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /androidpublisher/v3/applications/internalappsharing/{packageName}/artifacts/apk | Upload an APK for internal app sharing |
| POST | /androidpublisher/v3/applications/internalappsharing/{packageName}/artifacts/bundle | Upload an AAB for internal app sharing |
| GET | /androidpublisher/v3/applications/{packageName}/appRecoveries | List app recovery actions |
| POST | /androidpublisher/v3/applications/{packageName}/appRecoveries/{appRecoveryId}:deploy | Deploy an app recovery action |
| POST | /androidpublisher/v3/applications/{packageName}/dataSafety | Submit data safety declarations |
| GET | /androidpublisher/v3/applications/{packageName}/deviceTierConfigs | List device tier configurations |

## Key resources

- **Edits** — Open, modify, and commit a transactional Play release change
- **Tracks** — Manage internal, alpha, beta, and production release tracks
- **Bundles and APKs** — Upload AABs and APKs into an Edit
- **Listings** — Update title, description, and graphics per locale
- **InAppProducts** — Define and manage in-app products
- **Subscriptions** — Manage subscription products and offers
- **Purchases** — Validate and acknowledge purchases and subscriptions

## Why Jentic

- **Setup:** Wiring the Google Play Android Developer API by hand means setting up Google OAuth2, granting a service identity the right Play Console scopes, and refreshing access tokens across its 112 publishing operations yourself. Through Jentic you install once, import the Google Play Android Developer API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** This API puts the app package name in the URL path (/androidpublisher/v3/applications/{packageName}/...), so a rule can pin your agent to one app: it can read app recoveries and post data-safety details for that package and nothing else. You choose the operations it may call, so actions like deploying an app recovery are not included unless you add them.
- **Credential handling:** Your Google Play OAuth credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'commit a play edit' or 'verify a subscription token', and Jentic returns the matching publisher operation with its input schema so the agent calls the right endpoint without navigating the 112-endpoint reference.

## Related APIs

- **Google Play EMM API** — Distributes Play-published apps to managed Android devices via EMM.
- **Android Management API** — Pushes Play-published apps to enrolled devices through Android Management policies.
- **App Engine Admin API** — Hosts the backend services that validate Play purchases server-side.

## FAQ

### What authentication does the Google Play Android Developer API use?

OAuth 2.0 with a service account that has been linked to the Play Console developer account and granted the required permissions. Through Jentic the service account JSON is vaulted and only short-lived scoped tokens are used at call time.

### Can I publish a new app version with this API?

Yes, but always through an Edit. Open an Edit with edits.insert, upload the AAB or APK with edits.bundles or edits.apks, set the desired track and rollout, then commit with edits.commit. Uncommitted Edits do not affect the live store listing.

### What are the rate limits for the Google Play Android Developer API?

The API enforces a per-package daily quota and per-minute quota documented in the Play Console. Edit operations are cheap; bundle and APK uploads count more. Spread large bulk-listing updates across multiple Edits if you risk hitting the daily cap.

### How do I validate a subscription purchase through Jentic?

Search Jentic for 'verify google play subscription', load the schema for purchases.subscriptions.get, and execute it with the packageName, subscriptionId, and purchase token. Grant entitlement only when paymentState and expiryTimeMillis confirm an active subscription.

### Is the Google Play Android Developer API free?

The API is free for registered Play Console developer accounts. Costs are tied to the Play Developer account itself (one-time registration fee), not to API call volume.

### Why do my changes not appear in the store after a successful API call?

Because the change is in an open Edit. Until you call edits.commit, modifications are staged. Confirm by listing the Edit and verifying the changes, then call commit. Failed commits typically mean policy or asset validation errors, which the response describes.

### Can I limit what my agent is allowed to do with the Google Play Android Developer API?

Yes. Because you run Jentic One yourself, your own rules decide which of the 112 publishing operations your agent may call and which OAuth credential it uses. Since this API carries the app package name in the URL path, you can pin the agent to a single app so it only touches operations like listing app recoveries or submitting data-safety details for that package. Sensitive actions such as committing an Edit or deploying an app recovery are excluded unless you explicitly add them to the agent's allowed operations.