サブアカウントの構造

サブアカウントの構造、特に site_uri フィールドの形式は、プラットフォームの URL 構造によって決まります。

AFP でサポートされているサイト構造の種類は次のとおりです。

ユースケース	URL 構造	API の site_uri フィールドの値	API の request_id フィールドの値
サブドメイン	ルート: https://littlepig.example.com コンテンツ: https://littlepig.example.com/food.html	littlepig.example.com	littlepig（またはユーザーに関連付けられた内部一意の ID）
サブフォルダ	ルート: https://example.com/littlepig または https://example.com/sites/littlepig コンテンツ: https://example.com/littlepig/food.html または https://example.com/sites/littlepig/food.html	example.com/littlepig または example.com/sites/littlepig	littlepig（またはユーザーに関連付けられた内部一意の ID）
サブドメインとサブフォルダの組み合わせ	ルート: https://sites.example.com/sites/littlepig コンテンツ: https://sites.example.com/sites/littlepig/food.html	sites.example.com/sites/littlepig	littlepig（またはユーザーに関連付けられた内部一意の ID）
個別の URL	ルート（または作成者のプロフィール）: https://example.com/user/littlepig コンテンツ: https://example.com/nf8ag4n	example.com/user/littlepig 重要: このユースケースでは、すべてのページに「プラットフォームの作成者」メタタグが追加で必要となります。	littlepig（またはユーザーに関連付けられた内部一意の ID）

ユーザーがプラットフォームに複数のプロパティを持っている場合にサブアカウントを作成する方法

サブアカウントはユーザーにマッピングすることを目的としています。1 人のユーザーがプラットフォームで複数のプロパティ（サブドメイン、フォルダ、プロフィール ページなど）を所有できる場合は、そのユーザーにマッピングされたサブアカウントに、そのユーザーに関連付けられているすべてのプロパティが含まれている必要があります。

このシナリオの「request_id」の値

プラットフォームでユーザーごとに複数のプロパティが許可されている場合は、request_id フィールドでユーザーの内部一意の識別子を使用することをおすすめします。今後、get account API メソッドで、このフィールドの値に基づいてアカウントを取得できるようになります。

注: 現在、Platforms API には、1 つのアカウントに site_uri の複数のインスタンスの追加を行う sites メソッドがなく、アカウント作成 API は site_uri の 1 つのインスタンスのみをサポートしています。プラットフォームがこのタイプの構造に適合しているかどうかについては、アカウント マネージャーにお問い合わせください。