/v1/monitors puoi creare monitor persistenti che funzionano su un programma fisso, rilevano le modifiche delle pagine e ti notificano tramite email, Slack, SMS o un webhook dedicato.
- Crea un monitor da una
queryin linguaggio naturale - Limita le fonti con
source_policy - Esegui controlli su programmi in linguaggio naturale (minimo ogni 10 minuti, UTC)
- Configura
notification.channelse consegna opzionale tramitewebhook - Trasmetti il progresso del provisioning con Server-Sent Events (
?stream=1) - Elenca, ispeziona, aggiorna, metti in pausa, riprendi ed elimina i monitor
- Leggi eventi snapshot, artefatti di pianificazione, log di esecuzione e log degli agenti in tempo reale
query.
Installazione
Crea un monitor
Crea un monitor conPOST /v1/monitors. L’API convalida il tuo input, riserva un record del monitor, fornisce un agente ombra, genera una specifica del flusso di lavoro, mette in coda la pianificazione del DAG e crea un programma ricorrente.
queryè obbligatoria — descrivi cosa monitorare in linguaggio naturale.frequencyè opzionale e predefinita aogni ora. Usa frasi di pianificazione comeogni giorno alle 9am(i programmi vengono eseguiti in UTC; l’intervallo minimo è 10 minuti).source_policylimita facoltativamenteinclude_urls,exclude_urls,include_domainseexclude_domains.notificationconfigura quando e come avvisare (events+channels). La consegna del canale viene risolta in fase di esecuzione dalla pipeline del monitor — non passi i destinatari nel DAG.webhookè un oggetto separato ({ "url": "https://…" }) per le chiamate HTTP oltre anotification.channels.output_schemaimpone facoltativamente un’estrazione strutturata (JSON Schema valido).
202 con status: provisioning. Il monitor passa a active dopo che la pianificazione risolve i target tracked. Effettua il polling con GET /v1/monitors/:monitor_id o passa ?stream=1 (o Accept: text/event-stream) per seguire le fasi di provisioning e i token di ragionamento delle specifiche tramite SSE.
Esempio di richiesta
Hai bisogno solo diquery e frequency. I canali di notifica e i webhook possono essere aggiunti successivamente con POST /v1/monitors/:monitor_id.
Risposta
La creazione avvenuta con successo (non in streaming) restituisce HTTP202 con un oggetto monitor. tracked è vuoto fino al termine della pianificazione; effettua il polling con GET /v1/monitors/:monitor_id fino a quando status è active e tracked.urls è popolato.
Output strutturato del monitor
Impostaoutput_schema quando vuoi che i risultati dell’estrazione seguano una struttura JSON specifica. Lo schema deve essere un JSON Schema valido.
Stream di provisioning
Aggiungi?stream=1 o invia Accept: text/event-stream per ricevere eventi SSE mentre il monitor viene creato:
| Evento | Descrizione |
|---|---|
phase | Fase di provisioning (running, done, o failed) |
reasoning_token | Testo incrementale di progettazione delle specifiche |
reasoning_reset | Trunca il ragionamento bufferizzato dopo un tentativo LLM fallito |
complete | Oggetto monitor finale (stessa forma della risposta 202) |
error | Fallimento terminale |
Notifiche e webhook
Gli avvisi sono configurati sul record del monitor e risolti in fase di esecuzione — non incorporare i target dei canali nellaquery di monitoraggio.
notification
| Campo | Descrizione |
|---|---|
events | Quali esiti delle esecuzioni devono attivare la consegna. Vedi eventi di notifica sotto. Se imposti channels e ometti events, il valore predefinito è sia changed che first_snapshot. |
channels | Elenco di oggetti { "type", "target", "events"? } |
Eventi di notifica
Usaevents per indicare quando vuoi essere notificato. Valori consentiti:
| Evento | Significato |
|---|---|
changed | Notifica quando il monitor rileva un cambiamento rispetto allo snapshot precedente (ad esempio nuovo contenuto, prezzo aggiornato, o una differenza che la pipeline classifica come cambiata). |
first_snapshot | Notifica quando il monitor effettua il suo primo snapshot — l’esecuzione iniziale di base che memorizza il contenuto corrente prima dei confronti successivi. |
["changed"] avvisa solo sugli aggiornamenti dopo la base; ["first_snapshot"] conferma l’impostazione senza aspettare una differenza; ["changed", "first_snapshot"] copre entrambi.
Gli events per canale su un oggetto canale utilizzano gli stessi valori e sovrascrivono l’elenco a livello superiore solo per quel canale.
Tipi di canale supportati:
type | Formato target |
|---|---|
email | Indirizzo email valido |
slack | URL webhook in entrata di Slack |
sms | Numero di telefono E.164 (ad esempio +14155552671) |
webhook
Separato da notification.channels, webhook.url riceve payload HTTP POST quando il monitor attiva il tuo URL di callback. Puoi usare sia un webhook che le notifiche di canale sullo stesso monitor.
Esempi
Solo email:Politica delle fonti
Usasource_policy per limitare quali URL e domini il pianificatore può utilizzare.
Frequenze
Impostafrequency in linguaggio naturale, ad esempio:
ogni ora(predefinito se omesso)ogni giorno alle 9amogni giorno feriale alle 14:30
- Deve essere leggibile come linguaggio di pianificazione (non una domanda arbitraria del monitor).
- Intervallo minimo: ogni 10 minuti.
- I programmi sono memorizzati ed eseguiti in UTC (
schedule.timezoneèUTC). - Lunghezza massima: 50 caratteri.
frequency e la espone su schedule.cron. Quando il monitor è active, schedule.next_run_at mostra la prossima esecuzione in ISO 8601.
Elenca i monitor
Recupera tutti i monitor per il tuo team conGET /v1/monitors.
Per impostazione predefinita, i monitor eliminati sono filtrati. Usa ?include_deleted=true per includerli.
Forma della risposta
Ottieni un monitor
Recupera un singolo monitor conGET /v1/monitors/:monitor_id.
La risposta include last_run (riepilogo dell’ultimo snapshot) e total_count (conteggio degli snapshot) a meno che tu non passi include_total_count=false. Aggiungi include-diagram=true per includere un mermaid_diagram del DAG del monitor.
Forma della risposta
Elenca gli eventi del monitor
UsaGET /v1/monitors/:monitor_id/events per elencare gli eventi snapshot per un monitor.
Paginazione:
limit(predefinito25, massimo100)cursor(token opaco danext_cursor)count_only=truerestituisce solo{ "total_count": N }
snapshot_url pre-firmato a breve termine.
Forma della risposta
Ottieni la pianificazione del monitor
UsaGET /v1/monitors/:monitor_id/planning per ispezionare la specifica del flusso di lavoro FDA e il DAG del pianificatore dopo il provisioning.
Ottieni un’esecuzione del monitor
UsaGET /v1/monitors/:monitor_id/runs/:run_id per i metadati dello snapshot e gli eventi di log dell’agente analizzati per un’esecuzione (run_id deve iniziare con run_).
Stream dei log dell’agente
UsaGET /v1/monitors/:monitor_id/agent-logs?stream=1 (o Accept: text/event-stream) per seguire i log di CloudWatch per l’agente del monitor, filtrati per questo monitor_id.
Il parametro di query opzionale since è un timestamp in millisecondi (predefinito: 30 minuti fa).
Tipi di eventi SSE: ready, log, heartbeat, error.
Aggiorna un monitor
Aggiorna un monitor conPOST /v1/monitors/:monitor_id.
Campi supportati (includi solo ciò che vuoi cambiare):
metadata— unito con le chiavi esistenti; i valori di stringa vuoti eliminano le chiavifrequency— ricrea il programma interno e impostastatusdi nuovo suactivenotification— sostituisce l’intero oggetto di notificawebhook— passanullper rimuovere
409 mentre status è provisioning.
Quando aggiungi notification.channels senza events, l’API predefinisce events a ["changed", "first_snapshot"].
Aggiungi notifica email
Aggiungi webhook
Metti in pausa un monitor
Metti in pausa un monitor conPOST /v1/monitors/:monitor_id/pause.
Mettere in pausa disabilita il programma sottostante e imposta status su paused. Solo i monitor con status: active possono essere messi in pausa. Il corpo della richiesta è vuoto.
200 con il monitor e status: paused. schedule.next_run_at è null mentre è in pausa.
Riprendi un monitor
Riprendi un monitor in pausa conPOST /v1/monitors/:monitor_id/resume.
Riprendere riabilita il programma e imposta status di nuovo su active. Solo i monitor paused possono essere ripresi.
Elimina un monitor
Elimina un monitor conDELETE /v1/monitors/:monitor_id.
L’eliminazione elimina in modo soft la riga del monitor (status: deleted) e rimuove le sue risorse di programma e agente ombra.
Stato del monitor
| Stato | Significato |
|---|---|
provisioning | L’agente, la specifica, il pianificatore e il programma sono in fase di configurazione |
active | Programma abilitato; le esecuzioni avvengono su schedule.frequency |
paused | Programma disabilitato tramite /pause |
failed | Il provisioning o l’aggiornamento del programma è fallito (error_message impostato) |
deleted | Eliminato in modo soft tramite DELETE |
Esempi di casi d’uso
Di seguito sono riportati i modelli comuni di monitor. Ogni esempio ha bisogno solo diquery e frequency al momento della creazione; aggiungi notification e webhook in seguito se vuoi avvisi alla prima esecuzione o su modifiche.
Nuovi lanci di Y Combinator
Osserva Y Combinator Launches per le startup pubblicate di recente. Dopo la pianificazione,tracked.type è urls e tracked.urls punta alla pagina dei lanci.
active:
channels impostato e events omesso, l’API predefinisce ["changed", "first_snapshot"] così sei notificato sull’esecuzione di base e ogni volta che viene rilevata una modifica.
Post del blog dei concorrenti (AirOps, Profound)
Monitora l’indice del blog di un concorrente per nuovi post. Il pianificatore risolvetracked.urls all’URL del blog (ad esempio https://www.airops.com/blog o https://www.tryprofound.com/blog).
events: ["changed"] su notification se vuoi avvisi solo quando appaiono nuovi post, non sul primo snapshot di base.
Soglia del prezzo delle azioni (Tesla)
Monitora una fonte di dati strutturata quando la condizione è numerica piuttosto che una differenza di pagina. Il pianificatore impostatracked.type su data_api e lascia tracked.urls vuoto.
Changelog dell’API OpenAI
Ricevi notifiche quando il changelog dell’API di OpenAI elenca nuove funzionalità, rilasci di modelli o deprecazioni. Menziona l’URL del changelog nellaquery o fissalo con source_policy.include_urls.
events su ["changed"] in modo da essere avvisato quando il contenuto del changelog cambia, non solo quando viene memorizzato il primo snapshot.
Gestione di più monitor
Elenca ogni monitor per il tuo team per vedere lo stato, i programmi e i target risolti in un unico posto:data_api e un monitor di lanci YC con email e webhook configurati — con "count": 4 (o più) nella risposta.
Errori di convalida comuni
Gli endpoint del monitor restituiscono errori di convalida chiari per richieste non valide comuni:querymancante o vuotafrequencyche non è linguaggio di pianificazione, risolve troppo spesso (sotto i 10 minuti), o supera i 50 caratteri- Voci
source_policynon valide (gli array di URL devono contenere stringhehttp/httpsvalide) - Forma
notificationnon valida,eventssconosciuti, otype/targetdel canale non valido webhook.urlnon valido (deve esserehttpohttps)output_schemanon valido (deve essere un JSON Schema valido)- Formato
monitor_idorun_idnon valido - Aggiornamento mentre
statusèprovisioning(409) - Pausa/ripresa quando lo stato non è
active/paused