Migrer la gestion des utilisateurs et des accès
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Dans Content API for Shopping, vous gériez les utilisateurs et leurs droits d'accès à l'aide d'un champ dans la ressource Account. L'API Merchant remplace cela par la ressource dédiée nommée User et les méthodes correspondantes (create, delete, get, list, path). Pour en savoir plus, consultez Contrôler l'accès à votre compte.
Principales différences
Par rapport à Content API for Shopping, Merchant API offre les avantages suivants pour la gestion des utilisateurs :
- Ressource dédiée : cette option vous permet de contrôler plus précisément et directement qui peut accéder à votre compte Merchant Center et ce qu'il peut y faire.
- Noms de ressources RESTful : dans l'API Merchant, identifiez les ressources
User par un nom de ressource complet, par exemple accounts/12345/users/example@example.com.
- Alias
me : vous pouvez utiliser l'alias me à la place d'une adresse e-mail dans le nom de la ressource pour faire référence à l'utilisateur authentifié, par exemple accounts/12345/users/me.
- Droits d'accès consolidés : l'API Merchant consolide les champs d'accès booléens de l'API Content (par exemple,
admin, reportingManager) dans un seul champ access_rights répétable.
- Invitation et validation des utilisateurs : l'API Merchant introduit un état d'utilisateur explicite (
PENDING ou VERIFIED). Lorsque vous créez un utilisateur, il est dans l'état PENDING jusqu'à ce qu'il accepte l'invitation. Cela permet d'obtenir une visibilité sur l'état de l'utilisateur via l'API, ce qui n'était pas possible dans Content API for Shopping.
Ajouter
## Demandes
L'API Merchant utilise les URL de requête suivantes pour gérer les utilisateurs :
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}
Le tableau suivant compare les URL de requête entre Content API for Shopping et l'API Merchant.
| Description de la requête |
Content API for Shopping |
API Merchant |
| Obtenir les utilisateurs d'un compte |
GET {api_version}/{merchantId}/accounts/{accountId} |
GET {api_version}/accounts/{account}/users |
| Créer un compte utilisateur |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
POST {api_version}/accounts/{account}/users |
| Mettre à jour un utilisateur |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
PATCH {api_version}/accounts/{account}/users/{email} |
| Supprimer un compte utilisateur |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
DELETE {api_version}/accounts/{account}/users/{email} |
Identifiants
Le tableau suivant compare les identifiants utilisés dans les requêtes entre Content API for Shopping et l'API Merchant.
| Description de l'identifiant |
Content API for Shopping |
API Merchant |
| Identifiant de compte |
accountId |
account en accounts/{account} |
| Identifiant utilisateur |
email_address dans l'objet AccountUser |
email en accounts/{account}/users/{email} |
Méthodes
Le tableau suivant compare les méthodes de l'API Content pour Shopping et de l'API Merchant.
| Content API for Shopping |
API Merchant |
Disponibilité et remarques |
accounts.update |
users.create |
Crée un utilisateur pour un compte. |
accounts.get |
users.get |
Récupère un seul utilisateur. |
accounts.get |
users.list |
Liste tous les utilisateurs d'un compte. |
accounts.update |
users.update |
Met à jour les droits d'accès d'un utilisateur. |
accounts.update |
users.delete |
Supprime un utilisateur d'un compte. |
Modifications détaillées des champs
Mettez à jour votre utilisation des champs comme suit :
| Content API for Shopping |
API Merchant |
Description |
users (répétition : AccountUser) |
users (répétition : User) |
La ressource User est désormais une ressource de premier niveau avec son propre service. |
AccountUser.email_address |
CreateUserRequest.user_id et fait partie de User.name |
L'adresse e-mail de l'utilisateur fait désormais partie du nom de la ressource. Spécifiez-le dans le champ user_id lors de la création. |
AccountUser.admin |
access_rights: "ADMIN" |
L'API Merchant remplace le champ booléen admin par la valeur ADMIN dans l'énumération access_rights. |
AccountUser.order_manager, AccountUser.payments_manager, AccountUser.payments_analyst |
access_rights: "STANDARD" |
L'API Merchant remplace ces rôles par le droit d'accès STANDARD. |
AccountUser.reporting_manager |
access_rights: "PERFORMANCE_REPORTING" |
Le rôle reporting_manager est désormais le droit d'accès PERFORMANCE_REPORTING. |
AccountUser.read_only |
access_rights: "READ_ONLY" |
Le rôle read_only est désormais le droit d'accès READ_ONLY. |
| Non disponible |
User.name |
Contient le nom complet de la ressource de l'utilisateur, par exemple accounts/{account}/users/{email}. |
| Non disponible |
User.state |
Indique l'état de l'invitation de l'utilisateur (PENDING ou VERIFIED). |
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/08 (UTC).
[null,null,["Dernière mise à jour le 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`. |"]]
