Play Store-Eintrag mit der Google Play Developer API aktualisieren
edits.insert), änderst darin den Text und die Bilder des Eintrags (edits.listings.update, edits.images.upload) und rufst dann edits.commit auf, um zu validieren und zu veröffentlichen — oder edits.abandon, um zu verwerfen. Nichts geht live, bevor der Commit erfolgt ist. Die Auth läuft über einen Google-Cloud-Service-Account, und der Schritt, der fast alle stolpern lässt: Der Service-Account muss in der Play Console eingeladen werden, nicht nur eine Rolle in Google Cloud IAM erhalten.Mit der Google Play Developer API (offiziell Android Publisher API) kannst du einen Store-Eintrag ändern — Titel, Beschreibungen, Screenshots, Feature-Grafik — ohne die Play Console zu öffnen. Das ist genau das, was du willst, wenn du lokalisierte Texte aus einem CMS pushst, Screenshots aus einer Build-Pipeline synchronisierst oder Dutzende Sprach-Einträge gleichzeitig aktualisierst. Hier ist der komplette Ablauf, um das korrekt zu tun — inklusive der Teile, die in der Referenzdokumentation untergehen.
Ein Edit ist eine Transaktion, keine Reihe von Live-Schreibvorgängen
Das mentale Modell, das dir am meisten Ärger erspart: Du bearbeitest nie direkt den Live-Eintrag. Du öffnest einen Edit — eine private Staging-Kopie des aktuell veröffentlichten App-Zustands: Einträge, Bilder, Tracks, alles wird hineinkopiert. Alle Änderungen machst du an dieser Kopie. Dann committest du alles auf einmal, oder du verwirfst es, und nichts ist je passiert.
Googles eigene Formulierung ist unmissverständlich: „Änderungen innerhalb eines Edits sind erst live, wenn der Edit committed wurde." Beim Commit gehen — wenn keine Validierungsfehler auftreten — alle Änderungen im Edit gemeinsam live und ersetzen den aktuellen Zustand. Schlägt die Validierung fehl, wirft die API einen Fehler, und der Live-Eintrag bleibt unangetastet. Der Lebenszyklus besteht also aus genau vier Schritten:
edits.insert— Edit erstellen, du bekommst eineeditIdzurück.- ändern —
edits.listings.updatefür Text pro Sprache,edits.images.upload/deleteallfür Screenshots und Grafiken. edits.commit— alles validieren, dann atomar alles veröffentlichen.edits.abandon— Entwurf verwerfen, Live-Eintrag bleibt unverändert.
Ein harter Rahmen, um den du planen musst: Ein Account darf nur einen Edit gleichzeitig offen haben, und sobald jemand einen Edit committet oder die App über die Play-Console-Oberfläche bearbeitet, werden alle anderen offenen Edits für diese App ungültig. Behandle einen Edit als kurzlebig — öffnen, schreiben, committen. Halte ihn nicht stundenlang offen, während ein Mensch in der Console herumklickt.
Auth: ein Service-Account plus die Einladung, die alle vergessen
Für einen automatisierten Updater willst du einen Service-Account, keine User-OAuth. Zwei Systeme sind beteiligt, und sie sind wirklich getrennt:
- Google Cloud. Erstelle einen Service-Account, aktiviere die Google Play Android Developer API im Projekt und lade einen JSON-Schlüssel herunter. Der einzige benötigte Scope ist
https://www.googleapis.com/auth/androidpublisher. - Play Console. Gehe zu Nutzer & Berechtigungen, klicke auf Neue Nutzer einladen, füge die E-Mail-Adresse des Service-Accounts ein (die
...@...iam.gserviceaccount.com-Adresse) und gewähre ihm Zugriff auf die App. Erst dann kann dieser Schlüssel deinen Eintrag anfassen.
Eine weitere Voraussetzung: Die App muss bereits existieren und mindestens ein Release gehabt haben (mindestens eine über die Console hochgeladene APK/AAB). Eine brandneue App lässt sich nicht rein über die API bootstrappen.
Die vier Aufrufe als REST
Den Eintragstext aktualisieren
edits.listings.update ist ein PUT — ein vollständiger Ersatz des Eintrags dieser Sprache. Was du auch sendest, wird zum Eintrag; Felder, die du weglässt, werden gelöscht, nicht beibehalten. Willst du also nur die Kurzbeschreibung ändern, musst du trotzdem Titel und vollständige Beschreibung mitschicken, sonst löschst du sie. Wenn du wirklich nur eine Teiländerung willst, gibt es ein separates edits.listings.patch, das nur die von dir übergebenen Felder zusammenführt. Für die meisten Pipelines ist das vollständige PUT sauberer — du renderst den kompletten Eintrag ohnehin aus deiner Datenquelle, also ist ein vollständiger Ersatz genau richtig.
Die drei Textfelder und ihre Grenzen: title bis zu 30 Zeichen, shortDescription bis zu 80, fullDescription bis zu 4000. Eine Eintrags-Ressource pro Sprache, referenziert über den BCP-47-Sprach-Tag in der URL (en-US, de-DE, ja-JP und so weiter). Um zehn Sprachen zu aktualisieren, machst du zehn listings.update-Aufrufe innerhalb desselben Edits — dann veröffentlicht ein einziger Commit alle zusammen.
Screenshots und Feature-Grafik hochladen
Bilder werden pro Sprache und pro Bildtyp zugeordnet. Der Bildtyp ist ein Enum, und jeder Asset-Slot im Eintrag entspricht einem dieser Werte:
phoneScreenshots,sevenInchScreenshots,tenInchScreenshots— die Screenshot-Sets für Smartphone und Tablet.tvScreenshots,wearScreenshots— Android TV und Wear OS.featureGraphic— das 1024×500-Banner, das oben im Eintrag angezeigt wird.icon,tvBanner— das App-Icon und das TV-Banner.
edits.images.upload fügt dem Edit ein Bild einer bestimmten Sprache und eines bestimmten Typs hinzu. Es gibt keinen Aufruf, der „das ganze Array setzt", daher ist das verlässliche Muster zum Ersetzen von Screenshots: erst edits.images.deleteall für diese Sprache und diesen Bildtyp, dann die neue Reihe in der gewünschten Anzeigereihenfolge hochladen. edits.images.list liest, was aktuell im Edit steckt, und edits.images.delete entfernt bei Bedarf ein einzelnes Bild per ID — für chirurgische Änderungen. All das bleibt innerhalb des Edits, bis du committest.
Committen — und was „live" wirklich bedeutet
Ein paar Punkte, bei denen Präzision lohnt, weil sie überraschen:
- Kein neuer Build nötig. Das Committen eines reinen Text-/Bild-Edits erfordert keine neue APK/AAB. Text und Bilder sind Metadaten; du kannst sie beliebig oft am bestehenden Release aktualisieren. (Die App braucht nur dieses eine vorherige Release.)
- Commit validiert, dann veröffentlicht. Hat ein Screenshot die falsche Größe oder ist ein Feld zu lang, schlägt der Commit fehl, und der Live-Eintrag ändert sich nie — du korrigierst und committest erneut.
- Es ist nicht sofort. Nach einem erfolgreichen Commit können Änderungen bis zu mehrere Stunden brauchen, um zu erscheinen — genauso wie bei Änderungen, die man von Hand in der Play Console macht. Ein 200 beim Commit bedeutet nicht „für Nutzer bereits sichtbar".
- Verwerfen ist kostenlos. Sieht ein Testlauf falsch aus, verwirft
edits.abandonden Entwurf ohne jede Auswirkung auf den Live-Eintrag. Nützlich, um eine Pipeline risikofrei zu validieren.
Der No-Code-Weg: gestalten, übersetzen, veröffentlichen
Die API oben ist das richtige Werkzeug, wenn du Entwicklungszeit investieren willst und eine Datenquelle hast, aus der du synchronisierst. Was sie nicht macht: die Assets erstellen. Du musst die Screenshots trotzdem gestalten, Titel und beide Beschreibungen schreiben und das alles pro Sprache produzieren — die API verschickt nur, was du ihr gibst.
Genau diesen Teil übernimmt Mokbi. Du gestaltest die Screenshots im Browser, entwirfst Titel, Kurz- und vollständige Beschreibung direkt daneben und übersetzt den gesamten Eintrag in einem Durchgang in 50 Sprachen — sodass die zehn listings.update-Aufrufe von oben echten, lokalisierten Text statt Platzhaltern zu senden haben.
Und die Veröffentlichung selbst? Auch das erledigt Mokbi. Für Google Play läuft im Hintergrund genau dieser Ablauf (edits.insert → listings.update → Bilder-Upload → commit), sodass dein lokalisierter Eintrag samt Assets live geht, ohne dass du eine Zeile des obigen Codes schreibst. Für den App Store bereitet es die Version in App Store Connect vor — ausgefüllt und bereit zum Einreichen, da Apple verlangt, dass du selbst final auf Submit drückst und die Review durchläufst. Screenshots und Feature-Grafik gestalten, den Eintrag schreiben, ihn in 50 Sprachen übersetzen und live schalten sind ein durchgehender Arbeitsgang.