Memperbarui listing Play Store dengan Google Play Developer API

Google Play Developer API (nama resminya Android Publisher API) memungkinkan kamu mengubah listing toko — judul, deskripsi, tangkapan layar, feature graphic — tanpa membuka Play Console. Ini yang kamu butuhkan kalau kamu mendorong teks terlokalisasi dari CMS, menyinkronkan tangkapan layar dari build pipeline, atau memperbarui puluhan listing bahasa sekaligus. Berikut alur lengkapnya agar dilakukan dengan benar, termasuk bagian yang jarang dijelaskan dokumentasi resmi.

Edit adalah transaksi, bukan sekumpulan penulisan langsung

Model mental yang paling menyelamatkan kamu: kamu tidak pernah mengedit listing yang tayang secara langsung. Kamu membuka edit, yaitu salinan staging privat dari status deployment aplikasi saat ini — listing, gambar, track, semuanya disalin ke sana. Semua perubahan kamu buat terhadap salinan itu. Lalu kamu commit semuanya sekaligus, atau membatalkannya dan seolah tidak pernah terjadi apa-apa.

Kalimat Google sendiri sangat jelas: "Changes made within an edit are not live until the edit is committed." Saat commit, jika tidak ada error validasi, semua perubahan dalam edit tayang bersamaan, menggantikan status saat ini. Jika validasi gagal, API akan melempar error dan listing yang tayang tidak berubah. Jadi siklusnya persis empat langkah:

• edits.insert — membuat edit, mendapatkan editId.
• ubah — edits.listings.update untuk teks per bahasa, edits.images.upload / deleteall untuk tangkapan layar dan grafik.
• edits.commit — validasi semuanya, lalu publikasikan semua sekaligus secara atomik.
• edits.abandon — buang draft, listing yang tayang tidak berubah.

Satu batasan penting yang perlu dirancang di sekitarnya: satu akun hanya boleh punya satu edit terbuka pada satu waktu, dan jika seseorang meng-commit edit atau mengedit aplikasi lewat UI Play Console, semua edit lain yang terbuka untuk aplikasi itu jadi tidak valid. Perlakukan edit sebagai sesuatu yang berumur pendek — buka, tulis, commit. Jangan biarkan terbuka berjam-jam sementara ada orang yang mengklik-klik di console.

Autentikasi: service account, plus undangan yang sering dilupakan orang

Untuk pembaruan otomatis kamu butuh service account, bukan OAuth pengguna. Ada dua sistem yang terlibat, dan keduanya benar-benar terpisah:

1. Google Cloud. Buat service account, aktifkan Google Play Android Developer API pada proyek, dan unduh JSON key. Scope yang kamu butuhkan hanya https://www.googleapis.com/auth/androidpublisher.
2. Play Console. Buka Users & permissions, klik Invite new users, tempel email service account (alamat ...@...iam.gserviceaccount.com), dan beri akses ke aplikasi. Baru setelah itu key tersebut bisa menyentuh listing kamu.

Satu syarat lagi: aplikasi harus sudah ada dan sudah punya setidaknya satu rilis (setidaknya satu APK/AAB yang diunggah lewat console). Kamu tidak bisa membangun aplikasi baru sepenuhnya lewat API.

Empat panggilan, dalam bentuk REST

Memperbarui teks listing

edits.listings.update adalah PUT — penggantian penuh untuk listing bahasa tersebut. Apa pun yang kamu kirim menjadi listing itu; field yang kamu lewati akan dikosongkan, bukan dipertahankan. Jadi kalau kamu hanya ingin mengubah deskripsi singkat, kamu tetap harus mengirim judul dan deskripsi lengkap bersamanya, kalau tidak keduanya akan terhapus. Kalau kamu benar-benar ingin perubahan sebagian, ada edits.listings.patch terpisah yang hanya menggabungkan field yang kamu berikan. Untuk kebanyakan pipeline, PUT penuh lebih bersih — kamu memang me-render seluruh listing dari sumber kebenaran kamu, jadi mengganti semuanya sekaligus itu tepat.

Tiga field teks dan batasnya: title maksimal 30 karakter, shortDescription maksimal 80, fullDescription maksimal 4000. Satu resource listing per bahasa, ditandai dengan tag bahasa BCP-47 di URL (en-US, de-DE, ja-JP, dan seterusnya). Untuk memperbarui sepuluh bahasa, kamu membuat sepuluh panggilan listings.update di dalam edit yang sama — lalu satu commit mempublikasikan semuanya bersamaan.

Mengunggah tangkapan layar dan feature graphic

Gambar dilampirkan per bahasa dan per jenis gambar. Jenis gambar adalah enum, dan setiap slot aset di listing dipetakan ke salah satu nilai ini:

• phoneScreenshots, sevenInchScreenshots, tenInchScreenshots — set tangkapan layar ponsel dan tablet.
• tvScreenshots, wearScreenshots — Android TV dan Wear OS.
• featureGraphic — banner 1024×500 yang ditampilkan di atas listing.
• icon, tvBanner — ikon aplikasi dan banner TV.

edits.images.upload menambahkan satu gambar dari bahasa dan jenis tertentu ke dalam edit. Tidak ada panggilan "set seluruh array", jadi pola yang bisa diandalkan untuk mengganti tangkapan layar adalah edits.images.deleteall untuk bahasa dan jenis gambar itu terlebih dahulu, lalu unggah set baru sesuai urutan yang kamu inginkan. edits.images.list membaca apa yang saat ini ada di dalam edit, dan edits.images.delete menghapus satu gambar berdasarkan id kalau kamu butuh perubahan yang presisi. Semuanya tetap di dalam edit sampai kamu commit.

Melakukan commit — dan arti sebenarnya dari "tayang"

Beberapa hal yang perlu diperjelas, karena sering mengejutkan orang:

• Tidak perlu build baru. Meng-commit edit yang hanya berisi listing tidak memerlukan APK/AAB baru. Teks dan gambar itu metadata; kamu bisa memperbaruinya berkali-kali terhadap rilis yang sudah ada. (Aplikasi hanya perlu punya satu rilis sebelumnya.)
• Commit memvalidasi, lalu mempublikasikan. Kalau tangkapan layar salah dimensi atau field terlalu panjang, commit akan gagal dan listing yang tayang tidak pernah berubah — kamu perbaiki lalu commit ulang.
• Prosesnya tidak instan. Setelah commit berhasil, perubahan bisa butuh hingga beberapa jam untuk muncul, sama seperti edit yang dilakukan manual di Play Console. Jangan anggap respons 200 pada commit berarti "sudah terlihat oleh pengguna".
• Abandon itu gratis. Kalau dry run terlihat salah, edits.abandon membuang draft tanpa efek apa pun pada listing yang tayang. Berguna untuk memvalidasi pipeline tanpa risiko.

Jalur tanpa kode: desain, terjemahkan, publikasikan

API di atas adalah alat yang tepat kalau kamu punya waktu engineering dan sumber kebenaran untuk disinkronkan. Yang tidak dilakukannya adalah membuat aset. Kamu tetap harus mendesain tangkapan layar, menulis judul dan kedua deskripsi, dan menghasilkan semua itu per bahasa — API hanya mengirimkan apa yang kamu berikan.

Itulah bagian yang ditangani Mokbi. Kamu mendesain tangkapan layar di browser, menyusun judul, deskripsi singkat dan deskripsi lengkap bersamanya, lalu menerjemahkan seluruh listing ke 50 bahasa dalam satu langkah — sehingga sepuluh panggilan listings.update di atas punya teks nyata dan terlokalisasi untuk dikirim, bukan teks placeholder.

Lalu publikasinya sendiri? Mokbi juga menanganinya. Untuk Google Play, alat ini menjalankan tepat alur ini di baliknya (edits.insert → listings.update → upload gambar → commit), jadi listing dan aset terlokalisasi kamu tayang tanpa kamu menulis satu baris pun kode di atas. Untuk App Store, alat ini menyiapkan versi di App Store Connect, terisi dan siap dikirimkan, karena Apple mengharuskan kamu menekan tombol Submit terakhir dan lolos review. Mendesain tangkapan layar dan feature graphic, menulis listing, menerjemahkannya ke 50 bahasa, dan mempublikasikannya adalah satu proses yang berkesinambungan.

Bacaan selanjutnya

• Memperbarui listing Play tanpa merilis build baru
• Persyaratan listing Play dan checklist aset
• Padanan App Store Connect API untuk iOS

Buka editor →