迁移用户和访问权限管理
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
在 Content API for Shopping 中,您可以使用 Account
资源中的某个字段来管理用户及其访问权限。Merchant API 使用名为 User
的专用资源和相应的方法(create、delete、get、list、path)替换了此资源。如需了解详情,请参阅控制对您账号的访问权限。
主要差异
与 Content API for Shopping 相比,Merchant API 在用户管理方面具有以下优势:
- 专用资源:这种方式可更精细、更直接地控制哪些人可以访问您的 Merchant Center 账号以及他们可以执行哪些操作。
- RESTful 资源名称:在 Merchant API 中,通过完整资源名称(例如
accounts/12345/users/example@example.com
)来标识 User
资源。
me
别名:您可以在资源名称中使用别名 me
代替电子邮件地址来指代经过身份验证的用户,例如 accounts/12345/users/me
。
- 整合的访问权限:Merchant API 将 Content API 中的布尔值访问权限字段(例如
admin
、reportingManager
)整合为一个可重复的 access_rights
字段。
- 用户邀请和验证:Merchant API 引入了明确的用户状态(
PENDING
或 VERIFIED
)。创建新用户后,在用户接受邀请之前,他们处于 PENDING
状态。这样一来,API 就可以了解用户的状态,而 Content API for Shopping 无法做到这一点。
添加
## 请求
Merchant API 使用以下请求网址来管理用户:
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}
下表比较了 Content API for Shopping 与 Merchant API 之间的请求网址。
请求说明 |
Content API for Shopping |
Merchant API |
获取账号的用户 |
GET {api_version}/{merchantId}/accounts/{accountId} |
GET {api_version}/accounts/{account}/users |
创建用户 |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
POST {api_version}/accounts/{account}/users |
更新用户 |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
PATCH {api_version}/accounts/{account}/users/{email} |
删除用户 |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
DELETE {api_version}/accounts/{account}/users/{email} |
标识符
下表比较了 Content API for Shopping 和 Merchant API 中请求所使用的标识符。
标识符说明 |
Content API for Shopping |
Merchant API |
账号标识符 |
accountId |
account (在 accounts/{account} 中) |
用户标识符 |
AccountUser 对象中的 email_address |
email (在 accounts/{account}/users/{email} 中) |
方法
下表比较了 Content API for Shopping 和 Merchant API 的方法。
详细的字段更改
按如下所示更新字段的使用方式:
Content API for Shopping |
Merchant API |
说明 |
users (重复 AccountUser ) |
users (重复 User ) |
User 资源现在是具有自己服务的顶级资源。 |
AccountUser.email_address |
CreateUserRequest.user_id 和 User.name 的一部分 |
用户的电子邮件地址现在是资源名称的一部分。在创建时,在 user_id 字段中指定该值。 |
AccountUser.admin |
access_rights: "ADMIN" |
Merchant API 将布尔值 admin 字段替换为 access_rights 枚举中的 ADMIN 值。 |
AccountUser.order_manager 、AccountUser.payments_manager 、AccountUser.payments_analyst |
access_rights: "STANDARD" |
Merchant API 会将这些角色替换为 STANDARD 访问权限。 |
AccountUser.reporting_manager |
access_rights: "PERFORMANCE_REPORTING" |
reporting_manager 角色现在是 PERFORMANCE_REPORTING 访问权限。 |
AccountUser.read_only |
access_rights: "READ_ONLY" |
read_only 角色现在是 READ_ONLY 访问权限。 |
不可用 |
User.name |
包含用户的完整资源名称,例如 accounts/{account}/users/{email} 。 |
不可用 |
User.state |
表示用户的邀请状态,可以是 PENDING 或 VERIFIED 。 |
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-08-08。
[null,null,["最后更新时间 (UTC):2025-08-08。"],[],[],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`. |"]]