Nutzer- und Zugriffsverwaltung migrieren

In der Content API for Shopping haben Sie Nutzer und ihre Zugriffsrechte mit einem Feld in der Ressource Account 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 genauer und direkter steuern, wer auf Ihr Merchant Center-Konto zugreifen und was diese Person tun kann.
• RESTful-Ressourcennamen: In der Merchant API werden User-Ressourcen durch einen vollständigen Ressourcennamen identifiziert, z. B. accounts/12345/users/[e-mail].
• 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: Die Merchant API konsolidiert boolesche Zugriffsfelder aus der Content API (z. B. admin, reportingManager) in einem einzigen, wiederholbaren access_rights-Feld.
• Nutzereinladung und -bestätigung: Die Merchant API führt einen expliziten Nutzerstatus (PENDING oder VERIFIED) ein. Wenn Sie einen neuen Nutzer erstellen, hat er den Status PENDING, bis er die Einladung annimmt. So erhalten Sie über die API Einblick in den Status des Nutzers, was in der Content API for Shopping nicht möglich war. ## Anfragen hinzufügen

Die Merchant API verwendet die folgenden Anfrage-URLs, um Nutzer zu verwalten:

• 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}

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 Kennungen verglichen, die in Anfragen zwischen der Content API for Shopping und der Merchant API verwendet werden.

Beschreibung der ID	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.patch	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 (AccountUser-mal wiederholt)	users (User-mal wiederholt)	Die Ressource User 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 sie 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"	In der Merchant API werden diese Rollen durch die Zugriffsberechtigung „STANDARD“ ersetzt.
AccountUser.reporting_manager	access_rights: "PERFORMANCE_REPORTING"	Die Rolle reporting_manager ist jetzt die Zugriffsberechtigung PERFORMANCE_REPORTING.
AccountUser.read_only	access_rights: "READ_ONLY"	Die Rolle read_only ist jetzt die Zugriffsberechtigung 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.