نقل إدارة المستخدمين وأذونات الوصول
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
في Content API for Shopping، كنت تدير المستخدمين وحقوق الوصول الخاصة بهم باستخدام حقل في مرجع Account
. تحلّ واجهة Merchant API محلّ ذلك باستخدام المورد المخصّص المسمّى User
والطرق ذات الصلة (create وdelete وget وlist وpath). لمزيد من المعلومات،
اطّلِع على مقالة التحكّم في الوصول إلى حسابك.
الاختلافات الرئيسية
مقارنةً بواجهة Content API for Shopping، توفّر 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
إلى أن يقبل الدعوة. يتيح ذلك إمكانية الاطّلاع على حالة المستخدم من خلال واجهة برمجة التطبيقات، وهو أمر لم يكن متاحًا في Content API for Shopping.
إضافة
## طلبات
تستخدم 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 for Shopping وMerchant API.
وصف الطلب |
واجهة برمجة تطبيقات المحتوى في 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.
وصف المعرّف |
واجهة برمجة تطبيقات المحتوى في Shopping |
Merchant API |
معرّف الحساب |
accountId |
account في accounts/{account} |
معرّف المستخدم |
email_address ضمن العنصر AccountUser |
email في accounts/{account}/users/{email} |
الطُرق
يقارن الجدول التالي بين طرق Content API for Shopping وMerchant API.
واجهة برمجة تطبيقات المحتوى في Shopping |
Merchant API |
التوفّر والملاحظات |
accounts.update |
users.create |
تنشئ هذه الطريقة مستخدمًا جديدًا لحساب. |
accounts.get |
users.get |
لاسترداد مستخدم واحد |
accounts.get |
users.list |
تعرض هذه الطريقة قائمة بجميع المستخدمين في حساب معيّن. |
accounts.update |
users.update |
تعديل حقوق وصول المستخدم |
accounts.update |
users.delete |
يحذف هذا الإجراء مستخدمًا من حساب. |
تغييرات الحقول التفصيلية
عدِّل استخدامك للحقول على النحو التالي:
واجهة برمجة تطبيقات المحتوى في 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 بالقيمة 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 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة 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`. |"]]