ย้ายข้อมูลการจัดการผู้ใช้และการเข้าถึง
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
ใน 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 จนกว่าจะยอมรับคำเชิญ ซึ่งจะช่วยให้ 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} |
เมธอด
ตารางต่อไปนี้เปรียบเทียบวิธีการระหว่าง 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 |
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 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`. |"]]
