- 변화 이벤트는 프롬프트의 답변이 바뀔 때
webhookUrl로 갑니다. 내 브랜드가 나타나거나 사라질 때, 경쟁사가 앞설 때, 사이트가 처음 인용될 때입니다. - 알림은 최근 7일 브랜드 언급률이
alertBelowPct아래로 떨어지면 계정 관리자에게 이메일을 보냅니다.
변화 이벤트
모니터를 만들 때나 수정할 때webhookUrl을 설정하세요.
400 VALIDATION_ERROR를 반환합니다. webhookUrl: null은 이벤트를 끄고 모니터의 이벤트 상태를
버립니다. 다시 켜면 이력에서 시작합니다.
이벤트 유형
브랜드 이벤트는 프롬프트를 엔진별로, 그리드 모니터에서는 지점별로 따로 추적합니다. 상태는 최근 답변 5개로 읽으므로
samples: 5이면 실행 한 번으로 상태가 채워집니다.
- 이벤트는 상태가 바뀔 때 한 번 보냅니다. 답변에서 계속 빠져 있는 브랜드는
monitor.mention.stopped를 한 번 보내고, 돌아올 때까지 더 보내지 않습니다. - 프롬프트는 답변 5개가 쌓이면 상태가 생깁니다. 그 첫 상태가 기준이 되며 아무것도 보내지 않습니다.
- 카테고리 모니터는 자체 브랜드가 없으므로
monitor.source.first_cited만 보냅니다.
- 이미 답변이 있는 모니터에
webhookUrl을 켤 때: 각 프롬프트의 상태를 최근 30일 중 마지막 답변 5개로 다시 만들고, 이미 인용된 모든 도메인을 알려진 도메인으로 셉니다. 이벤트는 다음 답변부터 시작됩니다. webhookUrl과 함께 모니터를 만들거나, 답변이 생기기 전에 켤 때: 첫 실행이 알려진 도메인을 정하고,monitor.source.first_cited는 그 실행이 모두 제출된 뒤에 만들어진 태스크의 답변부터 셉니다. 브랜드 이벤트는 프롬프트에 답변 5개가 쌓이면 시작됩니다.
페이로드
각 이벤트는 JSON 본문의POST입니다. 예를 들면 다음과 같습니다.
서명과 재시도
이벤트는 태스크 웹훅과 같은 방식으로 서명하고 재시도합니다. 같은 세 가지querying-webhook-* 헤더, 같은 HMAC-SHA256
방식, 같은 재시도 일정입니다. 웹훅의 코드로 검증하세요. 두 가지가 다릅니다.
querying-webhook-id는 이벤트id입니다. 이 값으로 중복을 거르세요.- HMAC 키는 태스크의 키가 아니라
webhookUrl을 설정한 API 키의 SHA-256 다이제스트입니다.
webhookUrl을 다시 보내면 이후 이벤트는 새 키로 서명합니다. webhookUrl을 설정한 키가 폐기되거나
만료되면 이벤트가 멈춥니다. 각 이벤트는 delivery.lastError에 이유를 담아 failed로 표시되며, 서명 없이 보내는 일은
없습니다.
이벤트 목록과 다시 보내기
GET /v1/monitors/{id}/events(레퍼런스)는 이벤트를 최신순으로 나열합니다.
응답에는
webhookUrl, nextCursor(마지막 페이지에서 null), events가 있습니다. 각 이벤트에는 id, type,
createdAt, data(페이로드와 같음), delivery가 있습니다.
POST /v1/monitors/{id}/events/{eventId}/redeliver
(레퍼런스)는 이벤트 하나를 현재 webhookUrl로 지금 다시 보내고, 재시도를
처음부터 세며, 갱신된 delivery와 함께 이벤트를 반환합니다. 이미 전달된 이벤트도 다시 보낼 수 있습니다. 모니터에
webhookUrl이 없으면 409 WEBHOOK_NOT_SET, 알 수 없는 이벤트는 404 NOT_FOUND를 반환합니다.
이벤트는 30일 동안 보관합니다. 재시도 중인 이벤트는 재시도가 끝날 때까지 보관합니다.
알림
브랜드 모니터에alertBelowPct(1–100의 정수 퍼센트)를 설정하면 브랜드 언급률이 그 아래로 떨어질 때 이메일을 받습니다.
- 기간: 모니터의 모든 프롬프트와 엔진에 걸친 최근 7일의 채점된 답변. 리포트의 기본값인 30일은 경고하기에는 너무 느리게 움직입니다.
- 시점: 예약 실행이 시작될 때마다. 이미 채점된 답변을 읽으므로 이전 실행들을 반영합니다.
- 최소 표본: 기간의 채점된 답변이 5개 미만이면 발송하지 않습니다. 새 모니터나 엔진이 실패 중인 모니터는 조용합니다.
- 상태가 아니라 교차: 비율이 임계값 아래이고 알림이 활성 상태이면 발송한 뒤 비활성화합니다. 비율이 임계값 이상으로
돌아오면 다시 활성화되므로, 계속 낮은 모니터는 실행마다가 아니라 한 번만 이메일을 보냅니다.
alertBelowPct를 바꾸면 다시 활성화됩니다.
alertBelowPct를 400 VALIDATION_ERROR로 거절합니다.
alertBelowPct: null은 알림을 끕니다.
알림 이력
GET /v1/monitors/{id}/alerts(레퍼런스)는 alertBelowPct, armed,
deliveries(테스트를 포함한 모니터의 최근 알림 이메일 20건)를 반환합니다. 각 전달에는 id, status(pending, sent,
failed), attempts, createdAt, sentAt, lastError, payload(monitorId, name, ratePct, threshold,
windowDays, runs)가 있습니다. 전달 기록은 90일 동안 보관합니다.
테스트 알림 보내기
POST /v1/monitors/{id}/alerts/test(레퍼런스)는 실제 알림과 같은 전달 경로로
모니터 이름 뒤에 “(test)“를 붙인 테스트 이메일을 큐에 넣고 data.queued: true를 반환합니다. 결과는 알림 이력에서
확인하세요. 테스트 이메일은 모니터당 5분에 3번까지 보낼 수 있고, 넘으면 429 RATE_LIMITED를 반환합니다. 카테고리 모니터는
400 VALIDATION_ERROR를 반환합니다.
다음 단계
웹훅
모든 웹훅의 서명, 재시도, 안전한 핸들러.
출처와 답변
이벤트 뒤의 답변을 엽니다.