Play Store-listing bijwerken met de Google Play Developer API
edits.insert), wijzigt daarbinnen de listing-tekst en afbeeldingen (edits.listings.update, edits.images.upload), en doet dan edits.commit om te valideren en te publiceren — of edits.abandon om het weg te gooien. Er gaat niets live tot de commit. Auth loopt via een Google Cloud service account, en de stap waar bijna iedereen over struikelt: het service account moet worden uitgenodigd in de Play Console, niet alleen een rol krijgen in Google Cloud IAM.Met de Google Play Developer API (officieel de Android Publisher API) wijzig je een store-listing — titel, beschrijvingen, screenshots, feature graphic — zonder de Play Console te openen. Dat wil je als je gelokaliseerde teksten vanuit een CMS pusht, screenshots synchroniseert vanuit een build-pipeline, of tientallen taal-listings tegelijk bijwerkt. Dit is de complete flow om het goed te doen, inclusief de onderdelen die de referentie-docs verstoppen.
Een edit is een transactie, geen reeks live writes
Het mentale model dat je de meeste ellende bespaart: je bewerkt de live listing nooit rechtstreeks. Je opent een edit, een privé staging-kopie van de huidige gedeployde staat van de app — listings, afbeeldingen, tracks, alles wordt overgenomen. Je maakt al je wijzigingen tegen die kopie. Daarna commit je alles in één keer, of je verlaat de edit en er is niets gebeurd.
Google's eigen formulering is duidelijk: "Changes made within an edit are not live until the edit is committed." Bij commit gaat, als er geen validatiefouten zijn, elke wijziging in de edit tegelijk live, ter vervanging van de huidige staat. Als validatie mislukt, gooit de API een fout en blijft de live listing ongewijzigd. De levenscyclus bestaat dus uit precies vier stappen:
edits.insert— maak de edit aan, krijg eeneditIdterug.- wijzigen —
edits.listings.updatevoor tekst per taal,edits.images.upload/deleteallvoor screenshots en graphics. edits.commit— valideer alles, publiceer daarna alles atomisch.edits.abandon— gooi het concept weg, live listing blijft onveranderd.
Eén harde randvoorwaarde om rekening mee te houden: een account mag maar één open edit tegelijk hebben, en zodra iemand een edit commit of de app via de Play Console UI bewerkt, wordt elke andere open edit voor die app ongeldig. Behandel een edit als kortlevend — open hem, schrijf hem, commit hem. Houd er geen uren open terwijl iemand door de console klikt.
Auth: een service account, plus de uitnodiging die iedereen vergeet
Voor een geautomatiseerde updater wil je een service account, geen gebruikers-OAuth. Twee systemen zijn betrokken, en die staan echt los van elkaar:
- Google Cloud. Maak een service account aan, schakel de Google Play Android Developer API in voor het project, en download een JSON-sleutel. De enige scope die je nodig hebt is
https://www.googleapis.com/auth/androidpublisher. - Play Console. Ga naar Users & permissions, klik op Invite new users, plak het e-mailadres van het service account (het adres eindigend op
...@...iam.gserviceaccount.com), en geef het toegang tot de app. Pas dan kan die sleutel je listing aanraken.
Nog één voorwaarde: de app moet al bestaan en minstens één release hebben gehad (minstens één APK/AAB geüpload via de console). Je kunt een gloednieuwe app niet puur via de API opstarten.
De vier calls, als REST
De listing-tekst bijwerken
edits.listings.update is een PUT — een volledige vervanging van de listing voor die taal. Wat je ook verstuurt, wordt de listing; velden die je weglaat, worden gewist, niet bewaard. Wil je dus alleen de korte beschrijving wijzigen, dan stuur je toch ook de titel en volledige beschrijving mee, anders veeg je die weg. Wil je écht een gedeeltelijke wijziging, dan is er een aparte edits.listings.patch die alleen de velden samenvoegt die je meegeeft. Voor de meeste pipelines is de volledige PUT schoner — je rendert de complete listing toch al vanuit je bron van waarheid, dus die in zijn geheel vervangen is precies goed.
De drie tekstvelden en hun limieten: title tot 30 tekens, shortDescription tot 80, fullDescription tot 4000. Eén listing-resource per taal, geadresseerd via de BCP-47-taaltag in de URL (en-US, de-DE, ja-JP, enzovoort). Om tien talen bij te werken doe je tien listings.update-calls binnen dezelfde edit — daarna publiceert één commit ze allemaal tegelijk.
Screenshots en de feature graphic uploaden
Afbeeldingen worden gekoppeld per taal en per image type. Het image type is een enum, en elke asset-slot in de listing komt overeen met een van deze waarden:
phoneScreenshots,sevenInchScreenshots,tenInchScreenshots— de screenshot-sets voor telefoon en tablet.tvScreenshots,wearScreenshots— Android TV en Wear OS.featureGraphic— de 1024×500-banner bovenaan de listing.icon,tvBanner— het app-icoon en de TV-banner.
edits.images.upload voegt één afbeelding van een bepaalde taal en type toe aan de edit. Er is geen "stel de hele array in"-call, dus het betrouwbare patroon om screenshots te vervangen is eerst edits.images.deleteall voor die taal en dat image type, daarna de nieuwe set uploaden in de volgorde waarin je ze getoond wilt hebben. edits.images.list leest wat er nu in de edit staat, en edits.images.delete verwijdert één afbeelding op basis van id als je chirurgische wijzigingen nodig hebt. Het blijft allemaal binnen de edit tot je commit.
Committen — en wat "live" eigenlijk betekent
Een paar dingen om precies over te zijn, want ze verrassen mensen:
- Geen nieuwe build nodig. Het committen van een edit die alleen de listing raakt, vereist geen nieuwe APK/AAB. Tekst en afbeeldingen zijn metadata; je kunt ze zo vaak bijwerken als je wilt tegen de bestaande release. (De app hoeft alleen die ene eerdere release te hebben.)
- Commit valideert, dan publiceert. Als een screenshot de verkeerde afmeting heeft of een veld te lang is, mislukt de commit en verandert de live listing nooit — je fixt het en commit opnieuw.
- Het is niet direct zichtbaar. Na een geslaagde commit kunnen wijzigingen tot enkele uren duren voor ze verschijnen, net als bij handmatig gemaakte edits in de Play Console. Behandel een 200 op commit niet als "al zichtbaar voor gebruikers".
- Abandon is gratis. Als een dry run er niet goed uitziet, gooit
edits.abandonhet concept weg zonder enig effect op de live listing. Handig om een pipeline risicoloos te valideren.
De no-code route: ontwerpen, vertalen, publiceren
De API hierboven is het juiste gereedschap als je engineering-tijd hebt en een bron van waarheid om vanuit te synchroniseren. Wat het niet doet, is de assets maken. Je moet nog steeds de screenshots ontwerpen, de titel en beide beschrijvingen schrijven, en dat allemaal per taal produceren — de API verstuurt alleen wat je erin stopt.
Dat is het deel dat Mokbi voor je regelt. Je ontwerpt de screenshots in de browser, schrijft de titel, korte beschrijving en volledige beschrijving er meteen bij, en vertaalt de hele listing in één keer naar 50 talen — zodat de tien listings.update-calls hierboven echte, gelokaliseerde tekst te versturen krijgen in plaats van placeholder-tekst.
En de publicatie zelf? Ook dat doet Mokbi. Voor Google Play draait het onder de motorkap precies deze flow (edits.insert → listings.update → afbeeldingen uploaden → commit), zodat je gelokaliseerde listing en assets live gaan zonder dat je één regel van bovenstaande code schrijft. Voor de App Store zet het de versie klaar in App Store Connect, ingevuld en klaar om in te dienen, aangezien Apple vereist dat je zelf op Submit drukt en review doorloopt. Screenshots en feature graphic ontwerpen, de listing schrijven, vertalen naar 50 talen, en live zetten zijn één doorlopende stap.