Мониторинг изменений сайта через API

Мониторинг изменений сайта через API позволяет регулярно проверять важную страницу и получать событие только тогда, когда её содержимое действительно изменилось. В LLMTOKENAPI монитор создаётся один раз через POST /v1/monitors: сервис делает снимки по расписанию, сравнивает очищенный текст, хранит историю запусков и отправляет monitor.changed через настроенный webhook.

Когда нужен монитор, а когда — синхронизация

Монитор подходит для узкой задачи: заметить изменение конкретного публичного URL. Типичные примеры — страница тарифов поставщика, условия программы, расписание, документация метода или карточка товара. Результат проверки отвечает на вопрос «изменилась ли наблюдаемая область?» и может запустить следующий шаг вашей автоматизации.

Синхронизация базы знаний решает другую задачу: обходит набор страниц и обновляет поисковый индекс, чтобы AI-ассистент отвечал по свежей версии сайта. Если нужно автоматически переиндексировать документацию целиком, используйте Website Knowledge Sync. Если достаточно отследить одну страницу и решить, что делать дальше, монитор будет проще и дешевле по числу операций.

Не объединяйте эти сценарии искусственно. Событие монитора может запускать выборочный fetch, Web Intelligence или внутренний процесс согласования, но само по себе оно не означает, что новая версия уже проверена и помещена в RAG.

Выберите устойчивый URL и область страницы

Начните с канонического публичного HTTP- или HTTPS-адреса. Не используйте URL личного кабинета, страницы с одноразовой сессией или ресурсы, доступ к которым зависит от браузерной авторизации. Монитор работает с публичным ответом сервера и не должен обходить ограничения сайта.

По умолчанию сравнивается очищенный текст всей страницы: служебные script и style, HTML-теги и лишние пробелы не участвуют в сравнении. Это уменьшает шум от оформления. Но на динамических страницах всё равно могут меняться дата, рекламный блок, рекомендации или счётчик. Тогда задайте CSS-селектор и следите только за смысловой областью — например main, .pricing-table или [data-doc-content].

Селектор должен быть устойчивым. Класс, который сборщик сайта меняет при каждом build, быстро сломает проверку. Предпочитайте семантический контейнер или специально добавленный атрибут. После изменения шаблона сайта проверяйте, что выбранная область всё ещё содержит ожидаемый текст.

Создайте монитор через API

Для создания нужен API-ключ со scope monitors:write. Минимальный интервал — 15 минут, максимальный — 43 200 минут; если поле не передать, используется 60 минут. Имя помогает отличать правила в списке и журналах.

curl https://api.llmtokenapi.ru/v1/monitors \
  -H "Authorization: Bearer $LLMTOKENAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/pricing",
    "name": "Тарифы поставщика",
    "intervalMinutes": 60,
    "selector": "main"
  }'

Успешный ответ возвращает идентификатор, URL, имя, интервал, селектор, статус и время следующей проверки. Сохраните id: он нужен для чтения истории, паузы, изменения параметров и удаления монитора. Текущий контракт методов можно сверить в официальной OpenAPI-схеме LLMTOKENAPI.

Первый запуск создаёт базовый снимок. Он ещё не считается изменением, потому что сравнивать его не с чем. Событие monitor.changed появляется после последующей проверки, если хеш очищенного содержимого отличается от предыдущего.

Читайте состояние и историю запусков

Для чтения используйте ключ со scope monitors:read:

• GET /v1/monitors возвращает все мониторы организации;
• GET /v1/monitors/{id} показывает текущее правило и расписание;
• GET /v1/monitors/{id}/runs возвращает последние проверки;
• query-параметр limit ограничивает историю от 1 до 100 записей.

В записи запуска доступны признак changed, HTTP-статус, безопасное описание ошибки и время. Этого достаточно, чтобы построить панель состояния или периодическую сверку. Снимки хранятся зашифрованно; публичный API не превращает монитор в архив произвольных страниц.

Отличайте изменение от сбоя. Недоступность URL, тайм-аут или ошибочный селектор требуют диагностики, но не означают, что наблюдаемый факт изменился. Автоматизация должна иметь отдельные ветки для monitor.changed и monitor.failed.

Получайте события через webhook

Создайте webhook endpoint, подписанный на monitor.changed и при необходимости monitor.failed. После обнаружения изменения событие содержит идентификатор монитора, идентификатор запуска, статус и время проверки. По runId и API можно сопоставить событие с историей.

Webhook считайте уведомлением, а не единственным хранилищем состояния. Обработчик должен быстро проверить подпись, зафиксировать идентификатор события и вернуть успешный HTTP-ответ. Тяжёлую обработку переносите в очередь. Повторная доставка не должна повторно создавать задачу или отправлять клиенту несколько одинаковых сообщений. Подробная схема подписи и защиты от повторов есть в руководстве Webhook для AI API.

После события можно:

1. получить страницу через fetch или contents;
2. выделить изменившиеся факты в своём приложении;
3. запустить исследование с источниками;
4. отправить изменение на ручное согласование;
5. обновить базу знаний только после проверки.

Не публикуйте автоматически любое замеченное значение. Для цены, юридического условия или статуса услуги полезна вторая проверка: валидность HTTP-ответа, наличие ожидаемого элемента и сопоставление с предыдущим значением.

Управляйте расписанием без потери истории

PATCH /v1/monitors/{id} меняет URL, имя, интервал, селектор или статус. Значение paused останавливает новые проверки, а active возвращает монитор в работу. Пауза удобна во время обслуживания сайта или разбора ложных срабатываний: правило остаётся доступным, и его не нужно создавать заново.

Удаляйте монитор через DELETE только когда он больше не нужен. Если меняется назначение наблюдения — например, вместо тарифов вы начинаете отслеживать юридические условия, — лучше создать отдельный монитор с ясным именем. Так история двух разных бизнес-сигналов не смешается.

Снижайте шум и измеряйте надёжность

Для начала выберите несколько критичных страниц, а не весь сайт. На каждой проверьте три сценария: содержимое не меняется, целевой блок изменился, страница временно недоступна. Убедитесь, что система создаёт событие только во втором случае и отдельный сигнал сбоя — в третьем.

Следите за долей успешных проверок, числом полезных изменений, ложными срабатываниями и временем от обновления страницы до события. Если уведомлений слишком много, сузьте селектор или увеличьте интервал. Если изменение обнаруживается слишком поздно, уменьшайте интервал только для действительно важных URL.

Полный список методов, scopes и правила работы с API-ключом доступны в документации LLMTOKENAPI. Хороший мониторинг — это не частый запрос ради частоты, а устойчивое правило, которое отделяет содержательное изменение от фонового шума и безопасно запускает следующий шаг.