Migrate user and access management

In Content API for Shopping, you managed users and their access rights with a field in the Account resource. Merchant API replaces this with the dedicated resource named User and corresponding methods (create, delete, get, list, path). For more information, see Control access to your account .

Key differences

Compared to Content API for Shopping, Merchant API offers the following advantages for user management:

• Dedicated resource: This provides a more granular and direct way to control who can access your Merchant Center account and what they can do.
• RESTful resource names: In Merchant API, identify User resources by a full resource name, for example, accounts/12345/users/example@example.com .
• 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 .
• Consolidated access rights: Merchant API consolidates boolean access fields from Content API (for example, admin , reportingManager ) into a single, repeatable access_rights field.
• 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

Merchant API uses the following request URLs to manage users:

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

The following table compares the request URLs between the Content API for Shopping and Merchant API.

Request description	Content API for Shopping	Merchant API
Get users for an account	GET {api_version}/{merchantId}/accounts/{accountId}	GET {api_version}/accounts/{account}/users
Create a user	PATCH {api_version}/{merchantId}/accounts/{accountId}	POST {api_version}/accounts/{account}/users
Update a user	PATCH {api_version}/{merchantId}/accounts/{accountId}	PATCH {api_version}/accounts/{account}/users/{email}
Delete a user	PATCH {api_version}/{merchantId}/accounts/{accountId}	DELETE {api_version}/accounts/{account}/users/{email}

Identifiers

The following table compares the identifiers used in requests between the Content API for Shopping and Merchant API.

Identifier description	Content API for Shopping	Merchant API
Account identifier	accountId	account in accounts/{account}
User identifier	email_address within the AccountUser object	email in accounts/{account}/users/{email}

Methods

The following table compares the methods between the Content API for Shopping and Merchant API.

Content API for Shopping	Merchant API	Availability & notes
accounts.update	users.create	Creates a new user for an account.
accounts.get	users.get	Retrieves a single user.
accounts.get	users.list	Lists all users for an account.
accounts.update	users.update	Updates a user's access rights.
accounts.update	users.delete	Deletes a user from an account.

Detailed field changes

Update your use of fields as follows:

Content API for Shopping	Merchant API	Description
users (repeated AccountUser )	users (repeated User )	The User resource is now a top-level resource with its own service.
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.
AccountUser.admin	access_rights: "ADMIN"	Merchant API replaces the boolean admin field by the ADMIN value in the access_rights enum.
AccountUser.order_manager , AccountUser.payments_manager , AccountUser.payments_analyst	access_rights: "STANDARD"	Merchant API replaces these roles to STANDARD access right.
AccountUser.reporting_manager	access_rights: "PERFORMANCE_REPORTING"	The reporting_manager role is now the PERFORMANCE_REPORTING access right.
AccountUser.read_only	access_rights: "READ_ONLY"	The read_only role is now the READ_ONLY access right.
Not available	User.name	Contains the full resource name of the user, for example, accounts/{account}/users/{email} .
Not available	User.state	Indicates the status of the user's invitation, either PENDING or VERIFIED .