Di Content API for Shopping, Anda mengelola pengguna dan hak akses mereka dengan kolom di resource Account. Merchant API mengganti ini dengan resource khusus bernama User dan metode yang sesuai (create, delete, get, list, path). Untuk mengetahui informasi selengkapnya, lihat Mengontrol akses ke akun Anda.
Perbedaan utama
Dibandingkan dengan Content API for Shopping, Merchant API menawarkan keuntungan berikut untuk pengelolaan pengguna:
- Resource khusus: Fitur ini memberikan cara yang lebih terperinci dan langsung untuk mengontrol siapa yang dapat mengakses akun Merchant Center Anda dan apa yang dapat mereka lakukan.
- Nama resource RESTful: Di Merchant API, identifikasi resource Userdengan nama resource lengkap, misalnya,accounts/12345/users/example@example.com.
- Alias me: Anda dapat menggunakan aliasmesebagai pengganti alamat email di nama resource untuk merujuk ke pengguna yang diautentikasi, misalnya,accounts/12345/users/me.
- Hak akses gabungan: Merchant API menggabungkan kolom akses boolean dari Content API (misalnya, admin,reportingManager) ke dalam satu kolomaccess_rightsyang dapat diulang.
- Undangan dan verifikasi pengguna: Merchant API memperkenalkan status pengguna eksplisit (PENDINGatauVERIFIED). Saat Anda membuat pengguna baru, pengguna tersebut akan berada dalam statusPENDINGhingga menerima undangan. Hal ini memberikan visibilitas API ke status pengguna, yang tidak tersedia di Content API for Shopping. Menambahkan ## Permintaan
Merchant API menggunakan URL permintaan berikut untuk mengelola pengguna:
- GET /accounts/v1/accounts/{account}/users/{email}
- GET /accounts/v1/accounts/{account}/users
- POST /accounts/v1/accounts/{account}/users
- PATCH /accounts/v1/accounts/{account}/users/{email}
- DELETE /accounts/v1/accounts/{account}/users/{email}
Tabel berikut membandingkan URL permintaan antara Content API for Shopping dan Merchant API.
| Deskripsi permintaan | Content API for Shopping | Merchant API | 
|---|---|---|
| Mendapatkan pengguna untuk akun | GET {api_version}/{merchantId}/accounts/{accountId} | GET {api_version}/accounts/{account}/users | 
| Membuat pengguna | PATCH {api_version}/{merchantId}/accounts/{accountId} | POST {api_version}/accounts/{account}/users | 
| Memperbarui pengguna | PATCH {api_version}/{merchantId}/accounts/{accountId} | PATCH {api_version}/accounts/{account}/users/{email} | 
| Hapus pengguna | PATCH {api_version}/{merchantId}/accounts/{accountId} | DELETE {api_version}/accounts/{account}/users/{email} | 
Pengenal
Tabel berikut membandingkan ID yang digunakan dalam permintaan antara Content API for Shopping dan Merchant API.
| Deskripsi ID | Content API for Shopping | Merchant API | 
|---|---|---|
| ID akun | accountId | accountdiaccounts/{account} | 
| ID pengguna | email_addressdalam objekAccountUser | emaildiaccounts/{account}/users/{email} | 
Metode
Tabel berikut membandingkan metode antara Content API for Shopping dan Merchant API.
| Content API for Shopping | Merchant API | Ketersediaan & catatan | 
|---|---|---|
| accounts.update | users.create | Membuat pengguna baru untuk akun. | 
| accounts.get | users.get | Mengambil satu pengguna. | 
| accounts.get | users.list | Mencantumkan semua pengguna untuk akun. | 
| accounts.update | users.update | Memperbarui hak akses pengguna. | 
| accounts.update | users.delete | Menghapus pengguna dari akun. | 
Perubahan kolom mendetail
Perbarui penggunaan kolom Anda sebagai berikut:
| Content API for Shopping | Merchant API | Deskripsi | 
|---|---|---|
| users(berulangAccountUser) | users(berulangUser) | Resource Usersekarang menjadi resource tingkat teratas dengan layanannya sendiri. | 
| AccountUser.email_address | CreateUserRequest.user_iddan bagian dariUser.name | Alamat email pengguna kini menjadi bagian dari nama resource. Tentukan di kolom user_idselama pembuatan. | 
| AccountUser.admin | access_rights: "ADMIN" | Merchant API menggantikan kolom boolean admindengan nilaiADMINdalam enumaccess_rights. | 
| AccountUser.order_manager,AccountUser.payments_manager,AccountUser.payments_analyst | access_rights: "STANDARD" | Merchant API menggantikan peran ini dengan hak akses STANDARD. | 
| AccountUser.reporting_manager | access_rights: "PERFORMANCE_REPORTING" | Peran reporting_managerkini menjadi hak aksesPERFORMANCE_REPORTING. | 
| AccountUser.read_only | access_rights: "READ_ONLY" | Peran read_onlykini menjadi hak aksesREAD_ONLY. | 
| Tidak tersedia | User.name | Berisi nama resource lengkap pengguna, misalnya, accounts/{account}/users/{email}. | 
| Tidak tersedia | User.state | Menunjukkan status undangan pengguna, baik PENDINGmaupunVERIFIED. |