Миграция пользователей и управления доступом
Оптимизируйте свои подборки
Сохраняйте и классифицируйте контент в соответствии со своими настройками.
В Content API for Shopping управление пользователями и их правами доступа осуществлялось с помощью поля в ресурсе Account . В Merchant API это поле заменяется выделенным ресурсом User и соответствующими методами (create, delete, get, list, path). Подробнее см. в разделе Управление доступом к вашей учетной записи .
Ключевые отличия
По сравнению с Content API for Shopping, Merchant API предлагает следующие преимущества для управления пользователями:
- Выделенный ресурс : это обеспечивает более детальный и прямой способ контроля того, кто может получить доступ к вашей учетной записи Merchant Center и что они могут делать.
- Имена ресурсов RESTful : в API продавца идентифицируйте
User ресурсы по полному имени ресурса, например, accounts/12345/users/example@example.com . -
me alias : Вы можете использовать псевдоним me вместо адреса электронной почты в имени ресурса для ссылки на аутентифицированного пользователя, например, accounts/12345/users/me . - Объединенные права доступа : API торговца объединяет логические поля доступа из API контента (например,
admin , reportingManager ) в одно повторяемое поле access_rights . - Приглашение и верификация пользователя : API продавца вводит явное состояние пользователя (
PENDING или VERIFIED ). При создании нового пользователя он находится в состоянии PENDING до тех пор, пока не примет приглашение. Это обеспечивает API-просмотр статуса пользователя, который был недоступен в API контента для покупок. Добавить ## запросов
API торговца использует следующие URL-адреса запросов для управления пользователями:
-
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}
В следующей таблице сравниваются URL-адреса запросов между Content API for Shopping и Merchant API.
| Запросить описание | API контента для покупок | 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.
| Описание идентификатора | API контента для покупок | API торговца |
|---|
| Идентификатор счета | accountId | account в accounts/{account} |
| Идентификатор пользователя | email_address в объекте AccountUser | email в accounts/{account}/users/{email} |
Методы
В следующей таблице сравниваются методы Content API for Shopping и Merchant API.
| API контента для покупок | API торговца | Доступность и примечания |
|---|
accounts.update | users.create | Создает нового пользователя для учетной записи. |
accounts.get | users.get | Извлекает одного пользователя. |
accounts.get | users.list | Список всех пользователей учетной записи. |
accounts.update | users.update | Обновляет права доступа пользователя. |
accounts.update | users.delete | Удаляет пользователя из учетной записи. |
Подробные изменения полей
Обновите использование полей следующим образом:
| API контента для покупок | API торговца | Описание |
|---|
users (повторяющийся AccountUser ) | users (повторяющийся User ) | Ресурс User теперь является ресурсом верхнего уровня со своим собственным сервисом. |
AccountUser.email_address | CreateUserRequest.user_id и часть User.name | Адрес электронной почты пользователя теперь является частью имени ресурса. Укажите его в поле user_id при создании. |
AccountUser.admin | access_rights: "ADMIN" | API торговца заменяет логическое поле admin значением ADMIN в перечислении access_rights . |
AccountUser.order_manager , AccountUser.payments_manager , AccountUser.payments_analyst | access_rights: "STANDARD" | 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 . |
Если не указано иное, контент на этой странице предоставляется по лицензии Creative Commons "С указанием авторства 4.0", а примеры кода – по лицензии Apache 2.0. Подробнее об этом написано в правилах сайта. Java – это зарегистрированный товарный знак корпорации Oracle и ее аффилированных лиц.
Последнее обновление: 2025-08-08 UTC.
[null,null,["Последнее обновление: 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`. |"]]
