Google Play Developer API: Set Up a Service Account

A CI job that uploads the app bundle, a script that moves a build from internal testing to production, a support tool that answers reviews: all of them talk to the Google Play Developer API, and almost all of them do it as a service account. This guide covers setting one up as of 24 September 2026, granting it as little access as the job needs, and keeping its key out of the places keys tend to leak.

If you also ship on iOS, see how to create an App Store Connect API key.

The short version

• Create a Google Cloud project, enable the Google Play Developer API, and create a service account in it.
• Invite the service account's email address in Play Console under Users and permissions, with the permissions its job needs and no more.
• You no longer have to link your developer account to a Cloud project.
• A downloaded JSON key can't be downloaded again. Keep it out of your repository and your app, rotate it, and delete it when it is no longer needed.
• Google's Cloud guidance prefers keyless options, such as Workload Identity Federation, wherever your CI supports them.

What the API is for

Three parts of the API cover most of what teams automate.

• Edits. Google's Edits guide describes an edit as a container for changes: uploads, track assignments and store listing text. Nothing goes live until you commit the edit, and committed changes can take several hours to take effect. If anyone changes the app in Play Console while your edit is open, the edit is discarded.
• Tracks. The APKs and Tracks guide names the built-in tracks production, beta (open testing) and qa (internal testing). A release on production can be a staged rollout with a userFraction, which you raise, halt or complete through the same call.
• Reviews. The Reply to Reviews API lists recent reviews and posts replies, for example from a support tool.

The API can't create an app from scratch. The Edits guide says the app needs at least one upload through Play Console before the API can change it, and that switching an app between published and unpublished, and the legal consents needed to publish, stay in Play Console. Our guides to publishing on Google Play and testing tracks cover that side.

Step 1: create a Cloud project and enable the API

Google's Getting Started page lists the steps, as of 24 September 2026. Create a project in the Google Cloud console, or reuse one you already have. Then open the Google Play Developer API page in the console for that project and click Enable.

Some older guides tell you to link that project to your developer account in Play Console. You can skip that. The same page says, in a note at the top, that you no longer need to link your developer account to a Google Cloud project to use the API.

Step 2: create the service account and a key

Google recommends a service account for most uses, run from a secure environment such as your server. An OAuth client is the alternative when a person should act under their own Google account.

1. In the Google Cloud console, open Service accounts and click Create service account. Name it after its job, such as play-ci-upload.
2. Open the new account, go to the Keys tab, choose Add key, then Create new key, select JSON and click Create.

Google Cloud's page on creating and deleting service account keys says the file downloads once and can't be downloaded again, and that a service account can have up to 10 keys. If the console refuses to create a key, your Cloud organisation may block key creation. Google's key management guide notes that organisations created on or after 3 May 2024 have that block on by default.

Step 3: invite it in Play Console

Play Console doesn't know about the service account until you invite it. You need the Admin (all permissions) permission at account level to do this. As of 24 September 2026, Google's help page on developer account users and permissions describes these steps:

1. Go to Users and permissions and choose to invite a new user.
2. Paste the service account's email address. It ends in iam.gserviceaccount.com and is also inside the JSON key.
3. Optionally set an access expiry date. Without one, access lasts until you remove it.
4. Choose App permissions for specific apps, or Account permissions for every app in the account.
5. Tick the permissions the job needs, then click Invite user.

Granting as little as the job needs

Pick per job, and prefer app permissions over account permissions so a leaked key reaches one app rather than all of them.

A pipeline that pushes builds to testers but leaves production to a person needs the top row and nothing else. Give production rights to a separate service account with its own key, so each can be revoked without breaking the other.

Keeping the key safe

Google Cloud's best practices for managing service account keys treat a key like a password that skips two-step verification. As of 24 September 2026, the guidance includes:

• Prefer not to have a key at all. Google says keys become a security risk if they aren't managed carefully, and recommends a more secure alternative wherever possible.
• Keep it separate from source code. Never commit it, even to a private repository that may go public later. If you use GitHub, Google suggests turning on secret scanning.
• Don't leave it in Downloads. Move it straight to where it will live and check the recycle bin.
• Don't embed it in a binary. That rules out ever shipping it inside an app.
• Rotate it routinely, and disable keys you no longer need, then delete them once you are sure.
• If it was ever committed, delete the key in Cloud quickly. Removing it from the repository isn't enough, because history keeps a copy.

Google's guidance doesn't name a CI product. In practice, keeping the key separate from source code means your CI provider's encrypted secrets, written to a temporary file or environment variable for the length of the job.

Keyless options

Google Cloud's authentication overview recommends Workload Identity Federation for workloads that run on-premises or with another cloud provider, when their identity provider supports it. It gives them access without a service account key to create and look after. A hosted CI runner is that kind of workload, so whether you can use it depends on your CI and your tooling. fastlane's setup guide, for one, documents it alongside JSON keys, with GitHub Actions as its example.

Revoking access

Deleting the key in the Cloud console stops that key working for good. Removing the service account in Play Console Users and permissions, or letting its access expiry date pass, takes away what it can do in Play Console, whatever credential it uses.

Quotas

Google's quotas page groups the API into buckets with a default of 3,000 queries per minute each, as of 24 September 2026. Publishing, monetisation and Reply to Reviews calls share one bucket. The Reply to Reviews API adds its own limits per app: 200 GET requests an hour and 2,000 replies a day.

fastlane and Gradle Play Publisher

Two open-source tools wrap the API, and both use the same service account.

• fastlane supply. fastlane's Android setup guide walks through the same Cloud and Play Console steps, supports both Workload Identity Federation and JSON keys, and needs one upload in Play Console before it can initialise.
• Gradle Play Publisher. The project's README describes it as an unofficial Gradle plugin. It reads the JSON key from a file, from an ANDROID_PUBLISHER_CREDENTIALS environment variable, or from Application Default Credentials, and it also needs your initial upload done in Play Console.

Their setup guides are generous with access. fastlane's suggests Admin (all permissions) in Play Console, with the option of leaving out some release permissions, and Gradle Play Publisher's gives the service account a temporary Project Owner role in Cloud that it then tells you to remove. Compare either with the table above and trim what you grant once your pipeline works. Flutter and React Native apps produce the same Android app bundle as a native project, so all of this applies to them unchanged.

How FeedbackKit fits in

FeedbackKit never needs your Play service account or its key, and no SDK should. A service account key can release builds or reply to reviews in your name, so it lives on a server or in CI and nowhere else. The project API key you pass to the FeedbackKit SDK is the opposite: it is designed to ship inside your app, where anyone can read it from the APK. It tells FeedbackKit which project's board to show and where new requests, votes and comments go. Treat it as an identifier for your project rather than a secret. FeedbackKit's REST API, described in the OpenAPI reference, uses FeedbackKit's own keys and has nothing to do with Google's.

The FeedbackKit SDKs show the same request list on Android and every other platform you build for. Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

Setup is in the Kotlin docs, with Flutter and React Native alongside, and our Android feedback board guide walks through the Compose screens.

When your pipeline ships builds without anyone clicking, and you want to hear what users ask for next, start free.