העברת ניהול משתמשים וגישה
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
ב-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 alias: אפשר להשתמש בכינוי 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 נעשה שימוש בכתובות ה-URL הבאות של בקשות לניהול משתמשים:
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}
בטבלה הבאה מוצגות השוואה בין כתובות ה-URL של הבקשות ב-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} |
| מזהה משתמש |
email_address באובייקט AccountUser |
email ב-accounts/{account}/users/{email} |
Methods
בטבלה הבאה מוצגות השוואה בין השיטות של Content API for Shopping ו-Merchant API.
| Content API for Shopping |
Merchant API |
זמינות והערות |
accounts.update |
users.create |
יוצר משתמש חדש בחשבון. |
accounts.get |
users.get |
מאחזר משתמש יחיד. |
accounts.get |
users.list |
רשימה של כל המשתמשים בחשבון. |
accounts.update |
users.update |
עדכון של זכויות הגישה של משתמש. |
accounts.update |
users.delete |
מחיקת משתמש מחשבון. |
שינויים מפורטים בשדות
מעדכנים את השימוש בשדות באופן הבא:
| 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 מוחלף בערך ADMIN ב-enum 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 (שעון 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`. |"]]
