Actualizar tu ficha de Play Store con la Google Play Developer API
edits.insert), cambias el texto y las imágenes de la ficha dentro de ella (edits.listings.update, edits.images.upload) y luego haces edits.commit para validar y publicar — o edits.abandon para descartarla. Nada se publica hasta el commit. La autenticación es una cuenta de servicio de Google Cloud, y el paso que casi todos olvidan: la cuenta de servicio debe invitarse desde Play Console, no basta con darle un rol en Google Cloud IAM.La Google Play Developer API (su nombre formal es Android Publisher API) te permite cambiar una ficha de la tienda — título, descripciones, capturas de pantalla, gráfico destacado — sin abrir Play Console. Eso es justo lo que necesitas si estás enviando texto localizado desde un CMS, sincronizando capturas de pantalla desde un pipeline de compilación o actualizando decenas de fichas en distintos idiomas a la vez. Este es el flujo completo para hacerlo bien, incluidas las partes que la documentación de referencia esconde.
Una edición es una transacción, no un conjunto de escrituras en vivo
El modelo mental que te ahorra más de un dolor de cabeza: nunca editas la ficha en vivo directamente. Abres una edición, que es una copia privada de trabajo del estado actual publicado de la app — fichas, imágenes, canales, todo se copia. Haces todos tus cambios sobre esa copia. Luego confirmas todo de golpe, o la abandonas y no ha pasado nada.
Las palabras de Google son directas: «los cambios hechos dentro de una edición no se publican hasta que se confirma la edición». Al hacer commit, si no hay errores de validación, todos los cambios de la edición se publican juntos, reemplazando el estado actual. Si la validación falla, la API lanza un error y la ficha en vivo queda intacta. Así que el ciclo de vida son exactamente cuatro movimientos:
edits.insert— crea la edición y devuelve uneditId.- modificar —
edits.listings.updatepara el texto por idioma,edits.images.upload/deleteallpara capturas de pantalla y gráficos. edits.commit— valida todo y luego publica todo de forma atómica.edits.abandon— descarta el borrador; la ficha en vivo queda sin cambios.
Una restricción importante a tener en cuenta al diseñar tu flujo: una cuenta solo puede tener una edición abierta a la vez, y si alguien confirma una edición o edita la app desde la interfaz de Play Console, cualquier otra edición abierta de esa app queda invalidada. Trata una edición como algo de corta duración — ábrela, escríbela, confírmala. No la dejes abierta durante horas mientras alguien navega por la consola.
Autenticación: una cuenta de servicio, más la invitación que todos olvidan
Para un actualizador automatizado quieres una cuenta de servicio, no OAuth de usuario. Hay dos sistemas involucrados, y son realmente independientes:
- Google Cloud. Crea una cuenta de servicio, activa la Google Play Android Developer API en el proyecto y descarga una clave JSON. El único ámbito que necesitas es
https://www.googleapis.com/auth/androidpublisher. - Play Console. Ve a Usuarios y permisos, haz clic en Invitar nuevos usuarios, pega el correo de la cuenta de servicio (la dirección
...@...iam.gserviceaccount.com) y concédele acceso a la app. Solo entonces esa clave podrá tocar tu ficha.
Una condición previa más: la app ya debe existir y haber tenido al menos una versión publicada (al menos un APK/AAB subido desde la consola). No puedes crear una app completamente nueva solo con la API.
Las cuatro llamadas, en REST
Actualizar el texto de la ficha
edits.listings.update es un PUT — un reemplazo completo de la ficha de ese idioma. Lo que envíes se convierte en la ficha; los campos que omitas se borran, no se conservan. Así que si solo quieres cambiar la descripción corta, igual tienes que enviar el título y la descripción completa junto con ella, o los borrarás. Cuando de verdad quieras un cambio parcial, existe un edits.listings.patch aparte que solo combina los campos que proporciones. Para la mayoría de los pipelines el PUT completo es más limpio — de todos modos estás generando la ficha completa desde tu fuente de verdad, así que reemplazarla entera es lo correcto.
Los tres campos de texto y sus límites: title hasta 30 caracteres, shortDescription hasta 80, fullDescription hasta 4000. Un recurso de ficha por idioma, identificado por la etiqueta de idioma BCP-47 en la URL (en-US, de-DE, ja-JP, etcétera). Para actualizar diez idiomas haces diez llamadas listings.update dentro de la misma edición — y luego un solo commit las publica todas juntas.
Subir capturas de pantalla y el gráfico destacado
Las imágenes se adjuntan por idioma y por tipo de imagen. El tipo de imagen es un enum, y cada espacio de recurso en la ficha corresponde a uno de estos valores:
phoneScreenshots,sevenInchScreenshots,tenInchScreenshots— los conjuntos de capturas de pantalla de teléfono y tablet.tvScreenshots,wearScreenshots— Android TV y Wear OS.featureGraphic— el banner de 1024×500 que se muestra en la parte superior de la ficha.icon,tvBanner— el icono de la app y el banner de TV.
edits.images.upload añade una imagen de un idioma y tipo determinados a la edición. No existe una llamada para «reemplazar todo el conjunto», así que el patrón fiable para sustituir capturas de pantalla es hacer primero edits.images.deleteall para ese idioma y tipo de imagen, y luego subir el nuevo conjunto en el orden en que quieres que se muestren. edits.images.list lee lo que hay actualmente en la edición, y edits.images.delete elimina una sola imagen por id si necesitas cambios quirúrgicos. Todo permanece dentro de la edición hasta que haces el commit.
Confirmar — y qué significa realmente «en vivo»
Algunas cosas que conviene tener claras, porque sorprenden a la gente:
- No hace falta una nueva versión. Confirmar una edición que solo toca la ficha no necesita un APK/AAB nuevo. El texto y las imágenes son metadatos; puedes actualizarlos cuantas veces quieras sobre la versión existente. (La app solo necesita tener esa versión previa.)
- El commit valida y luego publica. Si una captura de pantalla tiene una dimensión incorrecta o un campo es demasiado largo, el commit falla y la ficha en vivo nunca cambia — corriges y vuelves a confirmar.
- No es instantáneo. Tras un commit exitoso, los cambios pueden tardar hasta varias horas en aparecer, igual que las ediciones hechas a mano en Play Console. No trates un 200 en el commit como «ya visible para los usuarios».
- Abandonar es gratis. Si una prueba en seco no sale bien,
edits.abandondescarta el borrador sin ningún efecto en la ficha en vivo. Útil para validar un pipeline sin riesgo.
El camino sin código: diseñar, traducir, publicar
La API descrita arriba es la herramienta adecuada si tienes tiempo de ingeniería que dedicar y una fuente de verdad desde la que sincronizar. Lo que no hace es crear los recursos. Igualmente tienes que diseñar las capturas de pantalla, escribir el título y ambas descripciones, y producir todo eso por idioma — la API solo publica lo que le entregas.
Esa es la parte que Mokbi se encarga de resolver. Diseñas las capturas de pantalla en el navegador, redactas el título, la descripción corta y la descripción completa junto a ellas, y traduces toda la ficha a 50 idiomas en una sola pasada — así las diez llamadas listings.update de arriba tienen texto real y localizado que enviar, en lugar de un texto de relleno.
¿Y la publicación en sí? Mokbi también se encarga de eso. Para Google Play ejecuta exactamente este flujo por debajo (edits.insert → listings.update → subida de imágenes → commit), así que tu ficha localizada y sus recursos se publican sin que escribas una sola línea del código de arriba. Para la App Store prepara la versión en App Store Connect, lista para enviar, ya que Apple exige que tú mismo pulses el botón final de Submit y pases la revisión. Diseñar las capturas de pantalla y el gráfico destacado, redactar la ficha, traducirla a 50 idiomas y publicarla son una sola pasada continua.