웹훅 & 트리거

트리거는 Letaido가 다른 앱에서 무언가가 발생했음을 실시간으로 감지하는 방법으로, 계속 확인할 필요가 없습니다.

HubSpot에 새로운 연락처가 등록되거나, Slack에서 누군가 @멘션을 하거나, 거래 단계가 이동할 때, 레타이두는 즉시 이를 파악하고 행동합니다.

이것으로 할 수 있는 일

팀이 여기서 설정하는 항목은 다음과 같습니다:

HubSpot 연락처가 MQL이 되면, ICP 기준으로 점수를 매기고 결과를 #mql-review에 게시합니다.
#pmm-questions에서 누군가 Slack 봇을 @멘션하면, 브랜드 보이스로 답변합니다.
Linear 이슈에 customer-facing 라벨이 지정되면, 한 단락 분량의 공개 요약을 작성하여 PMM 리드에게 DM으로 전송합니다.
GitHub 릴리스가 게시되면, 출시 이메일을 자동으로 초안 작성하여 검토를 위해 Notion으로 전송합니다.
Fathom 회의가 종료되면, 실행 항목을 추출하여 Linear에 추가합니다.
Apify 스크래퍼가 완료되면, 파이프라인의 다음 단계를 시작합니다.

트리거와 액션을 평범한 영어로 설명하시면 됩니다. 에이전트가 연결을 설정하고, 한 번 승인을 요청한 후, 자동으로 실행됩니다.

내부 작동 원리

두 가지 유형이 있습니다:

커넥터 트리거(권장). 서드파티 서비스에 대한 타입이 지정된 구독입니다. 설정은 한 번의 호출로 완료됩니다. 플랫폼이 구독, 서명 시크릿, 재시도 로직 및 이벤트 큐를 처리합니다. 이벤트는 알려진 스키마(Slack, GitHub, Linear, HubSpot, Fathom, Apify 등)와 함께 도착합니다.
임시 웹훅. 아직 내장 커넥터 트리거가 없는 서비스의 경우, 에이전트가 일반 웹훅 URL을 생성하고, 서드파티가 해당 URL로 POST하도록 구성한 다음, 동일한 큐로 이벤트를 가져옵니다. 서드파티가 보내는 스키마를 그대로 사용하므로 파싱 작업이 조금 더 필요합니다.

어느 쪽이든 에이전트가 적합한 것을 선택합니다. 사용자가 선택하는 것이 아닙니다.

이벤트 흐름 방식

타사 서비스가 플랫폼이 소유한 공개 URL로 POST합니다.
플랫폼은 서명을 검증하고, 페이로드를 파싱하며, 이를 보강합니다(예: Slack의 채널 ID를 이름으로 변환). 그런 다음 내부 큐에 푸시합니다.
소비자(앱, 작업 또는 채팅 에이전트)가 명명된 커서로 큐를 폴링하고 이벤트를 처리합니다.
각 이벤트는 처리 후 확인됩니다. 확인되지 않은 이벤트는 소비자가 중단될 경우 재전송됩니다.

커서는 소비자별로 관리되므로, 콘솔 앱과 작업이 서로 간섭하지 않고 동일한 이벤트를 감시할 수 있습니다.

신뢰성 모드 vs 자동 확인 모드

자동 확인(기본값). 이벤트를 읽으면 즉시 큐에서 사라집니다. 간단합니다. "피드를 추적하여 테이블에 기록"하는 경우에 적합합니다.
수동 확인. 이벤트를 읽고 처리한 다음 명시적으로 확인합니다. 처리 중 충돌이 발생하면 이벤트가 다시 전달됩니다. 부수 효과(이메일, 데이터베이스 쓰기, 다운스트림 API 호출)를 잃어서는 안 될 때 사용합니다.

에이전트에게 "신뢰할 수 있는 워크플로"를 요청하면 기본적으로 수동 확인을 선택합니다.

일반적인 요청 형태

"HubSpot에서 라이프사이클 단계가 marketingqualifiedlead인 새 연락처가 생성되면, 해당 회사를 ICP 기준으로 평가하고 결과를 #mql-review에 게시합니다."

에이전트: 1. HubSpot 연락처 생성 트리거를 구독합니다. 2. 이벤트를 가져와서 ICP 스코어러를 호출하고 Slack 커넥터를 통해 Slack에 게시하는 작은 컨슈머(콘솔 앱 또는 작업)를 작성합니다. 3. 해당 서피스를 처음 사용하는 경우 HubSpot 구독 승인과 Slack 승인을 모두 표시합니다.

"GitHub 이슈에 pmm-review 라벨이 지정되면, 고객 대상 요약을 한 단락으로 작성하여 DM으로 보내주세요."

"누군가 #pmm-questions에서 Slack 봇을 @멘션하면, 브랜드 보이스 스킬을 사용하여 답변합니다."

워크스페이스에서 볼 수 있는 것

활성 구독마다 다음 정보가 표시됩니다: - 커넥터 및 이벤트 유형. - 서명 비밀 상태. - 공개 URL(임시용) 또는 타사 앱 구성(커넥터 트리거용). - 큐를 읽는 컨슈머.

워크스페이스 UI에서 구독을 일시 중지하거나 취소할 수 있습니다. 취소하면 이후 인바운드 POST 요청에 대해 410을 반환합니다.

제한 사항 및 엣지 케이스

어떤 이벤트도 "채팅에서 팬아웃"되지 않습니다. 트리거는 서버 기반입니다. 채팅 세션이 종료되어도 이벤트는 계속 도착하여 소비자가 읽을 때까지 큐에 쌓입니다.
큐에는 보관 기간이 있습니다. 며칠이 지난 읽지 않은 이벤트는 삭제됩니다. 소비자가 오프라인 상태였다고 의심되는 경우, 이벤트가 누락되었다고 가정하기 전에 확인하십시오.
공개 사이트 소비자는 추가 제한이 있습니다. 사이트 표면 트리거는 호출별 명시적 검토가 필요합니다(포괄 승인 없음). 방문자가 제어하는 흐름은 팬아웃 비용 위험이 있기 때문입니다.
서명 시크릿은 저장되며 표시되지 않습니다. 에이전트는 이를 사용할 수 있지만 다시 읽을 수는 없습니다.

내부 동작 방식. 인바운드 이벤트는 nginx → api-proxy → connectors service를 거칩니다. 서비스는 저장된 서명 시크릿에 대해 서명을 검증하고, 커넥터의 enrich 훅(예: Slack의 사용자 ID를 사용자 이름으로 변환하는 리졸버)을 실행한 다음, webhook_events에 행을 작성합니다. 소비자는 선택적 provider 및 ack 매개변수와 함께 GET /webhooks/events?cursor=<name>를 통해 가져옵니다. 수동 확인 소비자는 through_id와 함께 /webhooks/ack로 POST를 보냅니다.