Skip to main content
AgenticAdvertising.org レジストリは、AdCP エコシステムにおけるブランドとプロパティの解決、エージェントの発見、認可の検証のためのパブリック REST API を提供します。

ベース URL

ほとんどのエンドポイントはパブリックで認証不要です。認証済みエンドポイントには Bearer トークンが必要です。 完全な OpenAPI 3.1 仕様 がコード生成とツール用に利用可能です。/.well-known/openapi.yaml でも発見できます。

クイックスタート

ブランドドメインを正準アイデンティティに解決します。
Response

レート制限

レート制限されたエンドポイントは、制限を超えると 429 Too Many Requests を返します。

エンドポイントグループ

Brand Resolution

ドメインを正準ブランドアイデンティティに解決し、brand.json ファイルを取得し、ブランドレジストリを参照。

Property Resolution

パブリッシャードメインをプロパティ情報に解決し、adagents.json を検証し、プロパティを参照。

Agent Discovery

インベントリプロファイルでエージェントをリスト、検索、フィルタリング。パブリッシャーを参照し、レジストリ統計を表示。

Change Feed

ローカル同期のためにレジストリ変更のカーソルベースフィードをポーリング。

Lookups & Authorization

ドメインでエージェントをルックアップし、プロダクト認可を検証し、プロパティ認可をリアルタイムで確認。

エンティティ別ルックアップ

3 つのエンドポイントが、レジストリに誰がいるかについての異なる質問に答えます。それらは API リファレンスの 2 つのタググループにまたがるため、エンドポイント固有のパラメーターに入る前に、この表を使って正しいルックアップサーフェスを選んでください。 GET /api/registry/agents — パブリックなエージェント母集団を参照またはフィルタリングしたいときに使います。エージェントがこのカタログに入る方法については エージェントの登録 を参照。リファレンス: Agent Discovery の List agents エンドポイント GET /api/registry/operator?domain=X — 1 つのエンティティを手にしていて、そのエージェントフットプリントを知りたいときに使います。 GET /api/registry/publisher?domain=X — 1 つのパブリッシャーを手にしていて、そのインベントリと委任を知りたいときに使います。

ブランド解決

これらのエンドポイントはドメインをブランドアイデンティティに解決します。レスポンスの source フィールドがデータの出所を示します。 すべてのソースが同じ解決レスポンス構造を生成します。完全なブランドアイデンティティデータ(logos、colors、tone)を得るには、/api/brands/enrich を使うか、レジストリでブランドをルックアップします。

プロパティ解決

エージェント探索

測定ベンダー探索

測定ベンダー(Adelaide スタイルの attention、Scope3 スタイルの emissions、Nielsen DAR、IAS/DV カスタム品質など)を特に発見するには、エージェントリストを type=measurement でフィルタリングします。
これは、AAO メンバーによってレジストリに登録されたすべての測定エージェントを返します。 メトリクスごとのカタログ探索。 各測定エージェントは、その完全なメトリクスごとのカタログを get_adcp_capabilities.measurement.metrics[] — 正準の、ベンダー管理の真実の源泉 — に公開します。AAO は各測定エージェントの get_adcp_capabilities を TTL でクロールし結果を保存します。?capabilities=true を渡すと、カタログが creative_capabilitiessignals_capabilities の隣でレスポンスに折り込まれます。 フィルターパラメーター(存在するときすべて type=measurement を意味します。明示的な非測定タイプは 400 を返します):
直接呼び出し対インデックス — どちらをいつ使うか。 バイヤーはベンダーのメトリクスカタログへの 2 つのパスを持ちます。

Change Feed

ルックアップと認可

認可検証は両側をチェックします: パブリッシャーの adagents.json(主張された delegation_type でこのエージェントを認可するか?)とオペレーターの brand.json(一致する relationship でこのプロパティを宣言するか?)。

バリデーションツール

検索

エージェントプロービング

アクティビティ履歴

GET /api/brands/history?domain={domain}GET /api/properties/history?domain={domain} は、レジストリエントリの編集履歴を新しい順で返します。これらはパブリックエンドポイントです — 認証不要。
Response
editor_name: "system" のエントリは自動エンリッチメントによって書き込まれました。is_rollbacktrue のとき、rolled_back_to に復元されたリビジョン番号が含まれます。ページネーションは limit(最大 100)と offset クエリパラメーターを使います。

不正防止とアンチホモグラフ制御

/api/brands/save/api/properties/save、および adagents 検証エンドポイントは、認証済みメンバー組織からドメイン文字列を受け入れるため、ホストされたレジストリは保存時に多層の不正防止制御の下限を適用します。これらは 3.x 時代の AgenticAdvertising.org レジストリの運用挙動であり — 新しいワイヤサーフェスではありません — タイポスクワット、混同可能なそっくりさん、通りすがりのブランドハイジャックが、単一の認証済み呼び出し元によってインデックスに書き込まれないように存在します。
  • ドメイン正規化(IDNA 2008 + 混同可能検出)。 保存エンドポイントは、永続化前に国際化ドメイン名を ASCII に正規化するために IDNA 2008 を適用すべきで(SHOULD)、次に 2 つのコーパス — (1) インデックス内のすでに登録されたエントリ、(2) レジストリオペレーターが維持する厳選された高価値ブランドの拒否リスト — に対して Unicode 混同可能検出(例: ICU uspoof または同等物)を実行すべきです(SHOULD)。拒否リストは、有名ブランドが自身で登録される前に、それらのタイポスクワットを捕捉します(例: g00gle.com の提出は、Google がまだインデックス行を主張していなくても拒否リストのエントリと衝突します)。曖昧な提出 — 混合スクリプトラベル、ホモグラフ衝突、許可されない Unicode クラス — は、黙ってコミットするのではなく、拒否または人間のレビューのためにフラグを立てるべきです(SHOULD)。
  • コミット前の所有権証明。 保存エンドポイントは、新しいブランドまたはプロパティエントリがインデックスにコミットされる前にドメイン管理の証拠を要求しなければなりません(MUST)— これがこの制御を動機付ける脅威です。侵害されたメンバー API キーを持つ攻撃者は、そうでなければ衝突する以前のエントリを持たない新鮮な混同可能バリアントを自由に一括登録できるからです。同じ認証済み組織による既存のコミュニティソースエントリへのリビジョンについては、再証明はローリングベースで要求されるべきですが(SHOULD。例: 以前の証明が 90 日より古くなったら)、そのウィンドウ内ではスキップしてもかまいません(MAY)。受け入れられる証明は、サーバー発行の nonce に一致する _adcp-owner.{domain} の DNS TXT レコード、またはドメイン上の /.well-known/adcp-ownership.txt にホストされた HTTP チャレンジのいずれかです。nonce は単一使用で、(organization, domain) ペアにスコープされ、発行から 15 分以内に期限切れになければなりません(MUST)。検証は成功時に nonce を消費し、失敗時に無効化しなければなりません(MUST)。期限切れ後のリークまたは未使用の nonce は死んでいます。既存の権威あるエントリ(すなわち brand.json / adagents.json に裏付けられたもの)へのリビジョンは、Save brandSave property の 409 Conflict セマンティクスに従い続けます。所有権証明はコミュニティソースの保存パスをカバーします。
  • 保存に対する組織ごとのレート制限。 レート制限に文書化された IP ごとのレート制限に加えて、保存エンドポイントは、単一の侵害された API キーが混同可能バリアントを一括登録できないよう、組織ごとの制限を適用すべきです(SHOULD)。ホストされた実装はバースト許容の上限を使います(目安: 組織あたり数十保存/時、組織あたり数百/日)。組織ごとのバケットを超える呼び出し元は 429 Too Many Requests を受け取ります。
これらの制御はホストされた AgenticAdvertising.org レジストリによって強制されます。Change Feed を消費するセルフホストミラーは、ホストされたレジストリの保存時チェックに依存し、それらを再実行しません — これはフィードのアドバイザリアイデンティティの姿勢(specs/registry-change-feed.md §Advisory identity material を参照)と一貫しています: フィードは変更検出であり信頼アンカーではなく、パブリッシャー自身の adagents.json ピンが権威あるアイデンティティソースのままです(adagents.json §signing_keys を参照)。代替レジストリ実装を運営するオペレーターは、コミュニティソースの書き込みを受け入れる前に同等の保存時制御を適用すべきです(SHOULD)。

認証

パブリックエンドポイント(解決、探索、検索)は認証不要です。書き込みエンドポイントは、組織 API キー(サーバー間)または OAuth 2.1 経由で取得したユーザー JWT(インタラクティブ/エージェントクライアント)のいずれかを受け入れます。両方とも Authorization: Bearer ... ヘッダーで送信されます。

Option A: 組織 API キー

長寿命、組織スコープ。ユーザーが存在しないサーバー間統合に最適。
  1. agenticadvertising.org/dashboard/api-keys でサインイン
  2. Create key をクリックし、生成されたキーをコピー
Authorization ヘッダーでキーを渡します。

Option B: OAuth 2.1 経由のユーザー SSO

短寿命、ユーザースコープ。人間が AAO にサインインするエージェントクライアント(MCP、AI アシスタント、カスタムアプリ)に最適。単一のトークンが /mcp と REST API の両方に対して機能します。 ディスカバリーは RFC 8414RFC 9728 に従います。
  • 認可サーバーメタデータ: GET /.well-known/oauth-authorization-server
  • 保護リソースメタデータ(REST API): GET /.well-known/oauth-protected-resource/api
  • 保護リソースメタデータ(MCP): GET /.well-known/oauth-protected-resource/mcp
フローは PKCE 付き認可コードです。動的クライアント登録(RFC 7591)が /register で利用可能です。ユーザーは AuthKit 経由で認証します。トークンは WorkOS 署名の JWT です。
有効なユーザー JWT はアイデンティティを証明し、エンタイトルメントは証明しません。組織メンバーシップまたは管理者ロールでゲートされたエンドポイント(ほとんどの書き込みエンドポイント)は、認証済みユーザーが必要な立場を欠く場合、依然として 403 を返します。

認証済みエンドポイント

これらのエンドポイントには有効な API キーが必要です。

Save brand

POST /api/brands/save レジストリでコミュニティブランドを保存または更新します。既存のブランドについては、リビジョン追跡された編集を作成します。brand.json 経由で管理される権威あるブランドは編集できません — それらは 409 Conflict を返します。 リクエストボディ:
domainbrand_name は必須です。brand_manifest(ブランドアイデンティティデータ)は任意です。ブランドの source はサーバーによって "community" に設定されます。ドメインは正規化されます(プロトコル除去、小文字化)。
Response (create)
Response (update)

Save property

POST /api/properties/save レジストリでホストされたプロパティを保存または更新します。既存のプロパティについては、リビジョン追跡された編集を作成します。adagents.json 経由で管理される権威あるプロパティは編集できません — それらは 409 Conflict を返します。 これはアイデンティティのみの書き込みサーフェスです: 保存されるドキュメントは常に authorized_agents: [] を運びます。セールス認可はパブリッシャー自身のオリジン adagents.json にのみ存在します — コミュニティレジストリはそれを作成も運搬もできません — したがってリクエストボディで送られる任意の authorized_agents は無視されます。 リクエストボディ:
publisher_domain は必須です。properties(それぞれ typename を要求)と contact は任意です。ドメインは正規化されます(プロトコル除去、小文字化)。
Response (create)
Response (update)

Change feed

GET /api/registry/feed レジストリ変更のカーソルベースフィードをポーリングします。これを使って、完全なデータセットを再取得せずにレジストリのローカルコピーを同期に保ちます。イベントは UUID v7 の event_id で順序付けられ、単調なカーソル進行を提供します。フィードはイベントを 90 日間保持します — 期限切れのカーソルは 410 Gone を返します。各レスポンスには、コンシューマーが要求したタイプフィルターのフィードラグを測定できるよう freshness メタデータが含まれます。 スキーマ: core/registry-feed-response.jsoncore/registry-event.json アイテムをラップします。 クエリパラメーター: イベントタイプ:
Response
has_moretrue のとき、返された cursor 値を次のリクエストで渡してポーリングを続けます。false のとき、現在のフィードの終わりに達しています — 後で同じカーソルで再度ポーリングして新しいイベントを取得します。 latest_event_created_at は、現在フィードに見える最新の一致イベントです。lag_secondsgenerated_at に対して計算されます。自身のミラー鮮度目標に応じてアラートを設定します。 GET /api/registry/feed/stream は、同じフィードページを Server-Sent Events で提供します。切断後は最後に永続化したカーソルで再接続します。ストリームは上記と同じ JSON 形状で event: feed を、追いついている間 event: heartbeat を発します。カーソルは同じ論理 types サブスクリプションに結び付けられます。カーソルを再利用しながらフィルターを変更すると、以前フィルターされたイベントをスキップする可能性があります。ストリームは再開カーソルを SSE id ではなく JSON data.cursor で運ぶため、ブラウザ EventSource クライアントは ?cursor=... で再接続しなければなりません。 カーソルが期限切れ(90 日より古いか見つからない)の場合、レスポンスは 410 Gone です。
410 Gone
GET /api/registry/agents/search インベントリプロファイル — チャネル、市場、コンテンツカテゴリ、プロパティタイプなど — でエージェントを検索します。フィルターは次元間で AND、次元内で OR を使います。結果は、フィルターマッチの幅、インベントリの深さ、TMP サポートに基づく関連性スコアでランク付けされます。 クエリパラメーター: 各 CSV パラメーターは最大 100 値を受け入れます。
Response
matched_filters 配列は、どのフィルター次元が一致したかを示し、結果が返された理由を理解するのに役立ちます。relevance_score は、フィルターマッチの幅、0.1 で重み付けされた ln(property_count + 1)、TMP サポートの 0.05 のブーストを組み合わせます。

Crawl request

POST /api/registry/crawl-request パブリッシャードメインの即時再クロールをリクエストします。adagents.json ファイルを更新した後にこれを使うと、次のスケジュールされたクロールを待たずにレジストリが変更を取得します。クロールは非同期で実行されます — エンドポイントは直ちに 202 Accepted を返します。 ドメインあたり 5 分ごとに 1 リクエスト、ユーザーあたり 1 時間に 30 リクエストにレート制限されます。 リクエストボディ:
domain は必須です。ドメインは正規化されます(小文字化、トリム)。エンドポイントはドメイン形式を検証し、DNS ルックアップを実行してプライベート/予約済み IP アドレスを拒否します。
202 Accepted
429 Too Many Requests
retry_after は再試行前に待つ秒数です。

Submit brand (legacy)

POST /api/brands/discovered/community レビュー用にブランドを提出します。このエンドポイントは /api/brands/save より前からあります — 新しい統合には save エンドポイントを推奨します。

エラーレスポンス

プロトコル対 REST API

AdCP プロトコルは、エージェント間通信のための MCP と A2A のタスク(例: get_productscreate_media_buy)を定義します。レジストリ REST API は別物です — AgenticAdvertising.org レジストリでエンティティをルックアップするための HTTP エンドポイントを提供します。 REST API を使うのはディスカバリーと認可のためです。
  • プロトコル呼び出しを行う前にブランドまたはプロパティドメインを解決する
  • どのエージェントが存在し、何に認可されているかを発見する
  • アドサービング中にリアルタイムで認可を検証する
  • レジストリを参照または検索する統合を構築する
MCP/A2A タスクを使うのはトランザクショナルな操作のためです。
  • セールスエージェントからプロダクトを取得(get_products
  • メディアバイの作成(create_media_buy
  • クリエイティブの構築(build_creative
  • シグナルの取得(get_signals
典型的な統合は両方を使います: レジストリ API 経由でパブリッシャードメインを解決し、次に認可されたエージェントの MCP エンドポイントを呼び出してトランザクションします。