Nutzer- und Zugriffsverwaltung migrieren
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
In der Content API for Shopping haben Sie Nutzer und ihre Zugriffsrechte mit einem Feld in der Account-Ressource verwaltet. In der Merchant API wird dies durch die dedizierte Ressource User und die entsprechenden Methoden (create, delete, get, list, path) ersetzt. Weitere Informationen finden Sie unter Zugriff auf Ihr Konto steuern.
Wichtige Unterschiede
Im Vergleich zur Content API for Shopping bietet die Merchant API die folgenden Vorteile für die Nutzerverwaltung:
- Dedizierte Ressource: Damit können Sie detaillierter und direkter steuern, wer auf Ihr Merchant Center-Konto zugreifen kann und was die jeweiligen Nutzer tun dürfen.
- RESTful-Ressourcennamen: In der Merchant API werden
User-Ressourcen durch einen vollständigen Ressourcennamen identifiziert, z. B. accounts/12345/users/example@example.com.
me-Alias: Sie können den Alias me anstelle einer E-Mail-Adresse im Ressourcennamen verwenden, um auf den authentifizierten Nutzer zu verweisen, z. B. accounts/12345/users/me.- Konsolidierte Zugriffsrechte: In der Merchant API werden boolesche Zugriffsfelder aus der Content API (z. B.
admin, reportingManager) in einem einzelnen, wiederholbaren access_rights-Feld zusammengefasst.
- Nutzereinladung und ‑bestätigung: In der Merchant API wird ein expliziter Nutzerstatus (
PENDING oder VERIFIED) eingeführt. Wenn Sie einen neuen Nutzer erstellen, hat er den Status PENDING, bis er die Einladung annimmt. Dadurch wird der Status des Nutzers über die API sichtbar, was in der Content API for Shopping nicht möglich war.
## Anfragen hinzufügen
Die Merchant API verwendet die folgenden Anfrage-URLs zum Verwalten von Nutzern:
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}
In der folgenden Tabelle werden die Anfrage-URLs der Content API for Shopping und der Merchant API verglichen.
| Beschreibung der Anfrage |
Content API for Shopping |
Merchant API |
| Nutzer für ein Konto abrufen |
GET {api_version}/{merchantId}/accounts/{accountId} |
GET {api_version}/accounts/{account}/users |
| Nutzer erstellen |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
POST {api_version}/accounts/{account}/users |
| Nutzer aktualisieren |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
PATCH {api_version}/accounts/{account}/users/{email} |
| Nutzer löschen |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
DELETE {api_version}/accounts/{account}/users/{email} |
IDs
In der folgenden Tabelle werden die in Anfragen verwendeten Kennzeichnungen zwischen der Content API for Shopping und der Merchant API verglichen.
| Beschreibung der Kennung |
Content API for Shopping |
Merchant API |
| Konto-ID |
accountId |
account in accounts/{account} |
| Nutzer-ID |
email_address im AccountUser-Objekt |
email in accounts/{account}/users/{email} |
Methoden
In der folgenden Tabelle werden die Methoden der Content API for Shopping und der Merchant API verglichen.
| Content API for Shopping |
Merchant API |
Verfügbarkeit und Hinweise |
accounts.update |
users.create |
Erstellt einen neuen Nutzer für ein Konto. |
accounts.get |
users.get |
Ruft einen einzelnen Nutzer ab. |
accounts.get |
users.list |
Listet alle Nutzer für ein Konto auf. |
accounts.update |
users.update |
Aktualisiert die Zugriffsrechte eines Nutzers. |
accounts.update |
users.delete |
Löscht einen Nutzer aus einem Konto. |
Detaillierte Feldänderungen
Aktualisieren Sie die Verwendung von Feldern so:
| Content API for Shopping |
Merchant API |
Beschreibung |
users (wiederholt AccountUser) |
users (wiederholt User) |
Die User-Ressource ist jetzt eine Ressource der obersten Ebene mit einem eigenen Dienst. |
AccountUser.email_address |
CreateUserRequest.user_id und Teil von User.name |
Die E-Mail-Adresse des Nutzers ist jetzt Teil des Ressourcennamens. Geben Sie ihn beim Erstellen im Feld user_id an. |
AccountUser.admin |
access_rights: "ADMIN" |
In der Merchant API wird das boolesche Feld admin durch den Wert ADMIN im Enum access_rights ersetzt. |
AccountUser.order_manager, AccountUser.payments_manager, AccountUser.payments_analyst |
access_rights: "STANDARD" |
Die Merchant API ersetzt diese Rollen durch das Zugriffsrecht STANDARD. |
AccountUser.reporting_manager |
access_rights: "PERFORMANCE_REPORTING" |
Die Rolle reporting_manager ist jetzt das Zugriffsrecht PERFORMANCE_REPORTING. |
AccountUser.read_only |
access_rights: "READ_ONLY" |
Die Rolle read_only ist jetzt das Zugriffsrecht READ_ONLY. |
| Nicht verfügbar |
User.name |
Enthält den vollständigen Ressourcennamen des Nutzers, z. B. accounts/{account}/users/{email}. |
| Nicht verfügbar |
User.state |
Gibt den Status der Einladung des Nutzers an, entweder PENDING oder VERIFIED. |
Sofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers. Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.
Zuletzt aktualisiert: 2025-08-08 (UTC).
[null,null,["Zuletzt aktualisiert: 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`. |"]]
