Migra la administración de usuarios y accesos

En Content API for Shopping, administrabas a los usuarios y sus derechos de acceso con un campo en el recurso Account. La API de Merchant reemplaza este elemento por el recurso dedicado llamado User y los métodos correspondientes (create, delete, get, list, path). Para obtener más información, consulta Cómo controlar el acceso a tu cuenta.

Diferencias clave

En comparación con Content API for Shopping, Merchant API ofrece las siguientes ventajas para la administración de usuarios:

• Recurso dedicado: Proporciona una forma más detallada y directa de controlar quién puede acceder a tu cuenta de Merchant Center y qué puede hacer.
• Nombres de recursos basados en REST: En la API de Merchant, identifica los recursos User por un nombre de recurso completo, por ejemplo, accounts/12345/users/example@example.com.
• Alias me: Puedes usar el alias me en lugar de una dirección de correo electrónico en el nombre del recurso para hacer referencia al usuario autenticado, por ejemplo, accounts/12345/users/me.
• Derechos de acceso consolidados: La API de Merchant consolida los campos de acceso booleanos de la API de Content (por ejemplo, admin, reportingManager) en un solo campo access_rights repetible.
• Invitación y verificación de usuarios: La API de Merchant Center introduce un estado de usuario explícito (PENDING o VERIFIED). Cuando creas un usuario nuevo, este se encuentra en el estado PENDING hasta que acepta la invitación. Esto proporciona visibilidad de la API sobre el estado del usuario, que no estaba disponible en Content API for Shopping. Agregar ## solicitudes

La API de Merchant usa las siguientes URLs de solicitud para administrar usuarios:

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

En la siguiente tabla, se comparan las URLs de solicitud entre la Content API for Shopping y la Merchant API.

Descripción de la solicitud	Content API for Shopping	API de Merchant
Obtener usuarios de una cuenta	GET {api_version}/{merchantId}/accounts/{accountId}	GET {api_version}/accounts/{account}/users
Crea un usuario	PATCH {api_version}/{merchantId}/accounts/{accountId}	POST {api_version}/accounts/{account}/users
Actualiza un usuario	PATCH {api_version}/{merchantId}/accounts/{accountId}	PATCH {api_version}/accounts/{account}/users/{email}
Borra un usuario	PATCH {api_version}/{merchantId}/accounts/{accountId}	DELETE {api_version}/accounts/{account}/users/{email}

Identificadores

En la siguiente tabla, se comparan los identificadores que se usan en las solicitudes entre la Content API for Shopping y la Merchant API.

Descripción del identificador	Content API for Shopping	API de Merchant
Identificador de la cuenta	accountId	account en accounts/{account}
Identificador del usuario	email_address dentro del objeto AccountUser	email en accounts/{account}/users/{email}

Métodos

En la siguiente tabla, se comparan los métodos de Content API for Shopping y Merchant API.

Content API for Shopping	API de Merchant	Disponibilidad y notas
accounts.update	users.create	Crea un usuario nuevo para una cuenta.
accounts.get	users.get	Recupera un solo usuario.
accounts.get	users.list	Enumera todos los usuarios de una cuenta.
accounts.update	users.update	Actualiza los derechos de acceso de un usuario.
accounts.update	users.delete	Borra un usuario de una cuenta.

Cambios detallados en los campos

Actualiza el uso de los campos de la siguiente manera:

Content API for Shopping	API de Merchant	Descripción
users (AccountUser repetido)	users (User repetido)	El recurso User ahora es un recurso de nivel superior con su propio servicio.
AccountUser.email_address	CreateUserRequest.user_id y parte de User.name	La dirección de correo electrónico del usuario ahora forma parte del nombre del recurso. Especifícalo en el campo user_id durante la creación.
AccountUser.admin	access_rights: "ADMIN"	La API de Merchant reemplaza el campo booleano admin por el valor ADMIN en el enum access_rights.
AccountUser.order_manager, AccountUser.payments_manager, AccountUser.payments_analyst	access_rights: "STANDARD"	La API de Merchant reemplaza estos roles por el derecho de acceso STANDARD.
AccountUser.reporting_manager	access_rights: "PERFORMANCE_REPORTING"	El rol reporting_manager ahora es el derecho de acceso PERFORMANCE_REPORTING.
AccountUser.read_only	access_rights: "READ_ONLY"	El rol read_only ahora es el derecho de acceso READ_ONLY.
No disponible	User.name	Contiene el nombre completo del recurso del usuario, por ejemplo, accounts/{account}/users/{email}.
No disponible	User.state	Indica el estado de la invitación del usuario, ya sea PENDING o VERIFIED.