Impri의 REST API를 사용하여 기본 HTTP Request 및 Wait 노드에서 n8n AI 에이전트 (AI Agent) 워크플로우를 위한 인간 승인 (Human Approval) 기능을 추가하세요 — 커스텀 노드도 필요 없고, 작은 Function 블록 하나 이상의 코드는 필요하지 않습니다.

워크플로우에서 게이트(Gate)가 위치하는 곳

전형적인 설정: Zendesk Trigger 노드가 새로운 티켓에 대해 실행되면, AI Agent 노드(n8n에 연결된 모델 기반)가 답장 초안을 작성하고, 마지막 노드가 일반적으로 그 답장을 고객에게 바로 게시합니다. 게이트를 설치할 가치가 있는 단계는 바로 그 마지막 단계입니다 — 그 이전의 모든 과정은 단순히 추론 과정일 뿐이며, 아직 외부로 아무것도 나가지 않았기 때문입니다.

해결책은 첫 번째 에이전트의 작업을 재확인하는 두 번째 AI Agent 노드를 추가하는 것이 아닙니다. 워크플로우가 진행되기 위해 반드시 거쳐야 하는 외부의 결정입니다: Impri가 초안을 보유하고, 사람이 승인(Approve) 또는 거절(Reject)을 누르면, 승인된 브랜치(Branch)만이 실제로 Zendesk API를 호출하는 노드에 도달하게 됩니다.

노드 패턴

다섯 개의 노드가 전체 루프를 구성합니다:

Authorization: Bearer im_<key>를 n8n의 Header Auth 자격 증명으로 한 번 설정하면 두 HTTP Request 노드 모두에서 재사용할 수 있습니다. actions 범위로 제한된 키만으로도 충분합니다 — 이 워크플로우에는 admin 권한이 전혀 필요하지 않습니다.

Code 노드에서 요청 생성하기

// AI Agent 노드 바로 뒤의 Code 노드
const ticket = $('Zendesk Trigger').item.json;
const draft = $input.item.json.output; // AI Agent 노드의 텍스트 출력
...

다음 노드의 HTTP Request 본문을 이 Code 노드의 {{ $json }}으로 지정하세요 — HTTP 노드 자체에서 수동으로 JSON을 빌드할 필요가 없습니다.

n8n 방식의 폴링 루프 (Polling Loop)

n8n에는 내장된 "완료될 때까지 폴링(poll until done)" 노드가 없으므로, 백 엣지(back-edge)를 사용하여 루프를 구축합니다: Wait (10s) → HTTP Request (GET status) → IF {{ $json.status === "pending" }} → true 브랜치가 다시 Wait 노드로 연결되고, false 브랜치가 다운스트림(Downstream)으로 계속 진행됩니다. 이는 docs/integrations.md의 n8n 섹션과 동일한 형태이며, 단지 노드별로 상세히 설명된 것뿐입니다.

지원 티켓 (support-ticket) 워크플로우의 경우, expires_in을 짧게(위와 같이 1시간 정도) 유지하세요. 하루가 지난 상용구 답변 (canned reply)은 보통 Zendesk에서 상담원이 직접 답변함으로써 이미 상황이 종료되었을 가능성이 높기 때문입니다.

결정 사항 읽기 (Reading the decision)

IF 노드의 False 분기(false branch)가 실행되면, 마지막 GET 응답에 결정 사항이 포함됩니다:

{
  "status": "approved",
  "decision": {
...

status를 기준으로 경로를 지정하세요: 오직 approved 경로만이 Zendesk의 "답변 게시 (post reply)" 노드에 도달하며, 이때 반드시 decision.final_preview.body를 읽어야 합니다. Code 노드의 원본 draft를 읽어서는 안 됩니다. 검토자가 승인하기 전에 문구를 다듬었을 수 있기 때문입니다.

웹훅 (webhook)을 사용하여 루프 건너뛰기

티켓 큐의 양이 적다면 10초마다 폴링 (polling) 하는 것도 괜찮지만, 만약 n8n 인스턴스에 공개 URL이 있다면 Code 노드의 JSON 내 callback_url을 n8n Webhook 노드의 URL로 설정하세요. Impri는 사람이 결정하는 즉시 해당 위치로 결정을 POST 합니다. 그러면 Wait/GET/IF 루프 전체를 두 번째 워크플로우를 시작하는 단일 Webhook 트리거로 대체할 수 있습니다. 해당 페이로드 (payload)에 대한 서명 검증 (Signature verification)은 webhooks.md에 문서화되어 있습니다.

이것이 대체할 수 없는 것

Impri는 승인 게이트 (approval gate)이지 워크플로우 엔진 (workflow engine)이 아닙니다. 분기 (branching), 재시도 (retries), 스케줄링 (scheduling)은 여전히 n8n의 역할입니다. Impri는 티켓을 읽거나 답변이 적절한지 판단하지 않습니다. 단지 초안을 사람에게 보여주고 그들이 결정한 내용을 기록할 뿐입니다. 또한, 이 게이트는 Zendesk API 자격 증명 (credential)이 "답변 게시" 노드에만 존재하고 워크플로우의 다른 곳에는 없을 때만 유효합니다. 만약 이전 노드에도 해당 자격 증명이 있다면, AI 에이전트의 출력이 Impri를 전혀 거치지 않는 경로를 통해 Zendesk에 도달할 수 있습니다.

다음 단계

Quickstart에서 시작하여 키를 발급받고 첫 번째 액션을 실행하거나, Integrations에서 정확한 n8n 참조 패턴을 확인하세요.