مهاجرت کاربر و مدیریت دسترسی
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
در Content API for Shopping، کاربران و حقوق دسترسی آنها را با فیلدی در منبع Account مدیریت کردید. Merchant API این را با منبع اختصاصی به نام User و روش‌های مربوطه (ایجاد، حذف، دریافت، فهرست، مسیر) جایگزین می‌کند. برای اطلاعات بیشتر، به کنترل دسترسی به حساب خود مراجعه کنید.
تفاوت های کلیدی
در مقایسه با Content API برای خرید، Merchant API مزایای زیر را برای مدیریت کاربر ارائه می دهد:
- منبع اختصاصی : این یک روش دقیق و مستقیم برای کنترل افرادی که می توانند به حساب Merchant Center شما دسترسی داشته باشند و کارهایی که می توانند انجام دهند ارائه می دهد.
- نام‌های منابع RESTful : در Merchant API، منابع
User را با نام کامل منبع شناسایی کنید، برای مثال accounts/12345/users/example@example.com . - نام مستعار
me : می توانید از نام مستعار me به جای آدرس ایمیل در نام منبع برای مراجعه به کاربر تأیید شده استفاده کنید، به عنوان مثال، accounts/12345/users/me . - حقوق دسترسی تلفیقی : Merchant API فیلدهای دسترسی بولی را از Content API (به عنوان مثال،
admin ، reportingManager ) در یک فیلد access_rights تکرارپذیر یکپارچه می کند. - دعوت و تأیید کاربر : Merchant API یک وضعیت کاربر صریح (
PENDING یا VERIFIED ) را معرفی می کند. وقتی کاربر جدیدی ایجاد می‌کنید، تا زمانی که دعوت را نپذیرد، در وضعیت PENDING هستند. این امکان مشاهده API را در وضعیت کاربر فراهم می کند، که در Content API برای خرید در دسترس نبود. ## درخواست اضافه کنید
Merchant 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 برای خرید و Merchant API مقایسه می کند.
| درخواست توضیحات | Content API برای خرید | 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 برای خرید و Merchant API مقایسه می‌کند.
| شرح شناسه | Content API برای خرید | Merchant API |
|---|
| شناسه حساب | accountId | account در accounts/{account} |
| شناسه کاربر | email_address در شیء AccountUser | email در accounts/{account}/users/{email} |
روش ها
جدول زیر روش‌های بین Content API برای خرید و Merchant API را مقایسه می‌کند.
| Content API برای خرید | Merchant API | در دسترس بودن و یادداشت ها |
|---|
accounts.update | users.create | یک کاربر جدید برای یک حساب کاربری ایجاد می کند. |
accounts.get | users.get | یک کاربر را بازیابی می کند. |
accounts.get | users.list | همه کاربران را برای یک حساب فهرست می کند. |
accounts.update | users.update | حقوق دسترسی کاربر را به روز می کند. |
accounts.update | users.delete | یک کاربر را از یک حساب حذف می کند. |
تغییرات میدان دقیق
استفاده از فیلدها را به صورت زیر به روز کنید:
| Content API برای خرید | 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 بولی را با مقدار ADMIN در فهرست access_rights جایگزین می‌کند. |
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 . |
جز در مواردی که غیر از این ذکر شده باشد،محتوای این صفحه تحت مجوز Creative Commons Attribution 4.0 License است. نمونه کدها نیز دارای مجوز Apache 2.0 License است. برای اطلاع از جزئیات، به خطمشیهای سایت Google Developers مراجعه کنید. جاوا علامت تجاری ثبتشده Oracle و/یا شرکتهای وابسته به آن است.
تاریخ آخرین بهروزرسانی 2025-08-08 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 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`. |"]]
