Skip to main content
A través del endpoint de Olostep /v1/monitors puedes crear monitores persistentes que se ejecutan en un horario fijo, detectan cambios en la página y te notifican por correo electrónico, Slack, SMS o un webhook dedicado.
  • Crea un monitor a partir de una query en lenguaje natural
  • Delimita fuentes con source_policy
  • Ejecuta verificaciones en horarios en lenguaje natural (mínimo cada 10 minutos, UTC)
  • Configura notification.channels y entrega opcional de webhook
  • Transmite el progreso de aprovisionamiento con eventos enviados por el servidor (?stream=1)
  • Lista, inspecciona, actualiza, pausa, reanuda y elimina monitores
  • Lee eventos de instantáneas, artefactos de planificación, registros de ejecución y registros de agentes en vivo
Por defecto, cada ejecución del monitor captura una instantánea completa de la página monitoreada: una imagen completa de su estado actual en ese momento. Si deseas que el monitor muestre solo lo nuevo o cambiado entre ejecuciones (deltas) en lugar del estado completo, expresa esa intención en la query.

Instalación

Crear un monitor

Crea un monitor con POST /v1/monitors. La API valida tu entrada, reserva un registro de monitor, aprovisiona un agente sombra, genera una especificación de flujo de trabajo, pone en cola la planificación de DAG y crea un horario recurrente.
  • query es obligatorio: describe qué observar en lenguaje natural.
  • frequency es opcional y por defecto es every hour. Usa frases de programación como every day at 9am (los horarios se ejecutan en UTC; el intervalo mínimo es 10 minutos).
  • source_policy opcionalmente restringe include_urls, exclude_urls, include_domains y exclude_domains.
  • notification configura cuándo y cómo alertar (events + channels). La entrega de canales se resuelve en tiempo de ejecución por la tubería del monitor: no pasas destinatarios al DAG.
  • webhook es un objeto separado ({ "url": "https://…" }) para devoluciones de llamada HTTP además de notification.channels.
  • output_schema opcionalmente impone una extracción estructurada (JSON Schema válido).
La respuesta de creación es HTTP 202 con status: provisioning. El monitor pasa a active después de que la planificación resuelve los objetivos tracked. Haz polling a GET /v1/monitors/:monitor_id o pasa ?stream=1 (o Accept: text/event-stream) para seguir las fases de aprovisionamiento y los tokens de razonamiento de especificaciones a través de SSE.

Ejemplo de solicitud

Solo necesitas query y frequency. Los canales de notificación y webhooks se pueden agregar más tarde con POST /v1/monitors/:monitor_id.

Respuesta

La creación exitosa (no en streaming) devuelve HTTP 202 con un objeto monitor. tracked está vacío hasta que la planificación termina; realiza polling a GET /v1/monitors/:monitor_id hasta que status sea active y tracked.urls esté poblado.

Salida estructurada del monitor

Configura output_schema cuando desees que los resultados de extracción sigan una estructura JSON específica. El esquema debe ser un JSON Schema válido.

Flujo de aprovisionamiento

Agrega ?stream=1 o envía Accept: text/event-stream para recibir eventos SSE mientras se crea el monitor:

Notificaciones y webhooks

Las alertas se configuran en el registro del monitor y se resuelven en tiempo de ejecución: no incrustes objetivos de canal en la query de monitoreo.

notification

Eventos de notificación

Usa events para indicar cuándo deseas ser notificado. Valores permitidos: Puedes incluir uno o ambos. Por ejemplo, ["changed"] alerta solo sobre actualizaciones después de la referencia; ["first_snapshot"] confirma la configuración sin esperar una diferencia; ["changed", "first_snapshot"] cubre ambos. Los events por canal en un objeto de canal usan los mismos valores y anulan la lista de nivel superior solo para ese canal. Tipos de canal soportados:

webhook

Separado de notification.channels, webhook.url recibe cargas útiles HTTP POST cuando el monitor activa tu URL de devolución de llamada. Puedes usar tanto un webhook como notificaciones de canal en el mismo monitor.

Ejemplos

Solo correo electrónico:
Devolución de llamada de webhook:
SMS:

Política de fuente

Usa source_policy para restringir qué URLs y dominios puede usar el planificador.

Frecuencias

Configura frequency en lenguaje natural, por ejemplo:
  • every hour (por defecto si se omite)
  • every day at 9am
  • every weekday at 14:30
Reglas:
  • Debe leerse como lenguaje de programación de horarios (no una pregunta arbitraria del monitor).
  • Intervalo mínimo: cada 10 minutos.
  • Los horarios se almacenan y ejecutan en UTC (schedule.timezone es UTC).
  • Longitud máxima: 50 caracteres.
La API deriva una expresión cron de tu texto frequency y la expone en schedule.cron. Cuando el monitor está active, schedule.next_run_at muestra la siguiente ejecución en ISO 8601.

Listar monitores

Recupera todos los monitores para tu equipo con GET /v1/monitors. Por defecto, los monitores eliminados se filtran. Usa ?include_deleted=true para incluirlos.

Forma de la respuesta

Obtener un monitor

Recupera un único monitor con GET /v1/monitors/:monitor_id. La respuesta incluye last_run (resumen de la última instantánea) y total_count (conteo de instantáneas) a menos que pases include_total_count=false. Agrega include-diagram=true para incluir un mermaid_diagram del DAG del monitor.

Forma de la respuesta

Listar eventos del monitor

Usa GET /v1/monitors/:monitor_id/events para listar eventos de instantáneas para un monitor. Paginación:
  • limit (por defecto 25, máximo 100)
  • cursor (token opaco de next_cursor)
  • count_only=true devuelve solo { "total_count": N }
Los eventos se devuelven del más nuevo al más antiguo. Cada elemento incluye una snapshot_url pre-firmada de corta duración.

Forma de la respuesta

Obtener planificación del monitor

Usa GET /v1/monitors/:monitor_id/planning para inspeccionar la especificación del flujo de trabajo FDA y el DAG del planificador después del aprovisionamiento.

Obtener una ejecución del monitor

Usa GET /v1/monitors/:monitor_id/runs/:run_id para obtener metadatos de instantáneas y eventos de registro de agentes analizados para una ejecución (run_id debe comenzar con run_).

Transmitir registros de agentes

Usa GET /v1/monitors/:monitor_id/agent-logs?stream=1 (o Accept: text/event-stream) para seguir los registros de CloudWatch para el agente del monitor, filtrados a este monitor_id. El parámetro de consulta opcional since es una marca de tiempo en milisegundos (por defecto: hace 30 minutos). Tipos de eventos SSE: ready, log, heartbeat, error.

Actualizar un monitor

Actualiza un monitor con POST /v1/monitors/:monitor_id. Campos soportados (incluye solo lo que deseas cambiar):
  • metadata — se fusiona con las claves existentes; los valores de cadena vacíos eliminan claves
  • frequency — recrea el horario interno y establece status de nuevo a active
  • notification — reemplaza todo el objeto de notificación
  • webhook — pasa null para eliminar
Devuelve 409 mientras status es provisioning. Cuando agregas notification.channels sin events, la API establece events por defecto a ["changed", "first_snapshot"].

Agregar notificación por correo electrónico

Agregar webhook

Pausar un monitor

Pausa un monitor con POST /v1/monitors/:monitor_id/pause. Pausar desactiva el horario subyacente y establece status en paused. Solo los monitores con status: active pueden ser pausados. El cuerpo de la solicitud está vacío.
En caso de éxito, devuelve 200 con el monitor y status: paused. schedule.next_run_at es null mientras está pausado.

Reanudar un monitor

Reanuda un monitor pausado con POST /v1/monitors/:monitor_id/resume. Reanudar vuelve a habilitar el horario y establece status de nuevo a active. Solo los monitores paused pueden ser reanudados.

Eliminar un monitor

Elimina un monitor con DELETE /v1/monitors/:monitor_id. La eliminación elimina suavemente la fila del monitor (status: deleted) y elimina sus recursos de horario y agente sombra.

Estado del monitor

Ejemplos de casos de uso

A continuación se presentan patrones comunes de monitores. Cada ejemplo solo necesita query y frequency en el momento de la creación; agrega notification y webhook más tarde si deseas alertas en la primera ejecución o en cambios.

Nuevos lanzamientos de Y Combinator

Observa Y Combinator Launches para startups recién publicadas. Después de la planificación, tracked.type es urls y tracked.urls apunta a la página de lanzamientos.
Agrega entrega por correo electrónico y webhook después de que el monitor esté active:
Con channels configurado y events omitido, la API establece por defecto ["changed", "first_snapshot"] para que seas notificado en la ejecución de referencia y cada vez que se detecte un cambio.

Publicaciones de blog de competidores (AirOps, Profound)

Monitorea el índice de blogs de un competidor para nuevas publicaciones. El planificador resuelve tracked.urls a la URL del blog (por ejemplo, https://www.airops.com/blog o https://www.tryprofound.com/blog).
Después de la creación, un monitor de esta familia se ve así:
Usa events: ["changed"] en notification si solo deseas alertas cuando aparezcan nuevas publicaciones, no en la primera instantánea de referencia.

Umbral de precio de acciones (Tesla)

Monitorea una fuente de datos estructurada cuando la condición es numérica en lugar de una diferencia de página. El planificador establece tracked.type en data_api y deja tracked.urls vacío.

Registro de cambios de la API de OpenAI

Recibe notificaciones cuando el registro de cambios de la API de OpenAI lista nuevas características, lanzamientos de modelos o deprecaciones. Menciona la URL del registro de cambios en query o fíjala con source_policy.include_urls.
Configura events a ["changed"] para que te alerten cuando el contenido del registro de cambios cambie, no solo cuando se almacene la primera instantánea.

Gestión de múltiples monitores

Lista cada monitor para tu equipo para ver el estado, los horarios y los objetivos resueltos en un solo lugar:
Un equipo que ejecute los ejemplos anteriores podría ver varios monitores uno al lado del otro: observaciones de blogs en diferentes cadencias, una observación de precio data_api, y un monitor de lanzamientos de YC con correo electrónico y webhook configurados, con "count": 4 (o más) en la respuesta.

Errores comunes de validación

Los endpoints del monitor devuelven errores de validación claros para solicitudes inválidas comunes:
  • query faltante o vacía
  • frequency que no es lenguaje de programación de horarios, se resuelve demasiado a menudo (menos de 10 minutos) o excede los 50 caracteres
  • Entradas inválidas de source_policy (las matrices de URL deben contener cadenas válidas http/https)
  • Forma inválida de notification, events desconocidos o type / target de canal inválido
  • webhook.url inválido (debe ser http o https)
  • output_schema inválido (debe ser un JSON Schema válido)
  • Formato inválido de monitor_id o run_id
  • Actualización mientras status es provisioning (409)
  • Pausar/reanudar cuando el estado no es active / paused
Ejemplo de error: