Eseguire la migrazione della gestione degli utenti e dell'accesso
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Nell'API Content for Shopping, gestivi gli utenti e i loro diritti di accesso con un campo nella risorsa Account
. L'API Merchant sostituisce questo elemento con la risorsa dedicata denominata User
e i metodi corrispondenti (create, delete, get, list, path). Per saperne di più,
consulta Controllare l'accesso al tuo
account.
Differenze principali
Rispetto a Content API for Shopping, l'API Merchant offre i seguenti vantaggi per la gestione degli utenti:
- Risorsa dedicata: offre un modo più granulare e diretto per
controllare chi può accedere al tuo account Merchant Center e cosa può fare.
- Nomi delle risorse RESTful: nell'API Merchant, identifica le risorse
User
tramite un
nome completo della risorsa, ad esempio accounts/12345/users/example@example.com
.
- Alias
me
: puoi utilizzare l'alias me
al posto di un indirizzo email nel nome della risorsa per fare riferimento all'utente autenticato, ad esempio accounts/12345/users/me
.
- Diritti di accesso consolidati: l'API Merchant consolida i campi di accesso booleani
dell'API Content (ad esempio,
admin
, reportingManager
) in un
unico campo ripetibileaccess_rights
.
- Invito e verifica dell'utente: l'API Merchant introduce uno
stato utente esplicito (
PENDING
o VERIFIED
). Quando crei un nuovo utente,
questi si trova nello stato PENDING
finché non accetta l'invito. In questo modo
l'API ha visibilità sullo stato dell'utente, cosa che non era disponibile
nella Content API for Shopping.
Aggiungi
## Richieste
L'API Merchant utilizza i seguenti URL di richiesta per gestire gli utenti:
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}
La seguente tabella confronta gli URL delle richieste tra l'API Content for Shopping e l'API Merchant.
Descrizione della richiesta |
API Content per Shopping |
API Merchant |
Recuperare gli utenti di un account |
GET {api_version}/{merchantId}/accounts/{accountId} |
GET {api_version}/accounts/{account}/users |
Crea un utente |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
POST {api_version}/accounts/{account}/users |
Aggiornare un utente |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
PATCH {api_version}/accounts/{account}/users/{email} |
Eliminazione di un utente |
PATCH {api_version}/{merchantId}/accounts/{accountId} |
DELETE {api_version}/accounts/{account}/users/{email} |
Identificatori
La tabella seguente confronta gli identificatori utilizzati nelle richieste tra
Content API for Shopping e Merchant API.
Descrizione dell'identificatore |
API Content per Shopping |
API Merchant |
Identificatore dell'account |
accountId |
account in accounts/{account} |
Identificatore utente |
email_address all'interno dell'oggetto AccountUser |
email in accounts/{account}/users/{email} |
Metodi
La seguente tabella mette a confronto i metodi dell'API Content for Shopping
e dell'API Merchant.
API Content per Shopping |
API Merchant |
Disponibilità e note |
accounts.update |
users.create |
Crea un nuovo utente per un account. |
accounts.get |
users.get |
Recupera un singolo utente. |
accounts.get |
users.list |
Elenca tutti gli utenti di un account. |
accounts.update |
users.update |
Aggiorna i diritti di accesso di un utente. |
accounts.update |
users.delete |
Elimina un utente da un account. |
Modifiche dettagliate ai campi
Aggiorna l'utilizzo dei campi come segue:
API Content per Shopping |
API Merchant |
Descrizione |
users (ripetuto AccountUser ) |
users (ripetuto User ) |
La risorsa User ora è una risorsa di primo livello con un proprio servizio. |
AccountUser.email_address |
CreateUserRequest.user_id e parte di User.name |
L'indirizzo email dell'utente ora fa parte del nome della risorsa. Specificalo nel campo user_id durante la creazione. |
AccountUser.admin |
access_rights: "ADMIN" |
L'API Merchant sostituisce il campo booleano admin con il valore ADMIN nell'enumerazione access_rights . |
AccountUser.order_manager , AccountUser.payments_manager , AccountUser.payments_analyst |
access_rights: "STANDARD" |
L'API Merchant sostituisce questi ruoli con il diritto di accesso STANDARD . |
AccountUser.reporting_manager |
access_rights: "PERFORMANCE_REPORTING" |
Il ruolo reporting_manager ora è il diritto di accesso PERFORMANCE_REPORTING . |
AccountUser.read_only |
access_rights: "READ_ONLY" |
Il ruolo read_only ora è il diritto di accesso READ_ONLY . |
Non disponibile |
User.name |
Contiene il nome completo della risorsa dell'utente, ad esempio accounts/{account}/users/{email} . |
Non disponibile |
User.state |
Indica lo stato dell'invito dell'utente, ovvero PENDING o VERIFIED . |
Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.
Ultimo aggiornamento 2025-08-08 UTC.
[null,null,["Ultimo aggiornamento 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`. |"]]