/v1/monitorsエンドポイントを通じて、固定スケジュールで実行される永続的なモニターを作成し、ページの変更を検出し、メール、Slack、SMS、または専用のWebhookを通じて通知を受け取ることができます。
- 自然言語の
queryからモニターを作成 source_policyでソースをスコープ- 自然言語のスケジュールでチェックを実行(最小10分ごと、UTC)
notification.channelsとオプションのwebhook配信を設定- サーバー送信イベントでプロビジョニングの進行をストリーム(
?stream=1) - モニターを一覧表示、検査、更新、一時停止、再開、削除
- スナップショットイベント、計画アーティファクト、実行ログ、ライブエージェントログを読む
queryでその意図を表現してください。
インストール
モニターを作成
POST /v1/monitorsでモニターを作成します。APIは入力を検証し、モニターレコードを予約し、シャドウエージェントをプロビジョニングし、ワークフロースペックを生成し、DAG計画をキューに入れ、繰り返しスケジュールを作成します。
queryは必須です — 自然言語で監視内容を説明します。frequencyはオプションで、デフォルトは毎時です。毎日午前9時のようなスケジューリングフレーズを使用します(スケジュールはUTCで実行されます; 最小間隔は10分です)。source_policyは、include_urls、exclude_urls、include_domains、exclude_domainsをオプションで制約します。notificationは、いつどのようにアラートを行うかを設定します(events+channels)。チャネル配信はモニターパイプラインによって実行時に解決されます — DAGに受信者を渡すことはありません。webhookは、notification.channelsに加えてHTTPコールバック用の別のオブジェクト({ "url": "https://…" })です。output_schemaは、構造化された抽出をオプションで強制します(有効なJSONスキーマ)。
202で、status: provisioningです。モニターは計画がtrackedターゲットを解決した後にactiveに移行します。GET /v1/monitors/:monitor_idをポーリングするか、?stream=1(またはAccept: text/event-stream)を渡して、プロビジョニングフェーズとSSE上のスペック推論トークンを追跡します。
リクエスト例
必要なのはqueryとfrequencyだけです。通知チャネルとWebhookは後でPOST /v1/monitors/:monitor_idで追加できます。
応答
成功した作成(非ストリーミング)は、モニターオブジェクトを持つHTTP202を返します。trackedは計画が終了するまで空です。GET /v1/monitors/:monitor_idをポーリングして、statusがactiveになり、tracked.urlsが埋められるまで待ちます。
構造化モニター出力
特定のJSON構造に従って抽出結果を取得したい場合は、output_schemaを設定します。スキーマは有効なJSONスキーマでなければなりません。
プロビジョニングストリーム
モニターが作成される間にSSEイベントを受け取るために?stream=1を追加するか、Accept: text/event-streamを送信します:
| イベント | 説明 |
|---|---|
phase | プロビジョニングステップ(running、done、またはfailed) |
reasoning_token | インクリメンタルなスペックデザインテキスト |
reasoning_reset | 失敗したLLM試行後にバッファリングされた推論を切り捨てます |
complete | 最終モニターオブジェクト(202応答と同じ形状) |
error | 終端の失敗 |
通知とWebhook
アラートはモニターレコードに設定され、実行時に解決されます — モニタリングqueryにチャネルターゲットを埋め込まないでください。
notification
| フィールド | 説明 |
|---|---|
events | どの実行結果が配信をトリガーするかを指定します。下記の通知イベントを参照してください。channelsを設定してeventsを省略した場合、デフォルトはchangedとfirst_snapshotの両方です。 |
channels | { "type", "target", "events"? }オブジェクトのリスト |
通知イベント
いつ通知を受け取りたいかをeventsで指定します。許可される値:
| イベント | 意味 |
|---|---|
changed | 前のスナップショットと比較して変更が検出されたときに通知します(例:新しいコンテンツ、更新された価格、またはパイプラインが変更として分類する差分)。 |
first_snapshot | モニターが最初のスナップショットを取得したときに通知します — 後の比較の前に現在のコンテンツを保存する初期ベースライン実行。 |
["changed"]はベースライン後の更新のみをアラートします;["first_snapshot"]は差分を待たずにセットアップを確認します;["changed", "first_snapshot"]は両方をカバーします。
チャネルオブジェクトのeventsは同じ値を使用し、そのチャネルのみに対してトップレベルリストをオーバーライドします。
サポートされているチャネルタイプ:
type | targetフォーマット |
|---|---|
email | 有効なメールアドレス |
slack | SlackのインカミングWebhook URL |
sms | E.164電話番号(例:+14155552671) |
webhook
notification.channelsとは別に、webhook.urlはモニターがコールバックURLを発火したときにHTTP POSTペイロードを受け取ります。同じモニターでWebhookとチャネル通知の両方を使用できます。
例
メールのみ:ソースポリシー
source_policyを使用して、プランナーが使用できるURLとドメインを制約します。
頻度
自然言語でfrequencyを設定します。例えば:
毎時(省略時のデフォルト)毎日午前9時毎週日午後2時30分
- スケジューリング言語として読み取れる必要があります(任意のモニター質問ではありません)。
- 最小間隔:10分ごと。
- スケジュールはUTCで保存および実行されます(
schedule.timezoneはUTCです)。 - 最大長:50文字。
frequencyテキストからcron式を導出し、schedule.cronで公開します。モニターがactiveの場合、schedule.next_run_atは次の実行をISO 8601で示します。
モニターを一覧表示
GET /v1/monitorsでチームのすべてのモニターを取得します。
デフォルトでは、削除されたモニターはフィルタリングされます。?include_deleted=trueを使用してそれらを含めます。
応答の形状
モニターを取得
GET /v1/monitors/:monitor_idで単一のモニターを取得します。
応答にはlast_run(最新のスナップショットの概要)とtotal_count(スナップショットの数)が含まれますが、include_total_count=falseを渡さない限り。include-diagram=trueを追加して、モニターDAGのmermaid_diagramを含めます。
応答の形状
モニターイベントを一覧表示
GET /v1/monitors/:monitor_id/eventsを使用して、モニターのスナップショットイベントを一覧表示します。
ページネーション:
limit(デフォルト25、最大100)cursor(next_cursorからの不透明なトークン)count_only=trueは{ "total_count": N }のみを返します
snapshot_urlが含まれます。
応答の形状
モニタープランニングを取得
GET /v1/monitors/:monitor_id/planningを使用して、プロビジョニング後のFDAワークフロースペックとプランナーDAGを検査します。
モニター実行を取得
GET /v1/monitors/:monitor_id/runs/:run_idを使用して、1回の実行(run_idはrun_で始まる必要があります)のスナップショットメタデータと解析されたエージェントログイベントを取得します。
エージェントログをストリーム
GET /v1/monitors/:monitor_id/agent-logs?stream=1(またはAccept: text/event-stream)を使用して、モニターのエージェントのCloudWatchログをこのmonitor_idにフィルタリングして追跡します。
オプションのクエリパラメータsinceはミリ秒のタイムスタンプです(デフォルト:30分前)。
SSEイベントタイプ:ready、log、heartbeat、error。
モニターを更新
POST /v1/monitors/:monitor_idでモニターを更新します。
サポートされているフィールド(変更したいものだけを含めてください):
metadata— 既存のキーとマージされます; 空の文字列値はキーを削除しますfrequency— 内部スケジュールを再作成し、statusをactiveに戻しますnotification— 通知オブジェクト全体を置き換えますwebhook— 削除するにはnullを渡します
statusがprovisioningの間は409を返します。
notification.channelsをeventsなしで追加すると、APIはデフォルトでeventsを["changed", "first_snapshot"]に設定します。
メール通知を追加
Webhookを追加
モニターを一時停止
POST /v1/monitors/:monitor_id/pauseでモニターを一時停止します。
一時停止すると、基礎となるスケジュールが無効になり、statusがpausedに設定されます。status: activeのモニターのみが一時停止できます。リクエストボディは空です。
200とモニターが返され、status: pausedになります。schedule.next_run_atは一時停止中はnullです。
モニターを再開
POST /v1/monitors/:monitor_id/resumeで一時停止されたモニターを再開します。
再開すると、スケジュールが再び有効になり、statusがactiveに戻ります。一時停止されたモニターのみが再開できます。
モニターを削除
DELETE /v1/monitors/:monitor_idでモニターを削除します。
削除はモニターローをソフト削除し(status: deleted)、そのスケジュールとシャドウエージェントリソースを削除します。
モニターステータス
| ステータス | 意味 |
|---|---|
provisioning | エージェント、スペック、プランナー、スケジュールが設定中 |
active | スケジュールが有効; schedule.frequencyで実行が行われる |
paused | /pauseでスケジュールが無効 |
failed | プロビジョニングまたはスケジュール更新が失敗(error_messageが設定されている) |
deleted | DELETEでソフト削除 |
使用例
以下は一般的なモニターパターンです。各例は作成時にqueryとfrequencyのみが必要です; 初回実行または変更時にアラートを受け取りたい場合は、後でnotificationとwebhookを追加します。
Y Combinatorの新しいローンチ
Y Combinator Launchesで新しく公開されたスタートアップを監視します。計画後、tracked.typeはurlsで、tracked.urlsはローンチページを指します。
activeになった後にメールとWebhook配信を追加:
channelsが設定され、eventsが省略された場合、APIはデフォルトで["changed", "first_snapshot"]に設定されるため、ベースライン実行時と変更が検出されたときに通知されます。
競合他社のブログ投稿(AirOps、Profound)
競合他社のブログインデックスを新しい投稿のために監視します。プランナーはtracked.urlsをブログURL(例:https://www.airops.com/blogまたはhttps://www.tryprofound.com/blog)に解決します。
notificationでevents: ["changed"]を使用すると、新しい投稿が表示されたときだけアラートを受け取り、最初のベースラインスナップショットではアラートを受け取りません。
株価の閾値(テスラ)
ページの差分ではなく、条件が数値である場合に構造化データソースを監視します。プランナーはtracked.typeをdata_apiに設定し、tracked.urlsを空にします。
OpenAI APIの変更履歴
OpenAIのAPI変更履歴に新しい機能、モデルリリース、または廃止がリストされると通知を受け取ります。queryで変更履歴URLを言及するか、source_policy.include_urlsで固定します。
eventsを["changed"]に設定して、変更履歴の内容が変わったときに通知を受け取り、最初のスナップショットが保存されたときだけではありません。
複数のモニターを管理
チームのすべてのモニターを一覧表示して、ステータス、スケジュール、および解決されたターゲットを一か所で確認します:data_api価格ウォッチ、メールとWebhookが設定されたYCローンチモニターなど、いくつかのモニターを並べて見ることができ、応答には"count": 4(またはそれ以上)が含まれるかもしれません。
一般的な検証エラー
モニターエンドポイントは、一般的な無効なリクエストに対して明確な検証エラーを返します:queryが欠落しているか空- スケジューリング言語ではない
frequency、10分未満の頻度で解決する、または50文字を超える - 無効な
source_policyエントリ(URL配列には有効なhttp/https文字列が含まれている必要があります) - 無効な
notification形状、未知のevents、または無効なチャネルtype/target - 無効な
webhook.url(httpまたはhttpsである必要があります) - 無効な
output_schema(有効なJSONスキーマである必要があります) - 無効な
monitor_idまたはrun_id形式 statusがprovisioningの間に更新(409)- ステータスが
active/pausedでないときに一時停止/再開