Kullanıcı ve erişim yönetimini taşıma
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Content API for Shopping'de kullanıcıları ve erişim haklarını Account kaynağındaki bir alanla yönetiyordunuz. Merchant API, bu yöntemi User adlı özel kaynak ve ilgili yöntemlerle (oluşturma, silme, alma, listeleme, yol) değiştirir. Daha fazla bilgi için Hesabınıza erişimi kontrol etme başlıklı makaleyi inceleyin.
Temel farklılıklar
Merchant API, Content API for Shopping'e kıyasla kullanıcı yönetimi açısından aşağıdaki avantajları sunar:
- Özel kaynak: Bu, Merchant Center hesabınıza kimlerin erişebileceğini ve bu kullanıcıların neler yapabileceğini kontrol etmenin daha ayrıntılı ve doğrudan bir yolunu sunar.
- RESTful kaynak adları: Merchant API'de
User kaynaklarını tam kaynak adıyla (ör. accounts/12345/users/example@example.com) tanımlayın.
me takma adı: Kimliği doğrulanmış kullanıcıya başvurmak için kaynak adında e-posta adresi yerine me takma adını kullanabilirsiniz. Örneğin, accounts/12345/users/me.- Birleştirilmiş erişim hakları: Merchant API, Content API'deki boolean erişim alanlarını (örneğin,
admin, reportingManager) tek bir tekrarlanabilir access_rights alanında birleştirir.
- Kullanıcı daveti ve doğrulama: Merchant API, açık bir kullanıcı durumu (
PENDING veya VERIFIED) sunar. Yeni bir kullanıcı oluşturduğunuzda, daveti kabul edene kadar PENDING durumunda olur. Bu, kullanıcının durumuyla ilgili API görünürlüğü sağlar. Bu görünürlük, Content API for Shopping'de mevcut değildi.
Ekle
## İstekler
Merchant API, kullanıcıları yönetmek için aşağıdaki istek URL'lerini kullanır:
GET /accounts/v1/accounts/{account}/users/{email}GET /accounts/v1/accounts/{account}/usersPOST /accounts/v1/accounts/{account}/usersPATCH /accounts/v1/accounts/{account}/users/{email}DELETE /accounts/v1/accounts/{account}/users/{email}
Aşağıdaki tabloda, Content API for Shopping ile Merchant API arasındaki istek URL'leri karşılaştırılmaktadır.
| İstek açıklaması |
Content API for Shopping |
Merchant API |
| Bir hesap için kullanıcıları alma |
GET {api_version}/{merchantId}/accounts/{accountId} |
GET {api_version}/accounts/{account}/users |
| Kullanıcı oluşturma |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
POST {api_version}/accounts/{account}/users |
| Kullanıcı güncelleme |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
PATCH {api_version}/accounts/{account}/users/{email} |
| Kullanıcı silme |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
DELETE {api_version}/accounts/{account}/users/{email} |
Tanımlayıcılar
Aşağıdaki tabloda, Content API for Shopping ile Merchant API arasındaki isteklerde kullanılan tanımlayıcılar karşılaştırılmaktadır.
| Tanımlayıcı açıklaması |
Content API for Shopping |
Merchant API |
| Hesap tanımlayıcısı |
accountId |
account accounts/{account} içinde başlıyor |
| Kullanıcı tanımlayıcısı |
AccountUser nesnesinde email_address |
email accounts/{account}/users/{email} içinde başlıyor |
Yöntemler
Aşağıdaki tabloda, Content API for Shopping ile Merchant API arasındaki yöntemler karşılaştırılmaktadır.
| Content API for Shopping |
Merchant API |
Kullanılabilirlik ve notlar |
accounts.update |
users.create |
Bir hesap için yeni kullanıcı oluşturur. |
accounts.get |
users.get |
Tek bir kullanıcıyı alır. |
accounts.get |
users.list |
Bir hesaptaki tüm kullanıcıları listeler. |
accounts.update |
users.update |
Kullanıcının erişim haklarını günceller. |
accounts.update |
users.delete |
Bir hesaptan kullanıcı siler. |
Ayrıntılı alan değişiklikleri
Alan kullanımınızı aşağıdaki gibi güncelleyin:
| Content API for Shopping |
Merchant API |
Açıklama |
users (AccountUser kez tekrarlandı) |
users (User kez tekrarlandı) |
User kaynağı artık kendi hizmetine sahip üst düzey bir kaynak. |
AccountUser.email_address |
CreateUserRequest.user_id ve User.name kuruluşunun bir parçası |
Kullanıcının e-posta adresi artık kaynak adının bir parçasıdır. Oluşturma sırasında user_id alanında belirtin. |
AccountUser.admin |
access_rights: "ADMIN" |
Merchant API, admin Boole alanını access_rights enum'ındaki ADMIN değeriyle değiştirir. |
AccountUser.order_manager, AccountUser.payments_manager, AccountUser.payments_analyst |
access_rights: "STANDARD" |
Merchant API, bu rolleri STANDARD erişim hakkıyla değiştirir. |
AccountUser.reporting_manager |
access_rights: "PERFORMANCE_REPORTING" |
reporting_manager rolü artık PERFORMANCE_REPORTING erişim hakkı olarak adlandırılıyor. |
AccountUser.read_only |
access_rights: "READ_ONLY" |
read_only rolü artık READ_ONLY erişim hakkı olarak adlandırılıyor. |
| Kullanılamıyor |
User.name |
Kullanıcının tam kaynak adını içerir. Örneğin, accounts/{account}/users/{email}. |
| Kullanılamıyor |
User.state |
Kullanıcının davetiyesinin durumunu (PENDING veya VERIFIED) gösterir. |
Aksi belirtilmediği sürece bu sayfanın içeriği Creative Commons Atıf 4.0 Lisansı altında ve kod örnekleri Apache 2.0 Lisansı altında lisanslanmıştır. Ayrıntılı bilgi için Google Developers Site Politikaları'na göz atın. Java, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-08-08 UTC.
[null,null,["Son güncelleme tarihi: 2025-08-08 UTC."],[],[],null,["# Migrate user and access management\n\nIn Content API for Shopping, you managed users and their access rights with a\nfield in the `Account` resource. Merchant API replaces this with the dedicated\nresource named\n[`User`](/merchant/api/reference/rest/accounts_v1/accounts.users) and\ncorresponding methods (create, delete, get, list, path). For more information,\nsee [Control access to your\naccount](/merchant/api/guides/accounts/control-access).\n\nKey differences\n---------------\n\nCompared to Content API for Shopping, Merchant API offers the following\nadvantages for user management:\n\n- **Dedicated resource**: This provides a more granular and direct way to control who can access your Merchant Center account and what they can do.\n- **RESTful resource names** : In Merchant API, identify `User` resources by a full resource name, for example, `accounts/12345/users/example@example.com`.\n- **`me` alias** : You can use the alias `me` in place of an email address in the resource name to refer to the authenticated user, for example, `accounts/12345/users/me`.\n- **Consolidated access rights** : Merchant API consolidates boolean access fields from Content API (for example, `admin`, `reportingManager`) into a single, repeatable`access_rights` field.\n- **User invitation and verification** : Merchant API introduces an explicit user state (`PENDING` or `VERIFIED`). When you create a new user, they are in a `PENDING` state until they accept the invitation. This provides API visibility into the user's status, which was not available in the Content API for Shopping. Add ## Requests\n\nMerchant API uses the following request URLs to manage users:\n\n- `GET /accounts/v1/accounts/{account}/users/{email}`\n- `GET /accounts/v1/accounts/{account}/users`\n- `POST /accounts/v1/accounts/{account}/users`\n- `PATCH /accounts/v1/accounts/{account}/users/{email}`\n- `DELETE /accounts/v1/accounts/{account}/users/{email}`\n\nThe following table compares the request URLs between the Content API for\nShopping and Merchant API.\n\n| Request description | Content API for Shopping | Merchant API |\n|--------------------------|---------------------------------------------------------|---------------------------------------------------------|\n| Get users for an account | `GET {api_version}/{merchantId}/accounts/{accountId}` | `GET {api_version}/accounts/{account}/users` |\n| Create a user | `PATCH {api_version}/{merchantId}/accounts/{accountId}` | `POST {api_version}/accounts/{account}/users` |\n| Update a user | `PATCH {api_version}/{merchantId}/accounts/{accountId}` | `PATCH {api_version}/accounts/{account}/users/{email}` |\n| Delete a user | `PATCH {api_version}/{merchantId}/accounts/{accountId}` | `DELETE {api_version}/accounts/{account}/users/{email}` |\n\nIdentifiers\n-----------\n\nThe following table compares the identifiers used in requests between the\nContent API for Shopping and Merchant API.\n\n| Identifier description | Content API for Shopping | Merchant API |\n|------------------------|-------------------------------------------------|-----------------------------------------------|\n| Account identifier | `accountId` | `account` in `accounts/{account}` |\n| User identifier | `email_address` within the `AccountUser` object | `email` in `accounts/{account}/users/{email}` |\n\nMethods\n-------\n\nThe following table compares the methods between the Content API for Shopping\nand Merchant API.\n\n| Content API for Shopping | Merchant API | Availability \\& notes |\n|--------------------------|----------------------------------------------------------------------------------|------------------------------------|\n| `accounts.update` | [`users.create`](/merchant/api/reference/rest/accounts_v1/accounts.users/create) | Creates a new user for an account. |\n| `accounts.get` | [`users.get`](/merchant/api/reference/rest/accounts_v1/accounts.users/get) | Retrieves a single user. |\n| `accounts.get` | [`users.list`](/merchant/api/reference/rest/accounts_v1/accounts.users/list) | Lists all users for an account. |\n| `accounts.update` | [`users.update`](/merchant/api/reference/rest/accounts_v1/accounts.users/update) | Updates a user's access rights. |\n| `accounts.update` | [`users.delete`](/merchant/api/reference/rest/accounts_v1/accounts.users/delete) | Deletes a user from an account. |\n\nDetailed field changes\n----------------------\n\nUpdate your use of fields as follows:\n\n| Content API for Shopping | Merchant API | Description |\n|---------------------------------------------------------------------------------------------|-----------------------------------------------------|---------------------------------------------------------------------------------------------------------------|\n| `users` (repeated `AccountUser`) | `users` (repeated `User`) | The `User` resource is now a top-level resource with its own service. |\n| `AccountUser.email_address` | `CreateUserRequest.user_id` and part of `User.name` | The user's email address is now part of the resource name. Specify it in the `user_id` field during creation. |\n| `AccountUser.admin` | `access_rights: \"ADMIN\"` | Merchant API replaces the boolean `admin` field by the `ADMIN` value in the `access_rights` enum. |\n| `AccountUser.order_manager`, `AccountUser.payments_manager`, `AccountUser.payments_analyst` | `access_rights: \"STANDARD\"` | Merchant API replaces these roles to `STANDARD` access right. |\n| `AccountUser.reporting_manager` | `access_rights: \"PERFORMANCE_REPORTING\"` | The `reporting_manager` role is now the `PERFORMANCE_REPORTING` access right. |\n| `AccountUser.read_only` | `access_rights: \"READ_ONLY\"` | The `read_only` role is now the `READ_ONLY` access right. |\n| Not available | `User.name` | Contains the full resource name of the user, for example, `accounts/{account}/users/{email}`. |\n| Not available | `User.state` | Indicates the status of the user's invitation, either `PENDING` or `VERIFIED`. |"]]
