ウェブデータ

ads.txtとsellers.jsonの検証API

サイトの広告枠の販売を承認されている企業を確認できます。ads.txtまたはapp-ads.txtを解析し、無効な行と重複を検出して、各販売者を広告システム自身のsellers.jsonと照合します。

カテゴリ ウェブデータ
エンドポイント 1
主な機能 4
よくある質問 4

これらの企業の担当者に使われています

InstantOutseerMongoDBRespondentSage Expense ManagementInstantlyD.R. HortonWhatConvertsAdobeLLM Pulse

統合前に確認できる信頼シグナル

透明なドキュメント、認証済みリクエスト、見える信頼性情報により、本番投入前に DomScan を評価しやすくなります。

ライブ サービスステータス

統合前に、現在のサービス稼働状況と文書化されたエラー応答を確認してください。

OpenAPI API アーティファクト

OpenAPI、Swagger、Postman、CLI、SDK、MCP のリンクにすぐアクセスできます。

API キー 保護されたアクセス

認証付きエンドポイントは API キーを使用し、呼び出し前に明確なクレジットコストを示します。

10,000 無料枠

毎月 10,000 クレジットから始め、利用が増えたときだけアップグレードできます。

この API で実装できること

このページを本番導入向けの概要として使えます。エンドポイント、例、レスポンス形状、DomScan を製品に組み込むためのワークフローをまとめています。

プロダクトワークフロー

ドメイン確認、DNS インテリジェンス、リスクシグナル、エンリッチメントをオンボーディング、検索、社内ツールに組み込めます。

アナリスト自動化

繰り返しの手動検索を、スケジュールジョブ、アラート、再現可能な調査手順に置き換えます。

クリーンな JSON データ

提供元ページをスクレイピングせず、予測可能なフィールド、文書化済みステータスコード、クレジットコストを使えます。

AI と運用ツール

OpenAPI、SDK、Postman、MCP を通じて、エージェント、ダッシュボード、SOAR プレイブック、CRM に接続できます。

統合ワークフロー

最初のリクエストから本番で繰り返し使える状態までのシンプルな流れです。

1
一度認証する

文書化されたヘッダーで API キーを送信し、サービス間で一貫したリクエストを保ちます。

2
例から問い合わせる

curl と HTTP サンプルから始め、パラメータをアプリケーションコードに対応付けます。

3
運用と監視

ステータスコード、クレジットコスト、レスポンスフィールドを使ってリトライ、ログ、アラートを構築します。

開発者キット

機械可読なドキュメント、リクエスト集、SDK、エージェント用ツールへすぐ移動できます。

パラメータとレスポンスのマップ

クライアントに接続する前に、入力、出力フィールド、ステータスコードを確認できます。

リクエストパラメータ

パラメータ

urlfileverify_sellers
レスポンスフィールド

レスポンス例

statussummarysummary.recordssummary.directsummary.resellersummary.ad_systemsvariablesvariables.ownerdomainissuessellerssellers.systems_checkedsellers.confirmed
ステータス範囲

HTTP ステータスコード

200400401402429

エンドポイント

GET /v1/ads-txt
クレジット: 2-5認証: 認証が必要です

統合前に確認できる信頼シグナル

透明なドキュメント、認証済みリクエスト、見える信頼性情報により、本番投入前に DomScan を評価しやすくなります。

サービスステータス API アーティファクト

OpenAPI、Swagger、Postman、CLI、SDK、MCP のリンクにすぐアクセスできます。

API キー 保護されたアクセス

認証付きエンドポイントは API キーを使用し、呼び出し前に明確なクレジットコストを示します。

無料枠 無料でサインアップ

毎月 10,000 クレジットから始め、利用が増えたときだけアップグレードできます。

アクティブ リクエスト例

curl と HTTP サンプルから始め、パラメータをアプリケーションコードに対応付けます。

主な機能

ads.txtとapp-ads.txt

ウェブ版のファイル、またはモバイルとコネクテッドTV向けのバージョンを、すべてのレコード、関係、認証局IDとともに検証します。

販売者の確認

verify_sellers=trueを指定すると、各販売者IDが広告システムのsellers.jsonで検索され、確認済み、非公開、type_mismatch、未検出のいずれかに分類されます。

構文チェック

無効な行、不明な関係、アカウントIDの欠落、不正なドメイン、重複するレコードを、行番号とともに集計します。

変数

OWNERDOMAIN、MANAGERDOMAIN、CONTACT、SUBDOMAIN、INVENTORYPARTNERDOMAINの宣言を、見つかったとおりに返します。

リクエスト例

GET /v1/ads-txt?url=example.com&verify_sellers=true bash
curl -H "X-API-Key: $DOMSCAN_API_KEY" "https://domscan.net/v1/ads-txt?url=example.com&verify_sellers=true"

レスポンス例

200 OK json
{
  "status": "found",
  "summary": { "records": 401, "direct": 94, "reseller": 307, "ad_systems": 98 },
  "variables": { "ownerdomain": ["example.com"] },
  "issues": [{ "code": "duplicate_record", "count": 47, "lines": [68, 76, 77] }],
  "sellers": {
    "systems_checked": 10,
    "confirmed": 58,
    "type_mismatch": 7,
    "seller_not_found": 16,
    "unknown": 9
  }
}

よくある質問

type_mismatchとは何を意味しますか?

sellers.jsonに販売者IDは載っているものの、そのタイプが関係と一致していない状態です。たとえば、RESELLER行に対してPUBLISHERのエントリが載っている場合です。

一部の販売者がunknownになるのはなぜですか?

広告システムのsellers.jsonを読み取れなかった、サイズが大きすぎた、または形式が不正だったためです。unknownは、販売者が存在しないことを意味するものではありません。

いくつの広告システムが検証されますか?

1回のリクエストで最大10件です。レコード数とDIRECTの関係が最も多いシステムから順に検証します。

何クレジットかかりますか?

2クレジットです。verify_sellers=trueの場合は5クレジットです。status unknownで終わった結果は返金されます。

関連ツールとリソース

HTTP ステータスコード

正常な応答、認証の問題、クレジット不足、レート制限、データ未検出、上流サービス障害を判別できるよう、クライアントで処理すべきHTTPステータスコードを明記しています。

成功 200

リクエスト成功

不正なリクエスト 400

無効なパラメータ

未認証 401

APIキーまたはセッションが不足しているか無効です。

支払いが必要 402

このリクエストを実行するためのクレジットが不足しています。

リクエスト過多 429

レート制限を超過