account_id 値の取得に使用します。
上流管理のアカウント名前空間では、list_accounts は任意のディスカバリーの飾りではなく、名前空間ディスカバリー契約です。上流プラットフォームがアクセス可能なアカウントセットを所有するため、バイヤーは最初のアカウントスコープリクエストの前に明示的な account_id を解決しなければなりません(MUST)。認証済みクレデンシャルが複数のアカウントにアクセスできる場合、セラーは list_accounts を公開しなければなりません(MUST)。正確に 1 つのアカウントにアクセスできる場合、SDK が自動選択して必須アカウント呼び出しで { "account_id": "..." } を送れるよう、セラーはそのシングルトンを返す list_accounts を公開すべきです(SHOULD)。sync_accounts プロビジョニングは、将来の明示的なケイパビリティがそのモードを宣言しない限り、3.0.x でアカウント ID アカウントを作成しません。今日これらのセラーで sync_accounts が公開されている場合、それは account_id ですでに識別されたアカウントに対する設定更新にのみ使用します。
list_accounts はすべてのベンダープロトコルで機能する — メディアバイエージェント、シグナルエージェント、ガバナンスエージェント、クリエイティブエージェントはすべてこの同じタスクを通じてアカウントを返します。
応答時間: 約1秒。
リクエストスキーマ: static/schemas/source/account/list-accounts-request.json
レスポンススキーマ: /schemas/v3/account/list-accounts-response.json
クイックスタート
このエージェントが操作できるすべてのアカウントを一覧表示します。リクエストパラメーター
すべてのパラメーターはオプション。空のリクエストは、認証済み呼び出し元に見えるすべてのアカウントを返します。既知の 1 アカウントをaccount_id または自然キー(brand + operator、オプションで sandbox)で再読み取りするときは account を使います。
レスポンス
各アカウントには以下が含まれます:
単一パブリッシャーのカーディナリティ
正確に 1 つのパブリッシャーエンティティを提供するセラーは、呼び出しプリンシパルに関わらず、そのエンティティをlist_accounts レスポンスの唯一のアカウントとして返してもよい(MAY)。list-accounts-response.json の “Direct advertiser with single account” の例がこのケースの正準です — pagination エンベロープを全く持たない単一要素の accounts[]。
pagination.has_more: true を要求するページネーションコンフォーマンスは、次の場合には適用されません:
paginationが完全に不在(正準の単一アカウント形状)、またはpagination.total_countが存在し ≤ 1
not_applicable として採点すべきです(SHOULD)。このパターンはコンフォーマントです。スペックは accounts[] に minItems 制約を持たず、単一アカウントの例は規範的です。
一般的なシナリオ
アカウントがアクティブになるまでポーリング
sync_accounts が pending_approval を返した後、アカウントが準備できるまでポーリングします。
アクティブなアカウントのみフィルタ
エラーハンドリング
次のステップ
- sync_accounts — セラーと広告主アカウントを同期します
- sync_governance — ガバナンスエージェントをアカウントに同期します
- アカウントとエージェント — 請求モデル、信頼モデル、認可オペレーター
- ブランドプロトコル — ベンダーエージェントがブランドの
domainからブランドアイデンティティを解決する方法