API 레퍼런스

인증

테넌트, 엔드유저, proxy-mode API 접근을 위한 헤더 스킴.

자격 증명 유형

스킴헤더역할
Tenant API keyX-API-Key: tk_… (또는 Authorization: Bearer tk_…)당신의 테넌트
Proxy-mode end userX-API-Key: tk_… + X-End-User: <your-user-id>당신의 백엔드가 주장하는 특정 엔드유저
Platform end userAuthorization: Bearer <jwt>/auth/login 또는 OAuth로 로그인한 엔드유저

선택적인 X-Space-Id 헤더는 특정 스페이스를 선택합니다. 이것이 없으면 사용자의 기본 스페이스가 사용됩니다.

어떤 스킴이든 principal(tenant · user · space)로 해석되며, 데이터베이스 세션은 Postgres row-level security로 그 신원에 스코프됩니다 — 따라서 격리는 애플리케이션 코드가 아니라 API 아래에서 강제됩니다.

어떤 것을 써야 하나요?

  • 서버 대 서버 통합(당신의 제품이 대화를 구동): proxy mode를 사용하세요. 백엔드가 테넌트 키를 보유하고 요청마다 엔드유저 신원을 주장합니다 — 사용자는 키를 절대 보지 못합니다.
  • 사용자가 플랫폼에 직접 로그인하는 자체 클라이언트 앱: 엔드유저 JWT를 사용하세요.
  • 관리 자동화(문서, 에이전트, 사용량 관리): 관리 엔드포인트에 대해 평범한 테넌트 키를 사용하세요.

테넌트 API 키는 서버 측 secret입니다. 브라우저 코드나 모바일 앱에 절대 넣지 마세요 — 브라우저 시나리오에서는 share token으로 대신 인증하는 임베드 위젯을 사용하세요.

Proxy mode 예시

curl https://chat.agent4.io/chat \
  -H "X-API-Key: tk_live_…" \
  -H "X-End-User: crm-user-8841" \
  -H "Content-Type: application/json" \
  -d '{ "message": "What documents do I need for a refinance?" }'

엔드유저 id는 당신의 시스템에서 온 안정적인 식별자면 무엇이든 됩니다. 플랫폼은 처음 볼 때 사용자와 그들의 기본 스페이스를 생성하고, 모든 이력, 메모리, 문서를 그들에게 스코프합니다.

오류

상태의미
401자격 증명 누락 또는 무효
403유효한 신원이지만, 요청된 스페이스/에이전트에 대한 접근 권한 없음
429월 토큰 할당량 소진