Skip to main content
Über den Olostep-Endpunkt /v1/monitors kannst du dauerhafte Monitore erstellen, die nach einem festen Zeitplan laufen, Seitenänderungen erkennen und dich per E-Mail, Slack, SMS oder einem dedizierten Webhook benachrichtigen.
  • Erstelle einen Monitor aus einer natürlichen Sprach-query
  • Begrenze Quellen mit source_policy
  • Führe Überprüfungen nach Zeitplänen in natürlicher Sprache durch (mindestens alle 10 Minuten, UTC)
  • Konfiguriere notification.channels und optionale webhook-Lieferung
  • Streame den Bereitstellungsfortschritt mit Server-Sent Events (?stream=1)
  • Liste, inspiziere, aktualisiere, pausiere, setze fort und lösche Monitore
  • Lies Snapshot-Ereignisse, Planungsartefakte, Laufprotokolle und Live-Agentenprotokolle
Standardmäßig erfasst jeder Monitorlauf einen vollständigen Snapshot der überwachten Seite — ein vollständiges Bild ihres aktuellen Zustands zu diesem Zeitpunkt. Wenn du möchtest, dass der Monitor nur das Neue oder Geänderte zwischen den Läufen (Deltas) anzeigt, anstatt den vollständigen Zustand, drücke diese Absicht in der query aus.

Installation

Erstelle einen Monitor

Erstelle einen Monitor mit POST /v1/monitors. Die API validiert deine Eingaben, reserviert einen Monitor-Datensatz, stellt einen Schattenagenten bereit, generiert eine Workflow-Spezifikation, reiht die DAG-Planung ein und erstellt einen wiederkehrenden Zeitplan.
  • query ist erforderlich — beschreibe, was in natürlicher Sprache überwacht werden soll.
  • frequency ist optional und standardmäßig auf jede Stunde gesetzt. Verwende Planungsphrasen wie jeden Tag um 9 Uhr (Zeitpläne laufen in UTC; Mindestintervall ist 10 Minuten).
  • source_policy schränkt optional include_urls, exclude_urls, include_domains und exclude_domains ein.
  • notification konfiguriert, wann und wie benachrichtigt werden soll (events + channels). Die Kanalzustellung wird zur Laufzeit durch die Monitor-Pipeline aufgelöst — du übergibst keine Empfänger an die DAG.
  • webhook ist ein separates Objekt ({ "url": "https://…" }) für HTTP-Rückrufe zusätzlich zu notification.channels.
  • output_schema erzwingt optional eine strukturierte Extraktion (gültiges JSON-Schema).
Die Erstellungsantwort ist HTTP 202 mit status: provisioning. Der Monitor wechselt zu active, nachdem die Planung tracked-Ziele aufgelöst hat. Poll GET /v1/monitors/:monitor_id oder übergebe ?stream=1 (oder Accept: text/event-stream), um die Bereitstellungsphasen und Spezifikationsbegründungstoken über SSE zu verfolgen.

Beispielanfrage

Du benötigst nur query und frequency. Benachrichtigungskanäle und Webhooks können später mit POST /v1/monitors/:monitor_id hinzugefügt werden.

Antwort

Eine erfolgreiche Erstellung (nicht-streaming) gibt HTTP 202 mit einem Monitor-Objekt zurück. tracked ist leer, bis die Planung abgeschlossen ist; poll GET /v1/monitors/:monitor_id, bis status active ist und tracked.urls gefüllt ist.

Strukturierte Monitor-Ausgabe

Setze output_schema, wenn du möchtest, dass die Extraktionsergebnisse einer bestimmten JSON-Struktur folgen. Das Schema muss ein gültiges JSON-Schema sein.

Bereitstellungsstream

Füge ?stream=1 hinzu oder sende Accept: text/event-stream, um SSE-Ereignisse zu erhalten, während der Monitor erstellt wird:

Benachrichtigungen und Webhooks

Benachrichtigungen werden im Monitor-Datensatz konfiguriert und zur Laufzeit aufgelöst — bette keine Kanalziele in die Überwachungs-query ein.

notification

Benachrichtigungsereignisse

Verwende events, um anzugeben, wann du benachrichtigt werden möchtest. Erlaubte Werte: Du kannst eines oder beide einschließen. Zum Beispiel, ["changed"] benachrichtigt nur bei Updates nach der Baseline; ["first_snapshot"] bestätigt die Einrichtung, ohne auf einen Unterschied zu warten; ["changed", "first_snapshot"] deckt beides ab. Pro-Kanal-events auf einem Kanalobjekt verwenden die gleichen Werte und überschreiben die Top-Level-Liste nur für diesen Kanal. Unterstützte Kanaltypen:

webhook

Unabhängig von notification.channels empfängt webhook.url HTTP-POST-Nutzlasten, wenn der Monitor deine Callback-URL auslöst. Du kannst sowohl einen Webhook als auch Kanalbenachrichtigungen auf demselben Monitor verwenden.

Beispiele

Nur E-Mail:
Webhook-Callback:
SMS:

Quellenrichtlinie

Verwende source_policy, um einzuschränken, welche URLs und Domains der Planer verwenden darf.

Frequenzen

Setze frequency in natürlicher Sprache, zum Beispiel:
  • jede Stunde (Standard, wenn weggelassen)
  • jeden Tag um 9 Uhr
  • jeden Wochentag um 14:30 Uhr
Regeln:
  • Muss als Planungssprache lesbar sein (keine willkürliche Monitorfrage).
  • Mindestintervall: alle 10 Minuten.
  • Zeitpläne werden in UTC gespeichert und ausgeführt (schedule.timezone ist UTC).
  • Maximale Länge: 50 Zeichen.
Die API leitet einen Cron-Ausdruck aus deinem frequency-Text ab und zeigt ihn in schedule.cron an. Wenn der Monitor active ist, zeigt schedule.next_run_at den nächsten Lauf in ISO 8601 an.

Monitore auflisten

Rufe alle Monitore für dein Team mit GET /v1/monitors ab. Standardmäßig werden gelöschte Monitore herausgefiltert. Verwende ?include_deleted=true, um sie einzuschließen.

Antwortform

Einen Monitor abrufen

Rufe einen einzelnen Monitor mit GET /v1/monitors/:monitor_id ab. Die Antwort enthält last_run (zusammenfassende Informationen des letzten Snapshots) und total_count (Anzahl der Snapshots), es sei denn, du übergibst include_total_count=false. Füge include-diagram=true hinzu, um ein mermaid_diagram des Monitor-DAGs einzuschließen.

Antwortform

Monitor-Ereignisse auflisten

Verwende GET /v1/monitors/:monitor_id/events, um Snapshot-Ereignisse für einen Monitor aufzulisten. Paginierung:
  • limit (Standard 25, max 100)
  • cursor (undurchsichtiger Token aus next_cursor)
  • count_only=true gibt nur { "total_count": N } zurück
Ereignisse werden in absteigender Reihenfolge zurückgegeben. Jedes Element enthält eine kurzlebige, vorab signierte snapshot_url.

Antwortform

Monitor-Planung abrufen

Verwende GET /v1/monitors/:monitor_id/planning, um die FDA-Workflow-Spezifikation und den Planer-DAG nach der Bereitstellung zu inspizieren.

Einen Monitorlauf abrufen

Verwende GET /v1/monitors/:monitor_id/runs/:run_id für Snapshot-Metadaten und geparste Agentenprotokollereignisse für eine Ausführung (run_id muss mit run_ beginnen).

Agentenprotokolle streamen

Verwende GET /v1/monitors/:monitor_id/agent-logs?stream=1 (oder Accept: text/event-stream), um CloudWatch-Protokolle für den Agenten des Monitors zu verfolgen, gefiltert auf diese monitor_id. Optionaler Abfrageparameter since ist ein Millisekunden-Zeitstempel (Standard: vor 30 Minuten). SSE-Ereignistypen: ready, log, heartbeat, error.

Einen Monitor aktualisieren

Aktualisiere einen Monitor mit POST /v1/monitors/:monitor_id. Unterstützte Felder (nur das einfügen, was du ändern möchtest):
  • metadata — wird mit vorhandenen Schlüsseln zusammengeführt; leere Zeichenfolgenwerte löschen Schlüssel
  • frequency — erstellt den internen Zeitplan neu und setzt status zurück auf active
  • notification — ersetzt das gesamte Benachrichtigungsobjekt
  • webhooknull übergeben, um zu entfernen
Gibt 409 zurück, während status provisioning ist. Wenn du notification.channels ohne events hinzufügst, setzt die API events standardmäßig auf ["changed", "first_snapshot"].

E-Mail-Benachrichtigung hinzufügen

Webhook hinzufügen

Einen Monitor pausieren

Pausiere einen Monitor mit POST /v1/monitors/:monitor_id/pause. Das Pausieren deaktiviert den zugrunde liegenden Zeitplan und setzt status auf paused. Nur Monitore mit status: active können pausiert werden. Der Anfragetext ist leer.
Bei Erfolg wird 200 mit dem Monitor und status: paused zurückgegeben. schedule.next_run_at ist null, während pausiert.

Einen Monitor fortsetzen

Setze einen pausierten Monitor mit POST /v1/monitors/:monitor_id/resume fort. Das Fortsetzen aktiviert den Zeitplan erneut und setzt status zurück auf active. Nur paused-Monitore können fortgesetzt werden.

Einen Monitor löschen

Lösche einen Monitor mit DELETE /v1/monitors/:monitor_id. Das Löschen löscht die Monitorzeile soft (status: deleted) und entfernt seine Zeitplan- und Schattenagenten-Ressourcen.

Monitorstatus

Beispielanwendungsfälle

Nachfolgend sind gängige Monitor-Muster aufgeführt. Jedes Beispiel benötigt nur query und frequency zur Erstellungszeit; füge notification und webhook später hinzu, wenn du Benachrichtigungen beim ersten Lauf oder bei Änderungen möchtest.

Neue Y Combinator-Starts

Beobachte Y Combinator Launches für neu veröffentlichte Startups. Nach der Planung ist tracked.type urls und tracked.urls zeigt auf die Launches-Seite.
Füge E-Mail- und Webhook-Zustellung hinzu, nachdem der Monitor active ist:
Mit channels gesetzt und events weggelassen, setzt die API standardmäßig ["changed", "first_snapshot"], sodass du beim Baseline-Lauf und bei jeder erkannten Änderung benachrichtigt wirst.

Wettbewerber-Blogbeiträge (AirOps, Profound)

Überwache einen Wettbewerber-Blog-Index auf neue Beiträge. Der Planer löst tracked.urls zur Blog-URL auf (zum Beispiel https://www.airops.com/blog oder https://www.tryprofound.com/blog).
Nach der Erstellung sieht ein Monitor in dieser Familie so aus:
Verwende events: ["changed"] auf notification, wenn du nur Benachrichtigungen möchtest, wenn neue Beiträge erscheinen, nicht beim ersten Baseline-Snapshot.

Aktienkurs-Schwelle (Tesla)

Überwache eine strukturierte Datenquelle, wenn die Bedingung numerisch ist und nicht ein Seitenunterschied. Der Planer setzt tracked.type auf data_api und lässt tracked.urls leer.

OpenAI API-Änderungsprotokoll

Lass dich benachrichtigen, wenn das OpenAI API-Änderungsprotokoll neue Funktionen, Modellveröffentlichungen oder Abkündigungen auflistet. Erwähne die Änderungsprotokoll-URL in query oder fixiere sie mit source_policy.include_urls.
Setze events auf ["changed"], damit du benachrichtigt wirst, wenn sich der Inhalt des Änderungsprotokolls ändert, nicht nur, wenn der erste Snapshot gespeichert wird.

Verwaltung mehrerer Monitore

Liste jeden Monitor für dein Team auf, um Status, Zeitpläne und aufgelöste Ziele an einem Ort zu sehen:
Ein Team, das die oben genannten Beispiele ausführt, könnte mehrere Monitore nebeneinander sehen — Blogüberwachungen mit unterschiedlichen Frequenzen, eine data_api-Preisüberwachung und einen YC-Launches-Monitor mit konfigurierter E-Mail- und Webhook-Benachrichtigung — mit "count": 4 (oder mehr) in der Antwort.

Häufige Validierungsfehler

Die Monitor-Endpunkte geben klare Validierungsfehler für häufige ungültige Anfragen zurück:
  • Fehlende oder leere query
  • frequency, die keine Planungssprache ist, zu oft auflöst (unter 10 Minuten) oder 50 Zeichen überschreitet
  • Ungültige source_policy-Einträge (URL-Arrays müssen gültige http/https-Zeichenfolgen enthalten)
  • Ungültige notification-Form, unbekannte events oder ungültiger Kanal-type / target
  • Ungültige webhook.url (muss http oder https sein)
  • Ungültiges output_schema (muss gültiges JSON-Schema sein)
  • Ungültiges monitor_id oder run_id-Format
  • Aktualisierung, während status provisioning ist (409)
  • Pause/fortsetzen, wenn der Status nicht active / paused ist
Beispiel für einen Fehler: