Content API for Shopping では、Account リソースのフィールドを使用して、ユーザーとそのアクセス権を管理していました。Merchant API では、この代わりに User という専用のリソースと対応するメソッド(create、delete、get、list、path)が使用されます。詳しくは、アカウントへのアクセスを制御するをご覧ください。
主な違い
Content API for Shopping と比較して、Merchant API にはユーザー管理に関して次のような利点があります。
- 専用リソース: Merchant Center アカウントにアクセスできるユーザーとその権限を、より細かく直接的に制御できます。
 - RESTful リソース名: Merchant API では、
Userリソースは完全なリソース名(例:accounts/12345/users/example@example.com)で識別します。 meエイリアス: リソース名でメールアドレスの代わりにエイリアスmeを使用して、認証済みユーザーを参照できます(例:accounts/12345/users/me)。- 統合されたアクセス権: Merchant API は、Content API のブール値のアクセス フィールド(
admin、reportingManagerなど)を 1 つの繰り返し可能なaccess_rightsフィールドに統合します。 - ユーザーの招待と確認: Merchant API に明示的なユーザー状態(
PENDINGまたはVERIFIED)が導入されました。新しいユーザーを作成すると、招待を承諾するまでPENDING状態になります。これにより、Content API for Shopping では利用できなかったユーザーのステータスを API で確認できるようになります。## リクエストを追加 
Merchant API は、次のリクエスト URL を使用してユーザーを管理します。
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}
次の表は、Content API for Shopping と Merchant API のリクエスト URL を比較したものです。
| リクエストの説明 | Content API for Shopping | Merchant API | 
|---|---|---|
| アカウントのユーザーを取得する | GET {api_version}/{merchantId}/accounts/{accountId} | 
      GET {api_version}/accounts/{account}/users | 
    
| ユーザーを作成する | PATCH {api_version}/{merchantId}/accounts/{accountId} | 
      POST {api_version}/accounts/{account}/users | 
    
| ユーザーを更新する | PATCH {api_version}/{merchantId}/accounts/{accountId} | 
      PATCH {api_version}/accounts/{account}/users/{email} | 
    
| ユーザーを削除 | PATCH {api_version}/{merchantId}/accounts/{accountId} | 
      DELETE {api_version}/accounts/{account}/users/{email} | 
    
識別子
次の表は、Content API for Shopping と Merchant API のリクエストで使用される ID を比較したものです。
| 識別子の説明 | Content API for Shopping | Merchant API | 
|---|---|---|
| アカウント ID | accountId | 
      account(accounts/{account}) | 
    
| ユーザー識別子 | AccountUser オブジェクト内の email_address | 
      email(accounts/{account}/users/{email}) | 
    
メソッド
次の表は、Content API for Shopping と Merchant API のメソッドを比較したものです。
| Content API for Shopping | Merchant API | 提供状況とメモ | 
|---|---|---|
accounts.update | 
      users.create | 
      アカウントの新しいユーザーを作成します。 | 
accounts.get | 
      users.get | 
      単一のユーザーを取得します。 | 
accounts.get | 
      users.list | 
      アカウントのすべてのユーザーを一覧表示します。 | 
accounts.update | 
      users.update | 
      ユーザーのアクセス権を更新します。 | 
accounts.update | 
      users.delete | 
      アカウントからユーザーを削除します。 | 
フィールドの変更の詳細
フィールドの使用を次のように更新します。
| Content API for Shopping | Merchant API | 説明 | 
|---|---|---|
users(AccountUser を繰り返す) | 
      users(User を繰り返す) | 
      User リソースは、独自のサービスを持つ最上位のリソースになりました。 | 
    
AccountUser.email_address | 
      CreateUserRequest.user_id と User.name の一部 | 
      ユーザーのメールアドレスがリソース名の一部になりました。作成時に user_id フィールドで指定します。 | 
    
AccountUser.admin | 
      access_rights: "ADMIN" | 
      Merchant API は、ブール値の admin フィールドを access_rights 列挙型の ADMIN 値に置き換えます。 | 
    
AccountUser.order_manager、AccountUser.payments_manager、AccountUser.payments_analyst | 
      access_rights: "STANDARD" | 
      Merchant API は、これらのロールを STANDARD アクセス権に置き換えます。 | 
    
AccountUser.reporting_manager | 
      access_rights: "PERFORMANCE_REPORTING" | 
      reporting_manager ロールが PERFORMANCE_REPORTING アクセス権になりました。 | 
    
AccountUser.read_only | 
      access_rights: "READ_ONLY" | 
      read_only ロールが READ_ONLY アクセス権になりました。 | 
    
| 利用不可 | User.name | 
      ユーザーの完全なリソース名(accounts/{account}/users/{email} など)が含まれます。 | 
    
| 利用不可 | User.state | 
      ユーザーの招待のステータス(PENDING または VERIFIED)を示します。 |