
언어 🇰🇷 한국어
API 리소스
인증
집계
AuditLog
배치 작업
댓글
이메일 템플릿
피드 게시물
해시태그
내 정보
모더레이터
알림 카운트
알림
페이지 반응
페이지
투표
투표 결과
보류 중인 웹훅 이벤트
SSO 사용자
구독
테넌트 일일 사용량
테넌트
테넌트 패키지
테넌트 사용자
사용자
도메인 설정
질문 설정
질문 결과
질문 결과 집계
사용자 배지
사용자 배지 진행
실시간 댓글 API
FastComments API
FastComments는 다양한 리소스와 상호 작용할 수 있는 API를 제공합니다. 우리 플랫폼과 통합을 구축하거나 직접 클라이언트를 만들 수도 있습니다!
이 문서에서는 API가 지원하는 모든 리소스를 요청 및 응답 유형과 함께 문서화한 내용을 찾을 수 있습니다.
엔터프라이즈 고객의 경우, 모든 API 접근은 감사 로그에 기록됩니다.
Generated SDKs
FastComments는 이제 코드에서 API Spec을 생성합니다(아직 완전하지 않지만 많은 API를 포함합니다).
또한 인기 있는 언어용 SDK도 제공됩니다:
- fastcomments-cpp
- fastcomments-go
- fastcomments-java
- fastcomments-sdk-js
- fastcomments-nim
- fastcomments-php
- fastcomments-php-sso
- fastcomments-python
- fastcomments-ruby
- fastcomments-rust
- fastcomments-swift
Authentication
API는 api key를 X-API-KEY 헤더 또는 API_KEY 쿼리 매개변수로 전달하여 인증합니다. API 호출을 위해 tenantId도 필요합니다. 이는 api key와 같은 페이지에서 확인할 수 있습니다.
Security Note
이 경로들은 서버에서 호출하도록 설계되었습니다. 브라우저에서 호출하지 마세요. 브라우저에서 호출하면 API 키가 노출되어 페이지 소스 코드를 볼 수 있는 누구든지 계정에 완전한 접근 권한을 얻게 됩니다!
Authentication Option One - Headers
- Header:
X-API-KEY - Header:
X-TENANT-ID
Authentication Option Two - Query Parameters
- Query Param:
API_KEY - Query Param:
tenantId
Authentication Option Three - OAuth Bearer Token
- Header:
Authorization: Bearer fcat_...
Zapier와 같은 서드파티 애플리케이션 및 MCP server 클라이언트는 API 키 대신 OAuth를 통해 토큰을 얻습니다. 해당 토큰은 여기의 모든 엔드포인트에서 작동합니다. 토큰에 테넌트가 내포되어 있으므로 tenantId는 선택 사항이지만 제공될 경우 토큰과 일치해야 합니다. GET 요청은 read 스코프가 필요하고, 다른 모든 메서드는 write 스코프가 필요합니다. 클라이언트 등록, PKCE, 토큰 갱신 및 폐기 등을 포함한 전체 흐름은 OAuth Authorization 아래에 문서화되어 있습니다. 발견은 https://fastcomments.com/.well-known/oauth-authorization-server에서 시작됩니다.
Reading Your Own Writes
FastComments는 Active-Active 가용성을 제공합니다. 데이터센터에서 오는 요청은 여러분에게 가장 가까운 point of presence로 라우팅됩니다. 이는 자동이며 일반적으로 읽기-쓰기 일관성을 관찰할 수 있습니다. 자신의 쓰기를 확실히 읽고 싶다면 해당 지역을 API 호스트로 사용하여 요청을 특정 지역에 고정할 수 있습니다(대부분의 통합에서는 보통 필요하지 않음):
- gdc-oregon.fastcomments.com
- gdc-virginia.fastcomments.com
- gdc-singapore.fastcomments.com
- gdc-falkenstein2.fastcomments.com
- gdc-sao-paulo.fastcomments.com
- eudc-helsinki2.fastcomments.com
- eudc-limburg.fastcomments.com
- eudc-france.fastcomments.com
이렇게 할 경우 과거에 엔트리포인트 노드가 폐기되고 전환을 위해 새로운 이름을 사용했으므로, 폴백을 정의하는 것이 좋습니다.
API 리소스 
리소스 사용량
API에서 데이터를 가져오는 것이 계정 사용량에 포함된다는 점에 유의하십시오.
각 리소스는 해당 사용량을 자체 섹션에 나열합니다.
일부 리소스는 다른 리소스보다 제공 비용이 더 많이 듭니다. 각 엔드포인트는 API 호출당 정해진 크레딧 비용을 가지고 있습니다. 일부 엔드포인트의 경우 옵션 및 응답 크기에 따라 크레딧 수가 달라집니다.
API 사용량은 Billing Analytics 페이지에서 확인할 수 있으며 몇 분마다 업데이트됩니다.
주의!
Comment API에서 urlId에 전달할 값을 결정할 때 혼란을 줄이기 위해 먼저 Pages 문서를 읽어볼 것을 권장합니다.
웹훅
Webhook 구독에는 별도의 가이드가 있습니다. POST, GET 및 DELETE /api/v1/webhooks, 그리고 GET /api/v1/webhooks/sample-payloads는 Managing Subscriptions via API에서 문서화되어 있으며, 이벤트 페이로드는 Webhook Structures에서 확인할 수 있습니다.
OAuth 인증 
FastComments는 OAuth 2.1 인가 서버입니다. 애플리케이션은 하나의 FastComments 계정에 바인딩된 토큰을 발급받아 이 가이드의 모든 엔드포인트에서 API 키 대신 사용할 수 있습니다. Zapier 앱, MCP 서버 및 기타 서드파티 통합이 이 방식으로 연결됩니다.
토큰은 PKCE가 적용된 인가 코드 플로우를 통해 발급됩니다. 클라이언트 자격 증명(client credentials) 또는 암시적(implicit) 그랜트는 지원하지 않습니다.
디스커버리
엔드포인트 위치, 지원되는 그랜트, 인증 방식은 표준 메타데이터 URL에서 확인할 수 있습니다:

해당 메타데이터가 설명하는 엔드포인트:

EU 리전의 계정은 동일한 경로로 https://eu.fastcomments.com를 issuer로 사용합니다.
클라이언트 등록
클라이언트는 플로우를 시작하기 전에 client_id와 등록된 redirect_uri가 필요합니다. 두 가지 방법이 있습니다:
- 동적 클라이언트 등록(Dynamic Client Registration). RFC 7591에 따라 JSON 본문(
redirect_uris,client_name,client_uri,logo_uri,token_endpoint_auth_method)과 함께POST /oauth/register를 호출합니다. 응답에는client_id가 포함되며, 기밀(confidential) 클라이언트의 경우client_secret도 포함됩니다. 등록은 인증 없이 수행되며 IP별로 요청이 제한됩니다. - 클라이언트 ID 메타데이터 문서(Client ID Metadata Document). 클라이언트가 자신이 제어하는
httpsURL을client_id로 사용합니다. FastComments가 해당 URL을 가져와 동일한 메타데이터 필드를 읽습니다. 별도의 등록 호출이 필요하지 않습니다.
Zapier 등 FastComments 대시보드에 나열된 파트너 애플리케이션은 FastComments가 직접 등록합니다. 마켓플레이스 등록 항목을 만들고 자사(first-party) 클라이언트가 필요한 경우 지원팀에 문의하세요.
스코프

스코프를 지정하지 않은 요청은 두 스코프가 모두 부여됩니다. 사용자는 동의 페이지에서 요청된 스코프를 확인합니다. 이 두 가지 이외의 스코프를 요청하면 invalid_scope 오류로 실패합니다.
1단계 - 인가 요청
사용자의 브라우저를 authorize 엔드포인트로 보냅니다. S256 방식의 PKCE는 모든 클라이언트에 필수입니다.


필요한 경우 사용자가 FastComments에 로그인한 뒤, 애플리케이션 이름, 연결될 계정, 요청된 스코프가 표시된 동의 페이지를 보게 됩니다. 사용자는 해당 계정에서 API Admin 권한을 보유해야 하며, 그렇지 않은 사용자는 동의 폼 대신 권한 오류를 보게 됩니다. 승인하면 code와 state와 함께 브라우저가 redirect_uri로 리다이렉트됩니다. 거부하면 error=access_denied와 함께 리다이렉트됩니다.
인가 코드는 10분간 유효하며 한 번만 교환할 수 있습니다. 동일한 코드를 두 번째로 교환하면 첫 번째 교환에서 발급된 모든 토큰이 취소됩니다.
2단계 - 토큰 요청
코드를 토큰으로 교환합니다. 본문은 form 인코딩입니다. 기밀 클라이언트는 client_secret_basic(HTTP Basic) 또는 client_secret_post(본문에 시크릿 포함)로 인증합니다. 퍼블릭 클라이언트는 client_id만 전송합니다.



오류는 RFC 6749를 따릅니다: error와 error_description이 포함된 JSON 본문이며, invalid_request, invalid_grant, invalid_scope, invalid_target, unsupported_grant_type은 HTTP 400, invalid_client는 HTTP 401, 요청 제한 시에는 HTTP 429가 반환됩니다.
3단계 - API 호출
액세스 토큰을 bearer 토큰으로 전송합니다. 테넌트는 토큰에 의해 암시되므로 tenantId는 선택 사항입니다. 전달하는 경우 토큰과 일치해야 하며, 그렇지 않으면 요청이 실패합니다.

GET /api/v1/me는 테넌트, 인가한 사용자, 부여된 스코프를 반환하므로 연결 테스트에 적합한 호출입니다. 만료되었거나 취소된 토큰이 포함된 요청은 HTTP 401을 받습니다. 토큰이 보유하지 않은 스코프가 필요한 메서드의 요청은 HTTP 403을 받습니다.
4단계 - 갱신


응답은 코드 교환과 동일한 형태입니다. 리프레시 토큰은 로테이션됩니다: 각 갱신은 새로운 refresh_token을 반환하며, 동시 요청을 위한 30초 유예 기간 후 이전 토큰을 취소합니다. 30초 이상 전에 로테이션된 리프레시 토큰을 제시하면 재생(replay)으로 간주되어 전체 그랜트가 취소됩니다. FastComments가 등록한 파트너 애플리케이션은 로테이션에서 제외되며, 만료일이 30일 연장된 동일한 리프레시 토큰을 받게 됩니다.
갱신 시 인가한 사용자가 여전히 해당 계정에서 API Admin 권한을 보유하는지도 다시 확인합니다. 그렇지 않은 경우 그랜트가 취소되고 응답은 invalid_grant입니다.
취소

리프레시 토큰을 취소하면 동일한 그랜트에서 발급된 모든 액세스 토큰이 취소됩니다. 액세스 토큰을 취소하면 해당 토큰만 취소됩니다. 이 엔드포인트는 RFC 7009에 따라 토큰 발견 여부와 관계없이 빈 JSON 객체와 함께 HTTP 200을 반환합니다.
사용자는 FastComments 대시보드의 Connected Apps에서 연결을 취소할 수도 있습니다. 해당 애플리케이션의 모든 토큰은 즉시 작동이 중지됩니다.
데이터 집계 
이 API는 문서를 그룹화(groupBy가 제공된 경우)하고 여러 연산을 적용하여 집계합니다. 다양한 연산(예: sum, countDistinct, avg 등)을 지원합니다.
비용은 가변적입니다. 스캔된 객체 500개마다 API 크레딧 1개가 소모됩니다.
기본적으로 각 API 호출에 허용되는 최대 메모리 사용량은 64MB이며, 기본적으로 동시에 하나의 집계만 실행할 수 있습니다. 여러 집계를 동시에 제출하면 제출된 순서대로 큐에 들어가 실행됩니다. 대기 중인 집계는 최대 60초 동안 대기하며, 그 이후에는 요청이 타임아웃됩니다. 개별 집계는 최대 5분 동안 실행될 수 있습니다.
관리되는 테넌트가 있는 경우 parentTenantId 쿼리 파라미터를 전달하여 한 번의 호출로 모든 하위 테넌트 리소스를 집계할 수 있습니다.
예제
예제: 고유 값 세기


예제: 고유 값 개수 세기

응답:

예제: 여러 필드 값 합계

응답:

예제: 여러 필드 값 평균

응답:

예제: 여러 필드의 최소/최대 값

응답:

예제: 여러 필드의 고유 값 세기

응답:

예제: 쿼리 생성 예제

응답:

예제: 검토 대기 댓글 수 세기

응답:

예제: 승인, 검토 및 스팸 댓글 분류

응답:

구조


다음 리소스들을 집계할 수 있습니다:
- AffiliateEvent
- AnonymousVote
- BannedUser
- BatchJob
- BlockedUser
- Comment
- CommentDeleted
- CommentIdToSyncOutbound
- CommentScheduled
- CommentSyncLog
- CustomConfig
- CustomEmailTemplateRenderError
- EmailToSend
- EventLogEntry
- ImportedCommentScheduled
- ModerationGroup
- Moderator
- Page
- PageReact
- PendingVote
- QuestionResult
- SSOUser
- SentEmail
- SpamEvent
- Tenant
- TenantAuditLog
- TenantBadge
- TenantDailyUsage
- TenantInvoiceHistory
- TenantPackage
- User
- UserBadge
- UserBadgeProgress
- UserNotification
- UserSubscription
- UserUsage
- Vote
AuditLog 구조 
AuditLog은 이 기능에 접근 권한이 있는 테넌트의 감사 이벤트를 나타내는 객체입니다.
AuditLog 객체의 구조는 다음과 같습니다:

targetId와 targetLabel은 이벤트가 수행된 대상을 설명하고; userId와 username은 누가 수행했는지를 설명합니다. 업데이트의 경우, objectDetails.changes는 실제로 변경된 내용을 {field: {from, to}} 형태의 맵으로 보유합니다.
감사 로그는 불변이며, 수동으로 기록할 수 없습니다. FastComments.com만이 감사 로그에 언제 기록할지를 결정할 수 있습니다. 그러나 이 API를 통해 로그를 읽을 수 있습니다.
감사 로그의 이벤트는 2년 후에 만료됩니다.
GET /api/v1/audit-logs 
이 API는 skip, limit, before, after 파라미터로 제공되는 페이지네이션을 사용합니다. AuditLog는 기본적으로 1000개씩 페이지로 반환되며, 최대 limit은 10000이고, when과 id 순으로 정렬됩니다. 이 엔드포인트는 대화형으로 페이지를 넘기는 용도보다는 주로 히스토리를 한 번에 덤프하는 용도로 사용되기 때문에 페이지 크기가 큽니다.
반환되는 로그 100개마다 크레딧 비용은 1입니다.
기본적으로 가장 최신 항목부터 목록을 받게 됩니다. 이렇게 하면 skip=0부터 폴링을 시작하여 마지막으로 소비한 레코드를 찾을 때까지 페이지네이션할 수 있습니다.
또는 가장 오래된 항목부터 정렬하여 더 이상 레코드가 없을 때까지 페이지네이션할 수도 있습니다.
정렬은 order를 ASC 또는 DESC로 설정하여 수행할 수 있습니다. 기본값은 DESC입니다.
날짜 기준 조회는 밀리초 단위 타임스탬프인 before와 after를 통해 가능합니다. before와 after는 포함되지 않으며(inclusive하지 않음), 둘 중 하나만 단독으로 사용할 수도 있습니다.
특정 사람에게 발생한 일 찾기
모든 이벤트는 수행한 사람(username, userId, ip)과, 별도로 수행 대상이 된 객체를 기록합니다. targetLabel은 해당 객체의 사람이 읽을 수 있는 라벨(예: jsmith (jsmith@example.com))이고, targetId는 그 id입니다. 사람의 이름이나 이메일은 알지만 id는 모를 때, 라벨에 대한 대소문자 구분 없는 부분 문자열 매칭을 위해 target을 사용하세요.
삭제 이벤트는 이벤트 시점의 라벨을 캡처하므로, 원본 레코드가 사라진 후에도 삭제된 사용자나 모더레이터를 식별할 수 있습니다.
관리되는 테넌트
귀하의 테넌트가 다른 테넌트를 관리하는 경우, includeManagedTenants=true로 설정하면 귀하의 테넌트와 관리하는 모든 테넌트의 이벤트를 하나의 응답으로 받을 수 있습니다. 반환된 각 로그의 tenantId를 통해 어떤 테넌트에서 온 것인지 알 수 있습니다.



BatchJob 구조 
A BatchJob은 가져오기, 내보내기 또는 페이지 마이그레이션과 같은 장기 실행 작업입니다. 작업은 대기열에 들어가며, 이후 백그라운드에서 가져와 실행됩니다.
processedCount와 totalCount는 진행 상황을 표시합니다. 단위는 type에 따라 달라집니다:
migrate-pages: 요청된 마이그레이션 중 완료된 마이그레이션 수.undo-page-migration: 복원된 레코드 수.totalCount는 없습니다.import,export및 기타 작업: 처리된 행 수.
BatchJob 객체의 구조는 다음과 같습니다:

재시도
페이지 마이그레이션 작업을 실행 중인 서버가 재시작하면, 작업은 대기열에 다시 들어가며 마지막으로 완료된 마이그레이션 이후부터 다시 진행됩니다. 작업은 최대 3번 시도되며, 그 이후에는 status가 failed가 됩니다.
GET /api/v1/batch-jobs 
이 라우트는 테넌트의 모든 유형의 배치 작업을 최신 순으로 반환하며, 페이지당 최대 100개를 제공합니다. 목록을 좁히려면 type 및 status를 사용하고, 페이지를 이동하려면 skip을 사용하세요.



GET /api/v1/batch-jobs/:id 
이 엔드포인트는 단일 배치 작업의 상태, 진행 상황 및 작업이 완료된 경우 결과를 반환합니다. POST /api/v1/pages/migrations 또는 POST /api/v1/pages/migrations/:undoId/undo 로 시작된 작업을 추적하는 데 사용하십시오.
작업은 status가 success 또는 failed일 때 완료됩니다. 각 호출은 1 크레딧이 소모되므로, 지속적으로 호출하기보다 몇 초 간격으로 폴링하십시오.




댓글 구조 
Comment 객체는 사용자가 남긴 댓글을 나타냅니다.
부모 댓글과 자식 댓글 간의 관계는 parentId를 통해 정의됩니다.
Comment 객체의 구조는 다음과 같습니다:

이 필드 중 일부는 READONLY로 표시되어 있습니다 - 이는 API에서 반환되지만 설정할 수 없습니다.
댓글 텍스트 구조
댓글은 FastComments 방식의 마크다운으로 작성되며, 이는 일반 마크다운에 [img]path[/img] 같은 이미지용 전통적인 bbcode 스타일 태그를 더한 것입니다.
텍스트는 두 필드에 저장됩니다. 사용자가 입력한 텍스트는 수정되지 않은 상태로 comment 필드에 저장됩니다. 이것이 렌더링되어 commentHTML 필드에 저장됩니다.
허용되는 HTML 태그는 b, u, i, strike, pre, span, code, img, a, strong, ul, ol, li, and br입니다.
HTML을 렌더링하는 것이 권장됩니다. 매우 작은 HTML 하위 집합이므로 렌더러를 만드는 것은 꽤 간단합니다. 예를 들어 React Native와 Flutter용으로 이를 도와주는 여러 라이브러리가 있습니다.
comment 필드의 정규화되지 않은 값을 렌더링하도록 선택할 수 있습니다. 예제 파서는 여기에 있습니다..
예제 파서는 HTML과 함께 작동하도록 조정하여 HTML 태그를 플랫폼에 맞는 렌더링 요소로 변환할 수도 있습니다.
태깅
댓글에서 사용자가 태그되면 해당 정보는 mentions라는 목록에 저장됩니다. 해당 목록의 각 객체는
다음과 같은 구조를 가집니다.
Run 
해시태그
해시태그가 사용되어 성공적으로 파싱되면 해당 정보는 hashTags라는 목록에 저장됩니다. 해당 목록의 각 객체는
다음과 같은 구조를 가집니다. retain이 설정된 경우, 쿼리용으로 댓글의 hashTags 배열에 해시태그를 수동으로 추가할 수도 있습니다.
Run 
GET /api/v1/comments 
이 API는 사용자에게 표시할 댓글을 가져오는 데 사용됩니다. 예를 들어, 승인되지 않았거나 스팸으로 표시된 댓글을 자동으로 필터링합니다.
페이지네이션
페이지네이션은 성능 요구 사항과 사용 사례에 따라 두 가지 방법 중 하나로 수행할 수 있습니다:
- 가장 빠름: 사전 계산된 페이지네이션(Precalculated Pagination):
- FastComments의 사전 빌드된 위젯과 클라이언트를 사용할 때 동작하는 방식입니다.
- "다음"을 클릭하면 단순히 페이지 수가 증가합니다.
- 키-값 저장소에서 가져오는 것으로 생각할 수 있습니다.
- 이 방식에서는
0부터 시작하는page매개변수와 정렬 방향으로direction을 정의하기만 하면 됩니다. - 페이지 크기는 커스터마이제이션 규칙을 통해 사용자 정의할 수 있습니다.
- 가장 유연함: 유연한 페이지네이션(Flexible Pagination):
- 이 방식에서는 사용자 정의
limit및skip매개변수를 정의할 수 있습니다.page를 전달하지 마세요. - 정렬
direction도 지원됩니다. limit은skip이 적용된 후 반환할 총 개수입니다.- 예:
page size = 100이고page = 2일 때skip = 200, limit = 100으로 설정합니다.
- 예:
- 자식 댓글도 페이지네이션에 포함됩니다.
asTree옵션을 사용하여 이를 우회할 수 있습니다.limitChildren및skipChildren을 통해 자식 댓글을 페이지네이션할 수 있습니다.maxTreeDepth를 통해 반환되는 스레드의 깊이를 제한할 수 있습니다.
- 이 방식에서는 사용자 정의
스레드
Precalculated Pagination을 사용할 때, 댓글은 페이지별로 그룹화되며 스레드의 댓글이 전체 페이지에 영향을 줍니다.- 이 방식에서는 클라이언트에서
parentId를 기반으로 스레드를 결정할 수 있습니다. - 예를 들어, 최상위 댓글 1개와 답글 29개가 있는 페이지에서 API에
page=0을 설정하면 최상위 댓글과 29개의 자식 댓글만 받게 됩니다.
- 이 방식에서는 클라이언트에서
Flexible Pagination을 사용할 때는parentId매개변수를 정의할 수 있습니다.- 최상위 댓글만 가져오려면 이 값을 null로 설정하세요.
- 그런 다음 스레드를 보려면 API를 다시 호출하고
parentId를 전달합니다. - 일반적인 해결책은 최상위 댓글에 대해 API를 호출한 다음, 각 댓글의 자식 댓글을 가져오기 위해 병렬로 API 호출을 수행하는 것입니다.
- 2023년 2월부터 새로 추가됨!
&asTree=true를 사용하여 트리 형태로 가져올 수 있습니다.- 이를
트리 형태의 유연한 페이지네이션이라고 생각할 수 있습니다. - 페이지네이션에는 최상위 댓글만 계산됩니다.
- 트리를 루트에서 시작하려면
parentId=null로 설정하세요 (parentId를 반드시 설정해야 합니다). - 페이지네이션을 위해
skip과limit을 설정합니다. asTree를true로 설정합니다.- 이 시나리오에서는 백엔드가 훨씬 더 많은 작업을 수행해야 하므로 크레딧 비용이
2배증가합니다. maxTreeDepth,limitChildren,skipChildren을 원하는 대로 설정합니다.
- 이를
트리 설명
asTree를 사용할 때는 페이지네이션을 이해하기 어려울 수 있습니다. 다음은 유용한 그림입니다:
사용자 컨텍스트에서 댓글 가져오기
/comments API는 서로 다른 사용 사례를 위해 두 가지 컨텍스트에서 사용할 수 있습니다:
- 자체 클라이언트를 구축하기 위한 정보로 정렬되고 태그가 지정된 댓글을 반환하는 경우.
- 이 경우
contextUserId쿼리 매개변수를 정의합니다.
- 이 경우
- 커스텀 통합을 위해 백엔드에서 댓글을 가져오는 경우.
contextUserId가 없으면 플랫폼은 기본적으로 이 컨텍스트를 사용합니다.




트리 형태로 댓글 가져오기
페이지네이션이 최상위 댓글만 계산하는 트리 형태로 댓글을 반환받을 수 있습니다.

최상위 댓글과 바로 아래 자식 댓글만 가져오고 싶으신가요? 다음은 한 가지 방법입니다:

하지만 UI에서 각 댓글에 "답글 보기" 버튼을 표시할지 여부를 알아야 할 수 있습니다. 트리 형태로 댓글을 가져올 때 해당되는 경우 댓글에 hasChildren 속성이 태그됩니다.
해시태그로 검색하여 트리 형태로 댓글 가져오기
API를 사용하여 전체 테넌트(한 페이지 또는 urlId에 국한되지 않음)에서 해시태그로 검색할 수 있습니다.
이 예제에서는 urlId를 생략하고 여러 해시태그로 검색합니다. API는 요청된 모든 해시태그가 포함된 댓글만 반환합니다.

모든 요청 매개변수

응답

유용한 팁
URL ID
Comment API를 urlId 매개변수와 함께 사용하는 것이 좋습니다. Pages API를 먼저 호출하여 사용 가능한 urlId 값이 어떤지 확인할 수 있습니다.
익명 작업
익명 댓글 작성의 경우 댓글을 가져올 때, 그리고 신고 및 차단을 수행할 때 anonUserId를 전달하는 것이 좋습니다.
(!) 많은 앱 스토어에서는 로그인하지 않은 사용자라도 볼 수 있는 사용자 생성 콘텐츠를 신고할 수 있어야 하므로 이 작업이 필수입니다. 이를 준수하지 않으면 앱이 해당 스토어에서 제거될 수 있습니다.
댓글이 반환되지 않는 경우
댓글이 승인되었는지, 스팸이 아닌지 확인하세요.
GET /api/v1/comments/:id 
이 API는 id로 단일 댓글을 가져오는 기능을 제공합니다.



POST /api/v1/comments 
이 API 엔드포인트는 댓글을 생성하는 기능을 제공합니다.
일반적인 사용 사례는 맞춤 UI, 통합 또는 가져오기입니다.
참고:
- 원하면 이 API는 댓글 위젯을 "라이브"로 업데이트할 수 있습니다 (이 경우
creditsCost가1에서2로 증가합니다). - 이메일이 제공되면 이 API는 자동으로 사용자 객체를 시스템에 생성합니다.
- 다른 이메일을 사용하지만 동일한 사용자 이름을 가진 두 댓글을 저장하려고 하면 두 번째 댓글에 대해 오류가 발생합니다.
- 만약
parentId를 지정하고 자식 댓글의notificationSentForParent가 false인 경우, 부모 댓글에 대한 알림을 전송합니다. 이 작업은 매 시간 수행됩니다(전송되는 이메일 수를 줄이기 위해 알림을 일괄 처리합니다). - 사용자를 생성할 때 환영 이메일을 보내거나 댓글 확인 이메일을 보내려면 쿼리 매개변수에서
sendEmails를true로 설정하세요. - 이 API로 생성된 댓글은 관리자 앱의 Analytics 및 Moderation 페이지에 표시됩니다.
- 설정이 켜져 있으면 "bad words"는 댓글 작성자 이름과 댓글 내용에서 여전히 마스킹됩니다.
- 원하면 이 API로 생성된 댓글은 스팸 검사를 받을 수 있습니다.
- Customization Rule 관리자 페이지에서 구성된 최대 댓글 길이 같은 설정은 여기에도 적용됩니다.
댓글 위젯에 표시되기 위해 제출에 필요한 최소 데이터는 다음과 같습니다:

더 현실적인 요청 예시는 다음과 같습니다:



PATCH /api/v1/comments/:id 
이 API 엔드포인트는 단일 댓글을 업데이트할 수 있는 기능을 제공합니다.
참고:
- 이 API는 원하면 댓글 위젯을 "실시간"으로 업데이트할 수 있습니다(기본
creditsCost가1에서2로 증가합니다).- 이를 통해 댓글을 페이지 간에 "실시간"으로 이동(예:
urlId변경)할 수 있습니다. - 페이지가 미리 계산되므로 마이그레이션은 추가로
2크레딧이 소모되며 CPU 집약적입니다.
- 이를 통해 댓글을 페이지 간에 "실시간"으로 이동(예:
- 생성 API와 달리, 이 API는 이메일이 제공되더라도 우리 시스템에 사용자 객체를 자동으로 생성하지 않습니다.
- 이 API로 업데이트된 댓글은 원하면 스팸 검사 대상이 될 수 있습니다.
- 최대 댓글 길이와 같은 구성은 Customization Rule 관리자 페이지에서 구성된 경우 여기에도 적용됩니다.
- 사용자가 자신의 댓글 텍스트를 업데이트할 수 있도록 하려면 요청 본문에 단순히
comment를 지정하면 됩니다. 우리는 결과commentHTML을 생성합니다.comment와commentHTML을 모두 정의하면 HTML을 자동으로 생성하지 않습니다.- 사용자가 새 텍스트에 멘션이나 해시태그를 추가하면
POSTAPI와 같이 처리됩니다.
- 댓글의
commenterEmail을 업데이트할 때는userId도 함께 지정하는 것이 가장 좋습니다. 그렇지 않으면 해당 이메일을 가진 사용자가 귀하의 테넌트에 속하는지 확인해야 하며, 그렇지 않으면 요청이 실패합니다. - 대상 댓글이 잠겨 있는 경우(
isLocked: true) 요청은code: 'locked'로 거부됩니다. 먼저 댓글의 잠금을 해제하고 업데이트한 다음 필요하면 다시 잠그십시오.



DELETE /api/v1/comments/:id 
이 API 엔드포인트는 댓글을 삭제할 수 있는 기능을 제공합니다.
참고:
- 원하는 경우 이 API는 댓글 위젯을 "라이브"로 업데이트할 수 있습니다 (이 경우
creditsCost가1에서2로 증가합니다). - 이 API는 모든 자식 댓글을 삭제합니다.
- 대상 댓글이 잠금 상태(
isLocked: true)이면 요청은code: 'locked'로 거부됩니다. 먼저 댓글의 잠금을 해제한 후 삭제하세요.



POST /api/v1/comments/:id/flag 
이 API 엔드포인트는 특정 사용자를 위해 댓글을 신고(flag)하는 기능을 제공합니다.
참고 사항:
- 이 호출은 항상 사용자 컨텍스트에서 수행되어야 합니다. 사용자는 FastComments.com 사용자, SSO 사용자 또는 테넌트 사용자일 수 있습니다.
- 신고-숨김 임계값이 설정되어 있는 경우, 정의된 횟수만큼 신고되면 댓글이 실시간으로 자동 숨김 처리됩니다.
- 자동으로 미승인(숨김) 처리된 후에는 관리자 또는 중재자만 댓글을 다시 승인할 수 있습니다. 신고를 취소한다고 해서 댓글이 다시 승인되지는 않습니다.

익명 신고의 경우 anonUserId를 지정해야 합니다. 이는 익명 세션을 나타내는 ID 또는 임의의 UUID일 수 있습니다.
이를 통해 사용자가 로그인하지 않은 경우에도 댓글 신고 및 신고 취소를 지원할 수 있습니다. 이렇게 하면 동일한 anonUserId로 댓글을 가져올 때 해당 댓글이 신고된 상태로 표시됩니다.



POST /api/v1/comments/:id/un-flag 
이 API 엔드포인트는 특정 사용자가 댓글의 플래그를 해제할 수 있는 기능을 제공합니다.
참고:
- 이 호출은 항상 사용자 컨텍스트에서 이루어져야 합니다. 사용자는 FastComments.com 사용자, SSO 사용자, 또는 테넌트 사용자가 될 수 있습니다.
- 댓글이 자동으로 미승인(숨김)된 이후에는 해당 댓글을 다시 승인할 수 있는 사람은 관리자 또는 중재자뿐입니다. 플래그 해제는 댓글을 다시 승인하지 않습니다.

익명 플래그의 경우 anonUserId를 지정해야 합니다. 이는 익명 세션을 나타내는 ID이거나 임의의 UUID일 수 있습니다.



POST /api/v1/comments/:id/block 
이 API 엔드포인트는 특정 댓글을 작성한 사용자를 차단할 수 있는 기능을 제공합니다. FastComments.com 사용자, SSO 사용자, Tenant 사용자가 작성한 댓글로부터의 차단을 지원합니다.
이 호출은 commentIdsToCheck 바디 파라미터를 지원하여, 이 작업 수행 후 클라이언트에 표시될 수 있는 다른 댓글들이 차단/차단 해제되어야 하는지 확인할 수 있습니다.
Notes:
- 이 호출은 항상 사용자 컨텍스트에서 이루어져야 합니다. 사용자는 FastComments.com 사용자, SSO 사용자, 또는 Tenant 사용자일 수 있습니다.
- 요청의
userId는 차단을 행하는 사용자입니다. 예:User A가User B를 차단하려고 합니다.userId=User A와User B가 작성한 댓글의 id를 전달하세요. - 완전히 익명인 댓글(사용자 id 없음, 이메일 없음)은 차단할 수 없으며 에러가 반환됩니다.

익명 차단의 경우 anonUserId를 지정해야 합니다. 이는 익명 세션을 나타내는 ID이거나 임의의 UUID일 수 있습니다.
이를 통해 사용자가 로그인하지 않은 경우에도 동일한 anonUserId로 댓글을 가져와 댓글을 차단하는 것을 지원할 수 있습니다.



POST /api/v1/comments/:id/un-block 
이 API 엔드포인트는 특정 댓글을 작성한 사용자의 차단을 해제할 수 있는 기능을 제공합니다. FastComments.com 사용자, SSO 사용자, 및 테넌트 사용자가 작성한 댓글에서의 차단 해제를 지원합니다.
이 작업이 수행된 후 클라이언트에서 잠재적으로 표시되는 다른 댓글들이 차단/차단 해제되어야 하는지 확인하기 위해 commentIdsToCheck 바디 매개변수를 지원합니다.
참고:
- 이 호출은 항상 사용자의 맥락에서 이루어져야 합니다. 사용자는 FastComments.com 사용자, SSO 사용자, 또는 테넌트 사용자일 수 있습니다.
- 요청의
userId는 차단을 해제하는 사용자입니다. 예를 들어:User A가User B의 차단을 해제하려고 합니다.userId=User A와User B가 작성한 댓글 ID를 전달하세요. - 완전히 익명인 댓글(사용자 id 없음, 이메일 없음)은 차단할 수 없으며 오류가 반환됩니다.




이메일 템플릿 구조 
EmailTemplate 객체는 테넌트의 맞춤 이메일 템플릿 구성을 나타냅니다.
시스템은 사용할 이메일 템플릿을 다음 기준으로 선택합니다:
- 유형 식별자 — 이를
emailTemplateId라고 합니다. 이 값들은 상수입니다. domain. 먼저 관련 객체(예:Comment)가 속한 도메인에 대한 템플릿을 찾습니다. 일치하는 템플릿이 없으면 domain이 null이거나*인 템플릿을 찾습니다.
다음은 EmailTemplate 객체의 구조입니다:

참고
- 유효한
emailTemplateId값은/definitions엔드포인트에서 확인할 수 있습니다. /definitions엔드포인트에는 기본 번역과 테스트 데이터도 포함되어 있습니다.- 템플릿은 구조나 테스트 데이터가 유효하지 않으면 저장에 실패합니다.
GET /api/v1/email-templates/:id 
개별 EmailTemplate는 해당 id(emailTemplateId가 아님)로 가져올 수 있습니다.



GET /api/v1/email-templates 
이 API는 페이지 매김을 사용하며, page 쿼리 매개변수로 제공합니다. EmailTemplates는 100개씩 페이지로 반환되며, createdAt과 그 다음으로 id로 정렬됩니다.



PATCH /api/v1/email-templates/:id 
이 API 엔드포인트는 id와 업데이트할 속성만 지정하여 이메일 템플릿을 업데이트할 수 있는 기능을 제공합니다.
템플릿을 생성할 때와 동일한 모든 유효성 검사가 적용된다는 점에 유의하세요. 예를 들어:
- 템플릿은 렌더링되어야 합니다. 각 업데이트 시 이것이 확인됩니다.
- 동일한 도메인에 대해 중복된 템플릿을 가질 수 없습니다(그렇지 않으면 하나가 조용히 무시됩니다).



POST /api/v1/email-templates 
이 API 엔드포인트는 이메일 템플릿을 생성하는 기능을 제공합니다.
Notes:
- 같은 도메인에서는 동일한
emailTemplateId를 가진 템플릿을 여러 개 가질 수 없습니다. - 하지만 와일드카드 템플릿(
domain=*)과 동일한emailTemplateId에 대한 도메인별 템플릿을 동시에 가질 수 있습니다. - 여러 도메인이 있거나 테스트용으로 특정 템플릿을 사용하려는 경우(예:
domain을localhost로 설정) 에만domain을 지정하면 됩니다. - 만약
domain을 지정하면 해당 값은DomainConfig와 일치해야 합니다. 오류가 발생하면 유효한 도메인 목록이 제공됩니다. - 템플릿 문법은 EJS이며 500ms 타임아웃으로 렌더링됩니다. 렌더링의 P99는 <5ms 이므로 500ms에 도달하면 문제가 있는 것입니다.
- 저장하려면 템플릿이 주어진
testData로 렌더링되어야 합니다. 렌더링 오류는 집계되어 대시보드에 보고됩니다(곧 API를 통해서도 제공될 예정입니다).
템플릿을 추가하는 데 필요한 최소 데이터는 다음과 같습니다:

사이트별 템플릿을 원할 경우 domain을 정의할 수 있습니다:



POST /api/v1/email-templates/render 
이 API 엔드포인트는 이메일 템플릿을 미리 볼 수 있는 기능을 제공합니다.



DELETE /api/v1/email-templates/:id 
이 경로는 id로 단일 EmailTemplate를 제거합니다.



FeedPost 구조 
FeedPost 객체는 FastComments 피드의 게시물을 나타냅니다. 피드는 자체 댓글 스레드를 가진 게시물 스트림으로, Feed 위젯에 의해 렌더링됩니다. 각 게시물은 작성자, 선택적 풍부 콘텐츠, 미디어 및 링크를 가지고 있으며, 피드를 필터링할 수 있도록 태그를 지정할 수 있습니다.
FeedPost 객체의 구조는 다음과 같습니다:

참고:
READONLY로 표시된 필드가 있습니다 - 이 필드들은 API에서 반환되지만 설정할 수 없습니다.- 게시물에 대한 댓글은
urlId가post:뒤에 게시물_id가 붙은 일반 댓글입니다. 해당 값을 Comment API와 함께 사용하여 게시물에 대한 댓글을 읽거나 생성할 수 있습니다.
GET /api/v1/feed-posts 
피드의 게시물을 최신 순으로 가져옵니다. 페이지네이션은 커서 기반이며, 마지막으로 받은 게시물의 _id를 afterId로 전달하여 다음 페이지를 가져옵니다.
반환된 10개의 게시물당 1크레딧이 소모되며, 최소 1크레딧이 차감됩니다.



POST /api/v1/feed-posts 
이 라우트는 단일 FeedPost를 생성합니다. 모든 게시물에는 작성자가 있으므로 fromUserId가 필요하며, 이는 계정에 존재하는 FastComments 또는 SSO 사용자의 ID여야 합니다.



PATCH /api/v1/feed-posts/:id 
이 라우트는 단일 FeedPost를 업데이트합니다. 변경하려는 필드만 전송하세요.



HashTag 구조 
HashTag 객체는 사용자가 남길 수 있는 태그를 나타냅니다. HashTag는 외부 콘텐츠로 연결하거나 관련 댓글을 묶는 데 사용할 수 있습니다.
HashTag 객체의 구조는 다음과 같습니다:

참고 사항:
- 일부 API 엔드포인트에서는 해시태그가 URL에 사용되는 것을 볼 수 있습니다. 값은 URI 인코딩해야 함을 기억하세요. 예를 들어,
#은%23으로 표현해야 합니다. - 일부 필드는
READONLY로 표시되어 있습니다 - 이는 API에서 반환되지만 설정할 수는 없습니다.
GET /api/v1/hash-tags 
이 API는 page 쿼리 매개변수로 페이지네이션을 제공합니다. HashTags는 tag로 정렬되어 페이지당 100개씩 반환됩니다.



PATCH /api/v1/hash-tags/:tag 
이 경로는 단일 HashTag를 업데이트할 수 있는 기능을 제공합니다.



POST /api/v1/hash-tags 
이 라우트는 단일 HashTag를 추가하는 기능을 제공합니다.



POST /api/v1/hash-tags/bulk 
이 경로는 최대 100개의 HashTag 객체를 한 번에 추가할 수 있는 기능을 제공합니다.



DELETE /api/v1/hash-tags/:tag 
이 라우트는 제공된 태그로 HashTag 사용자를 제거합니다.
자동 HashTag 생성이 비활성화되지 않은 한, 사용자가 댓글 작성 시 해시태그를 제공하면 해시태그가 다시 생성될 수 있습니다.



GET /api/v1/me 
요청을 만든 자격 증명을 설명합니다: 해당 자격 증명이 속한 테넌트와 OAuth 액세스 토큰의 경우 애플리케이션을 승인한 사용자를 나타냅니다. 통합에서는 이를 사용하여 연결을 테스트하고 라벨을 지정합니다.
API 키를 사용할 경우 응답은 테넌트만 식별합니다. OAuth 베어러 토큰을 사용할 경우 승인된 사용자와 부여된 범위도 포함됩니다.


Moderator 구조 
Moderator 객체는 모더레이터에 대한 구성을 나타냅니다.
모더레이터에는 세 가지 유형이 있습니다:
isCommentModeratorAdmin플래그를 가진 관리자 사용자.isCommentModeratorAdmin플래그를 가진 SSO 사용자.- 초대로 모더레이터가 된 일반 댓글 작성자 또는 FastComments.com 사용자.
Moderator 구조는 사용 사례 3의 중재 상태를 나타내는 데 사용됩니다.
API를 통해 사용자를 모더레이터로 초대하려면 Moderator API를 사용하여 Moderator를 생성하고 그들을 inviting 하십시오.
사용자에게 FastComments.com 계정이 없으면 초대 이메일이 계정 설정을 돕습니다. 이미 계정이 있는 경우 해당 테넌트에 대한 중재 접근 권한이 부여되고 Moderator 객체의 userId가 해당 사용자를 가리키도록 업데이트됩니다. 이 경우 해당 사용자 계정은 본인 소유이며 FastComments.com에서 관리되므로, 해당 사용자에 대한 API 접근 권한은 없습니다.
사용자 계정을 완전히 관리해야 하는 경우, SSO를 사용하거나 그들을 Tenant User로 추가한 다음 Moderator 객체를 추가하여 통계를 추적하는 것을 권장합니다.
Moderator 구조는 사용 사례 1 및 2에 대한 통계 추적 메커니즘으로 사용할 수 있습니다. 사용자를 생성한 후 userId가 정의된 Moderator 객체를 추가하면 해당 통계가 Comment Moderators Page에서 추적됩니다.
Moderator 객체의 구조는 다음과 같습니다:

GET /api/v1/moderators/:id 
이 경로는 해당 id의 단일 모더레이터를 반환합니다.



GET /api/v1/moderators 
이 API는 페이징을 사용하며, skip 쿼리 매개변수로 제공됩니다. 모더레이터는 createdAt 및 id 순으로 정렬되어 한 페이지에 100명씩 반환됩니다.
요금은 반환된 모더레이터 수에 따라 계산되며, 반환된 모더레이터 10명당 1 credit per 10의 비용이 발생합니다.



PATCH /api/v1/moderators/:id 
이 API 엔드포인트는 id로 Moderator를 업데이트할 수 있는 기능을 제공합니다.
Moderator를 업데이트할 때 다음과 같은 제한이 있습니다:
- Moderator를 업데이트할 때 다음 값들은 제공할 수 없습니다:
acceptedInvitemarkReviewedCountdeletedCountmarkedSpamCountapprovedCounteditedCountbannedCountverificationIdcreatedAt
userId가 지정된 경우, 해당 사용자가 존재해야 합니다.userId가 지정된 경우, 해당 사용자는 쿼리 매개변수에 지정된 동일한tenantId에 속해야 합니다.- 동일한 테넌트 내의 두 명의 모더레이터는 동일한
email로 추가할 수 없습니다. - Moderator에 연관된
tenantId는 변경할 수 없습니다.



POST /api/v1/moderators 
이 경로는 단일 Moderator를 추가할 수 있는 기능을 제공합니다.
Moderator 생성에는 다음과 같은 제한이 있습니다:
name과email은 항상 제공되어야 합니다.userId는 선택 사항입니다.Moderator를 생성할 때 다음 값들은 제공할 수 없습니다:acceptedInvitemarkReviewedCountdeletedCountmarkedSpamCountapprovedCounteditedCountbannedCountverificationIdcreatedAt
userId가 지정된 경우, 해당 사용자는 존재해야 합니다.userId가 지정된 경우, 해당 사용자는 쿼리 매개변수에 지정된 동일한tenantId에 속해야 합니다.- 동일한 테넌트 내에서 두 명의 모더레이터는 같은
email로 추가될 수 없습니다.
이메일만 알고 있는 사용자에 대해 Moderator를 생성할 수 있습니다:

또는 해당 사용자가 우리 테넌트에 속해 있는 경우, 그들의 모더레이션 통계를 추적하기 위해 Moderator를 생성할 수 있습니다:



POST /api/v1/moderators/:id/send-invite 
이 경로는 단일 Moderator를 초대할 수 있는 기능을 제공합니다.
다음 제한 사항이 Moderator에게 초대 이메일을 보내는 데 적용됩니다:
Moderator는 이미 존재해야 합니다.fromName은100 characters보다 길 수 없습니다.
참고:
- 제공된 이메일을 가진 사용자가 이미 존재하면, 해당 사용자는 테넌트의 댓글을 관리하도록 초대됩니다.
- 제공된 이메일을 가진 사용자가 존재하지 않는 경우, 초대 링크는 계정 생성 절차로 안내합니다.
- 초대는
30 days후에 만료됩니다.
이메일만 알고 있는 사용자에 대해 Moderator를 생성할 수 있습니다:

이것은 다음과 같은 이메일을 보냅니다: Bob at TenantName is inviting you to be a moderator...


DELETE /api/v1/moderators/:id 
이 경로는 id로 Moderator를 제거합니다.



알림 카운트 구조 
NotificationCount 객체는 사용자의 읽지 않은 알림 수와 메타데이터를 나타냅니다.
읽지 않은 알림이 없으면 해당 사용자에 대한 NotificationCount가 존재하지 않습니다.
NotificationCount 객체는 자동으로 생성되며 API를 통해 생성할 수 없습니다. 또한 1년 후에 만료됩니다.
사용자의 NotificationCount를 삭제하면 읽지 않은 알림 수를 초기화할 수 있습니다.
NotificationCount 객체의 구조는 다음과 같습니다:

GET /api/v1/notification-count/:user_id 
이 라우트는 사용자 ID로 단일 NotificationCount를 반환합니다. SSO를 사용하는 경우 사용자 ID 형식은 <tenant id>:<user id>입니다.
읽지 않은 알림이 없으면 NotificationCount가 없으므로 404를 받게 됩니다.
notifications/count와 달리 훨씬 빠르지만 필터링은 허용하지 않습니다.



DELETE /api/v1/notification-count/:user_id 
이 경로는 사용자 id로 단일 NotificationCount를 삭제합니다. SSO를 사용하는 경우, 사용자 id는 <tenant id>:<user id> 형식입니다.
이 작업은 사용자의 읽지 않은 알림 수를 초기화합니다(댓글 위젯의 빨간 벨이 사라지고 카운트가 사라집니다).



알림 구조 
A Notification 객체는 사용자를 위한 알림을 나타냅니다.
Notification 객체는 자동으로 생성되며 API를 통해 생성할 수 없습니다. 또한 1년 후에 만료됩니다. 알림은 삭제할 수 없습니다. 하지만 viewed를 false로 설정하여 업데이트할 수 있으며, viewed로 조회할 수 있습니다.
사용자는 알림에서 특정 댓글에 대해 optedOut을 true로 설정하여 알림을 받지 않도록 선택할 수 있습니다. false로 설정하면 다시 수신하도록 할 수 있습니다.
알림 유형은 다양합니다 - relatedObjectType와 type을 확인하세요.
알림이 생성되는 방식은 매우 유연하며 다양한 시나리오에 의해 트리거될 수 있습니다 (NotificationType 참조).
현재 Notification이 존재한다고 해서 이메일이 전송되거나 전송되어야 함을 의미하지 않습니다. 대신 알림은 알림 피드와 관련 통합에 사용됩니다.
Notification 객체의 구조는 다음과 같습니다:

GET /api/v1/notifications 
이 라우트는 createdAt을 기준으로 최신 순으로 정렬된 최대 30개의 Notification 객체를 반환합니다.
userId로 필터링할 수 있습니다. SSO의 경우 사용자 ID는 <tenant id>:<user id> 형식입니다.



GET /api/v1/notifications/count 
이 라우트는 count 매개변수에 알림 수를 담은 객체를 반환합니다.
이 라우트는 /notification-count/보다 느리고 크레딧 비용이 두 배이지만 더 많은 차원으로 필터링할 수 있습니다.
/notifications 엔드포인트와 동일한 매개변수(예: userId)로 필터링할 수 있습니다. SSO를 사용하는 경우 user id는 <tenant id>:<user id> 형식입니다.




PATCH /api/v1/notifications/:id 
이 API 엔드포인트는 id로 Notification을 업데이트할 수 있는 기능을 제공합니다.
Notification을 업데이트할 때 다음 제한이 있습니다:
- 다음 필드만 업데이트할 수 있습니다:
viewedoptedOut



페이지 반응 공개 API 
Page Reacts는 사용자가 페이지에 좋아요를 누르거나 자체 반응 이미지 세트로 반응할 수 있게 합니다. Page Reacts widget와 Floating Likes 위젯은 이러한 엔드포인트를 기반으로 구축되며, 직접 호출하여 자체 좋아요 버튼을 만들 수 있습니다.
이 가이드의 다른 부분과 달리, Page Reacts 엔드포인트는 공개되어 있습니다. 사용자의 브라우저에서 호출되며 API 키가 필요 없고 API 크레딧도 소모되지 않습니다. 모든 반응은 요청을 보낸 사용자에게 귀속되므로 사용자는 자신의 반응만 추가하거나 제거할 수 있습니다.
엔드포인트는 두 가지 세트가 있습니다:
/page-reacts/v1/likes/:tenantId- 사용자당 페이지당 하나의 "like"만 허용합니다. 좋아요 버튼에 사용하세요./page-reacts/v2/:tenantId- 페이지당 여러 반응을 허용하며, 각각은 사용자가 선택한 짧은id(예:heart또는laugh)로 식별됩니다.
두 엔드포인트는 PublicApi의 일부로서 우리 SDK에서도 사용할 수 있으며, 예를 들어 JavaScript SDK에서는 getV1PageLikes, createV1PageReact, deleteV1PageReact와 같은 메서드가 제공됩니다.
반응한 사람 보기
GET 엔드포인트에 includeUserInfo=public을 전달하면 좋아요 또는 반응을 한 사용자들의 사용자명과 아바타를 최신 순으로 함께 가져올 수 있습니다. 프로필 활동을 비공개로 설정한 사용자와 익명 사용자는 제외됩니다. 최대 100개의 반응이 반환됩니다.
SSO 사용자는 isProfileActivityPrivate를 false로 설정하지 않는 한 프로필 활동이 비공개 상태로 생성됩니다. 따라서 목록에 표시하고 싶은 사용자는 해당 값을 설정해 주세요.
SSO가 필요한 페이지에서는 해당 페이지를 볼 수 있는 SSO 사용자만 반응한 사람 목록을 조회할 수 있습니다. 그 외의 경우 sso-required 또는 page-forbidden 코드를 포함한 403 오류가 반환됩니다.
서버에서 GET /api/v1/pages/likes와 GET /api/v1/pages/reacts를 호출하면 API 키와 함께 동일한 목록을 반환하며, includeUserInfo=include-private를 사용하면 비공개 프로필을 가진 사용자도 포함됩니다.
사용자를 식별하기
반응은 요청을 보낸 사용자와 연결됩니다:
- SSO 사용자:
sso쿼리 매개변수를 전달하고, 댓글 위젯에 제공한 것과 동일한 SSO 객체를 URI 인코딩한 JSON으로 설정합니다. 자세한 내용은 SSO를 참고하세요. - 익명 사용자:
sso매개변수가 없고 FastComments 로그인도 없는 경우, 서버는 FastComments 세션 쿠키에 저장된 익명 ID를 브라우저에 할당합니다. 요청을 보낼 때credentials: 'include'를 사용하여 쿠키가 요청 간에 유지되도록 합니다. 서드파티 쿠키를 차단하는 브라우저는 익명 ID를 유지하지 않으므로, 각 사용자를 신뢰성 있게 인식해야 할 경우 SSO를 사용하세요.
urlId
urlId는 페이지를 식별하며, 댓글에서도 동일하게 사용됩니다. 좋아요와 댓글이 같은 페이지에서 집계되도록 댓글 위젯에 제공한 것과 동일한 urlId를 사용하세요. URI 인코딩을 잊지 마세요.

GET /page-reacts/v1/likes/:tenantId 
페이지에 대한 좋아요 수와 현재 사용자가 해당 페이지에 좋아요를 눌렀는지 여부를 반환합니다. 아직 존재하지 않는 페이지는 likeCount가 0으로 반환됩니다.
includeUserInfo=public을 전달하면 페이지에 좋아요를 누른 사용자들을 최신 순으로 가져올 수 있습니다. 비공개 프로필 활동을 가진 사용자와 익명 사용자는 제외되며, 최대 100개의 좋아요가 조회됩니다. 여기서는 public만 허용됩니다; include-private를 사용하면 422 오류가 반환되며 API 키와 함께 GET /api/v1/pages/likes에서 사용할 수 있습니다. SSO가 필요한 페이지에서는 includeUserInfo가 페이지를 볼 수 없는 사용자에게 403을 반환합니다.



POST /page-reacts/v1/likes/:tenantId 
현재 사용자로서 페이지에 좋아요를 표시합니다. 각 사용자는 페이지에 한 번만 좋아요를 할 수 있습니다: 다시 좋아요를 시도하면 already-liked 코드와 함께 성공하며 카운트는 변경되지 않습니다.
페이지가 아직 존재하지 않으면 생성됩니다. title을 전달하여 페이지의 제목을 설정하거나 업데이트합니다.



DELETE /page-reacts/v1/likes/:tenantId 
현재 사용자의 페이지 좋아요를 제거합니다. 사용자가 페이지에 좋아요를 누르지 않은 경우, 요청은 not-liked 코드와 함께 성공하며 카운트는 변경되지 않습니다.



GET /page-reacts/v2/:tenantId 
페이지의 각 반응에 대한 카운트를 반환하고, 현재 사용자가 추가한 반응을 반환합니다.
includeUserInfo=public을 전달하면 반응한 사용자도 가져올 수 있으며, 반응당 하나의 항목으로 반응 ID와 함께 가장 최신 순으로 반환됩니다. 개인 프로필 활동을 가진 사용자와 익명 사용자는 제외되며, 최대 100개의 반응이 조회됩니다. 여기서는 public만 허용됩니다; include-private는 422를 반환하며 API 키와 함께 GET /api/v1/pages/reacts에서 사용할 수 있습니다. SSO가 필요한 페이지에서는 includeUserInfo가 페이지를 볼 수 없는 사용자에게 403을 반환합니다.



GET /page-reacts/v2/:tenantId/list 
페이지에 반응을 추가한 사용자의 이름을 알파벳 순으로 반환합니다. 최대 100개의 반응을 조회하며, 익명 사용자와 비공개 프로필 활동을 가진 사용자는 포함되지 않습니다. SSO가 필요한 페이지에서는 페이지를 볼 수 없는 사용자가 403과 코드 sso-required 또는 page-forbidden을 받습니다.
아바타와 사용자 ID도 가져오려면 includeUserInfo=public와 함께 GET /page-reacts/v2/:tenantId 를 사용하세요.



POST /page-reacts/v2/:tenantId 
현재 사용자로서 페이지에 반응을 추가합니다. 사용자는 각 반응 ID를 한 번만 추가할 수 있습니다: 다시 추가하면 already-reacted 코드와 함께 성공하며 카운트가 변경되지 않습니다. 사용자는 같은 페이지에 여러 다른 반응을 추가할 수 있습니다.
반응 ID는 사용자가 선택하며 최대 36자까지 가능합니다. 페이지가 아직 존재하지 않으면 생성됩니다. 페이지의 제목을 설정하거나 업데이트하려면 title을 전달하세요.



DELETE /page-reacts/v2/:tenantId 
현재 사용자의 페이지에 대한 리액션 중 하나를 제거합니다. 사용자가 해당 리액션을 추가하지 않은 경우, 요청은 no-react 코드와 함께 성공하며 카운트는 변경되지 않습니다.



페이지 구조 
A Page 객체는 여러 댓글이 속할 수 있는 페이지를 나타냅니다. 이 관계는 urlId로 정의됩니다.
A Page는 페이지 제목, 댓글 수, 및 urlId와 같은 정보를 저장합니다.
Page 객체의 구조는 다음과 같습니다:

GET /api/v1/pages 
현재는 귀하의 계정에 연결된 모든 페이지(또는 /by-url-id를 통해 단일 페이지)만 가져올 수 있습니다. 더 세밀한 검색이 필요하시면 저희에게 문의해 주세요.



유용한 팁
Comment API에는 urlId가 필요합니다. 먼저 Pages API를 호출하여 사용 가능한 urlId 값이 어떤 형태인지 확인할 수 있습니다.
GET /api/v1/pages/by-url-id 
개별 페이지는 해당 urlId로 가져올 수 있습니다. 이는 페이지 제목이나 댓글 수를 조회하는 데 유용합니다.



유용한 팁
urlId과 같은 값은 URI 인코딩해야 합니다.
GET /api/v1/pages/likes 
페이지에 대한 좋아요 수를 반환하며, 선택적으로 가장 최근 순으로 좋아요를 누른 사용자들을 반환합니다. 이는 GET /page-reacts/v1/likes/:tenantId 의 서버 측 버전입니다.
includeUserInfo 는 반환되는 사용자를 제어합니다:
public은 프로필 활동을 비공개로 설정한 사용자를 제외합니다.include-private은 해당 사용자를 포함합니다. 이 옵션은 목록이 공개되지 않을 때만 사용하십시오.
익명 사용자는 절대 포함되지 않으며, 최대 100개의 좋아요가 조회됩니다. 존재하지 않는 페이지는 likeCount 가 0 이고 users 목록이 비어 있습니다.



유용한 팁
urlId 와 같은 값은 URI 인코딩을 해야 합니다.
GET /api/v1/pages/reacts 
페이지의 각 반응에 대한 카운트를 반환하고, 선택적으로 반응한 사용자를 반환합니다. 각 반응은 반응 ID와 함께 최신 순으로 하나의 항목으로 제공됩니다. 이는 GET /page-reacts/v2/:tenantId의 서버 측 버전입니다.
includeUserInfo는 반환되는 사용자를 제어합니다:
public은 프로필 활동을 비공개로 설정한 사용자를 제외합니다.include-private는 해당 사용자를 포함합니다. 이 옵션은 목록이 공개되지 않을 때만 사용하십시오.
익명 사용자는 절대 포함되지 않으며, 최대 100개의 반응을 조회합니다. 존재하지 않는 페이지는 counts가 없고 users 목록이 비어 있습니다.



유용한 팁
urlId와 같은 값은 URI 인코딩해야 합니다.
PATCH /api/v1/pages/:id 
이 라우트는 단일 Page를 업데이트할 수 있는 기능을 제공합니다. 해당 댓글들이 업데이트됩니다.



참고
Page 객체의 일부 매개변수는 자동으로 업데이트됩니다. 이러한 항목에는 카운트와 title 속성이 포함됩니다. 카운트는 계산된 값이므로
API를 통해 업데이트할 수 없습니다. 페이지 title은 API를 통해 설정할 수 있지만, 동일한 urlId를 가진 페이지에서 댓글 위젯을 사용하고 페이지 제목이 다를 경우 덮어써질 수 있습니다.
POST /api/v1/pages 
이 API 엔드포인트는 페이지를 생성하는 기능을 제공합니다.
일반적인 사용 사례는 접근 제어입니다.
참고 사항:
- 댓글 스레드에 댓글을 작성했거나
Comment를 생성하는 API를 호출했다면, 이미Page객체를 생성한 것입니다! 댓글 위젯에 전달한 것과 동일한urlId를 사용하여/by-url-idPage라우트를 통해 해당 객체를 가져올 수 있습니다. Page구조에는 일부 계산된 값이 포함되어 있습니다. 현재 이 값들은commentCount와rootCommentCount입니다. 이 값들은 자동으로 채워지며 API를 통해 설정할 수 없습니다. 설정을 시도하면 API가 오류를 반환합니다.



DELETE /api/v1/pages/:id 
이 라우트는 id로 단일 페이지를 제거합니다.
동일한 urlId를 가진 페이지의 댓글 위젯과 상호작용하면 Page가 원활하게 재생성된다는 점에 유의하세요.



POST /api/v1/pages/migrations 
이 라우트는 댓글과 페이지를 하나의 urlId 또는 도메인에서 다른 것으로 이동합니다. 대시보드의 Domain Migration tool와 동일합니다. 요청당 최대 100개의 마이그레이션을 보낼 수 있습니다. 지정된 순서대로 실행되므로 a에서 b로, 그 다음 b에서 c로 이동하는 것이 작동합니다.
각 마이그레이션은 type을 가집니다:
urlId는urlId가 정확히from인 페이지를 이동합니다.post-1은post-10과 일치하지 않습니다.domain은 모든urlId와url내부의from을 찾아/바꾸고, 각 댓글의domain을 업데이트합니다. 두 값 모두old.example.com과 같은 도메인이어야 합니다.
댓글, 페이지, 페이지 반응, 투표, 알림 및 구독 모두 이동합니다. to에 이미 페이지가 존재하면 두 페이지가 병합됩니다.
마이그레이션은 배치 작업으로 실행됩니다. 응답에 batchJobId가 포함됩니다. 진행 상황을 확인하려면 GET /api/v1/batch-jobs/:id를 폴링하십시오. 작업이 완료되면 마이그레이션당 결과가 제공되며, 90일 이내에 POST /api/v1/pages/migrations/:undoId/undo로 전달할 수 있는 undoId가 있습니다.
요청은 큐에 넣기 전에 검증됩니다. 마이그레이션 중 하나라도 유효하지 않으면 전체 요청이 422와 함께 실패하고 아무 작업도 실행되지 않습니다.
마이그레이션을 큐에 넣는 데 비용이 들지 않습니다. 작업이 완료되면 마이그레이션된 1000개의 댓글당 1 크레딧이 차감되며, 최소 1 크레딧이 부과됩니다.



참고
- 한 테넌트에 대한 작업은 한 번에 하나씩, 오래된 것이 먼저 실행됩니다. 두 번째 마이그레이션은 첫 번째가 완료될 때까지 기다립니다.
PATCH /api/v1/pages/:id를 새urlId와 함께 사용하면 페이지만 변경되고 댓글은 변경되지 않습니다. 이 라우트를 사용하여 페이지의 댓글을 이동하십시오.
POST /api/v1/pages/migrations/:undoId/undo 
이 라우트는 하나의 POST /api/v1/pages/migrations 작업에서 발생한 모든 마이그레이션을 되돌립니다. 완료된 마이그레이션 작업에서 undoId를 GET /api/v1/batch-jobs/:id 로 가져옵니다. undoId는 90일 동안 사용할 수 있으며 한 번만 사용할 수 있습니다.
undo는 마이그레이션과 동일하게 배치 작업으로 실행되며, 응답에 batchJobId가 포함됩니다. 작업이 완료되면 pageMigrationUndoResult가 다음을 보고합니다:
restored: 마이그레이션 이전 값으로 복원된 레코드.skipped: 마이그레이션 후 변경되었거나 더 이상 존재하지 않아 그대로 남은 레코드. 이후 편집은 절대 덮어쓰지 않습니다.notRestorable: 두 페이지를 병합하거나 중복 페이지를 제거하는 과정에서 마이그레이션이 삭제된 레코드. 복구할 수 없습니다.
마이그레이션은 최신 순으로 역순으로 되돌리며, 따라서 a에서 b로, 그 다음 b에서 c로의 체인은 a로 되돌아갑니다. 중간에 실패한 마이그레이션 작업도 undo가 가능하며, 실패 전까지 적용된 변경을 되돌립니다.
undo를 큐에 넣는 데는 비용이 들지 않습니다. 작업이 완료되면 복원된 레코드 1,000개당 1 크레딧이 차감되며 최소 1 크레딧이 부과됩니다.



Poll 구조 
Poll는 독립적인 객체가 아니라 댓글에 첨부됩니다. 댓글과 함께 생성되거나( POST /api/v1/comments 참조), 이후 PUT /api/v1/polls/:commentId를 사용하여 기존 댓글에 추가됩니다.
투표 수는 poll 자체에 저장되므로, poll을 읽으면 아무것도 더할 필요 없이 결과를 바로 얻을 수 있습니다. 이 수치 뒤에 있는 개별 투표는 PollVote 객체입니다.
각 옵션은 poll이 생성될 때 생성되는 id를 가집니다. 이 id는 투표를 하거나, 옵션의 라벨을 변경하거나, 옵션을 추가하거나 제거하여 poll을 PUT할 때 옵션(및 해당 투표)을 유지하는 데 사용됩니다. 옵션을 참조하는 유일한 안전한 방법은 이 id이며, 목록에서의 위치는 절대 사용하지 마십시오.

제한 사항
- 질문은 필수이며 최대 200자입니다.
- poll은 2개에서 10개 사이의 옵션을 가집니다.
- 옵션 라벨은 필수이며, 최대 100자이고, poll 내에서 고유해야 합니다(대소문자 무시).
closesAt은 poll이 생성될 때 미래의 시점이어야 합니다. poll을 즉시 종료하려면 과거의 날짜로PATCH하십시오.
사이트 설정
Poll은 사이트 구성을 따르며, 이는 Customize Widget에서 변경할 수 있습니다:
- poll을 생성하려면 먼저 Poll이 활성화되어 있어야 하며, 그렇지 않으면 API가
polls-disabled로 응답합니다. - 투표는 로그인한 사용자로 제한될 수 있으며, 이 경우
anonUserId만 포함된 투표는poll-login-required로 거부됩니다.
GET /api/v1/polls/:commentId 
댓글에 연결된 설문조사를 현재 투표 수와 함께 읽어옵니다.
설문조사는 댓글 API를 통해 댓글 자체에도 반환되므로, 전체 댓글이 아니라 결과만 필요할 때 이 엔드포인트를 사용하십시오.



설문조사가 없는 댓글, 삭제된 댓글, 존재하지 않는 댓글 ID 모두 poll-not-found와 함께 동일한 방식으로 응답합니다.
PUT /api/v1/polls/:commentId 
기존 댓글에 설문을 연결하거나 이미 존재하는 설문의 전체 상태를 설정합니다.
본문은 전체 설문이며, 전송한 옵션은 해당 순서대로 설문의 옵션이 됩니다. 각 옵션은 id 로 매칭됩니다:
- 기존 옵션의
id를 포함하여 전송된 옵션은 해당 옵션과 투표를 유지합니다. 라벨과 위치는 전송한 내용으로 업데이트됩니다. id없이 전송된 옵션은 새로 추가되며, 투표는 없습니다.- 기존 옵션을 제외하면 해당 옵션과 그에 대한 투표가 모두 제거됩니다.
totalVotes도 동일하게 감소합니다.
따라서 옵션을 추가하려면 현재 옵션들을 id와 함께 전송하고 새 옵션은 id 없이 전송합니다. 옵션을 제거하려면 해당 옵션을 제외한 목록을 전송합니다. 옵션 id 는 GET /api/v1/polls/:commentId 로 반환된 설문에 포함됩니다.
모든 id 를 전송하지 않으면 모든 옵션이 교체되고 설문에 이미 존재하던 모든 투표가 삭제됩니다. 설문에 투표가 있는 경우 replaceVotes=true 가 필요하며, 이를 지정하지 않으면 API는 replace-votes-required 로 응답합니다.
다른 필드도 동일하게 교체됩니다: closesAt, privacy, requireVoteToSeeResults 를 생략하면 기본값으로 재설정됩니다. 하나의 필드만 변경하고 나머지는 유지하려면 PATCH /api/v1/polls/:commentId 를 사용하세요.



기타 참고 사항
- 설문에 존재하지 않는
id이거나 동일한id를 두 번 제공하면poll-invalid오류가 발생합니다. 설문이 없는 댓글은 아직 옵션id가 없으므로 전송하는 모든 옵션은id를 생략해야 합니다. - 설문에 투표가 있는 경우 프라이버시 설정은 좁게만 조정할 수 있고 넓게는 변경할 수 없습니다.
- 이 API는 사이트 설정을 따릅니다. 사이트나 페이지에서 설문이 활성화되지 않은 경우
polls-disabled오류가 발생합니다. - 잠긴 댓글은 설문을 변경할 수 없으며
locked오류가 발생합니다. - 연결된 위젯은 실시간으로 업데이트되므로 사용자는 새 설문을 페이지를 새로 고치지 않고도 볼 수 있습니다.
PATCH /api/v1/polls/:commentId 
투표의 투표수를 방해하지 않고 설문을 편집합니다. 질문이나 옵션의 오타를 수정하거나, 설문을 닫거나 다시 열거나, 누가 투표했는지를 볼 수 있는 권한을 변경할 때 사용합니다.
옵션은 id 로 지정되며, PATCH 는 지정한 옵션의 라벨을 변경합니다. 옵션을 추가, 제거 또는 순서를 바꾸려면 전체 옵션 목록을 PUT /api/v1/polls/:commentId 로 전송하십시오: id와 함께 전송한 옵션은 투표도 그대로 유지됩니다.
모든 필드는 선택 사항이지만, 최소 하나는 제공해야 합니다.




기타 참고 사항
- 설문에 존재하지 않는 옵션 id를 지정하면
poll-invalid오류가 발생하며, 조용히 무시되지 않습니다. - 라벨은 설문 내에서 고유해야 하며, 변경하지 않는 옵션도 포함하여 중복되지 않아야 합니다.
- 설문을 생성할 때와 달리, 여기서는
closesAt를 과거 시점으로 지정할 수 있습니다—즉시 설문을 닫는 방법입니다. - 설문에 투표가 있으면 프라이버시 설정을 좁게 할 수는 있지만, 넓게 할 수는 없습니다.
- 잠긴 댓글은 설문을 변경할 수 없으며,
locked오류가 발생합니다.
DELETE /api/v1/polls/:commentId 
댓글에서 설문을 제거하고, 해당 설문에 대한 모든 투표도 함께 삭제합니다. 댓글 자체는 그대로 남습니다.
댓글을 삭제하면 설문과 투표도 함께 삭제되므로, 댓글을 유지하고 싶을 때만 이 작업이 필요합니다.



PollVote 구조 
PollVote는 설문에 대한 한 사람의 답변입니다. 설문 자체에 표시되는 카운트는 이와 동기화되어 유지되므로, 총합이 아니라 누가 무엇에 투표했는지 알고 싶을 때만 필요합니다.
투표자는 설문당 최대 하나의 투표만 가질 수 있습니다. 다시 투표하면 두 번째 투표를 추가하는 대신 기존 투표가 새로운 옵션으로 이동하며, updatedAt은 그 시점을 기록합니다.
voterId는 투표자가 로그인했을 때의 userId이며, 그렇지 않으면 anonUserId입니다.

Privacy
설문의 privacy 설정은 댓글 위젯에 적용되는 방식과 동일하게 이 API에도 적용됩니다:
- Anonymous (the default): 아무도 누가 어떻게 투표했는지 볼 수 없으므로 투표를 읽을 수 없습니다.
GET /api/v1/poll-votes및GET /api/v1/poll-votes/:id는poll-anonymous로 응답합니다. 설문의 카운트는GET /api/v1/polls/:commentId에서 여전히 확인할 수 있습니다. - Admins and moderators: API 키가 사이트 관리자의 것이므로 투표를 읽을 수 있습니다.
- Everyone: 모든 사람이 투표를 읽을 수 있습니다.
설문에 투표가 있으면 프라이버시 설정을 좁게 할 수는 있지만 넓게 할 수는 없습니다.
GET /api/v1/poll-votes 
하나의 설문 조사 카운트 뒤에 있는 개별 투표를 오래된 순서대로 나열합니다. 반환된 100표당 1크레딧이 소모됩니다.
설문 조사는 댓글에 속하므로 투표는 한 번에 하나의 설문 조사씩 읽으며 commentId가 필요합니다. voterId를 사용하여 특정 사용자의 투표를 확인하거나 optionId를 사용하여 특정 옵션을 선택한 모든 사용자를 나열할 수 있습니다.
한 호출당 최대 1000개의 투표가 반환됩니다. 더 많은 투표를 페이지네이션하려면 skip을 사용하세요.
설문 조사의 privacy 설정이 적용됩니다: 익명 설문 조사에 대한 투표는 읽을 수 없으며, 요청은 poll-anonymous 오류와 함께 실패합니다. 자세한 내용은 PollVote 구조를 참조하세요.



옵션별 투표 수 계산
결과를 얻기 위해 직접 합산할 필요가 없습니다 - 설문 조사는 자체 카운트를 가지고 있습니다. 대신 GET /api/v1/polls/:commentId 로 설문 조사를 읽고, 누가 투표했는지 알아야 할 때 이 API를 사용하세요.
페이지의 모든 설문 조사
페이지 전체에 대한 투표 목록은 제공되지 않습니다. 전체 페이지를 보고하려면 GET /api/v1/comments 로 해당 페이지의 댓글을 가져오세요. 이 호출은 각 댓글의 설문 조사와 그 카운트를 반환하며, 관심 있는 설문 조사에 대한 투표를 읽을 수 있습니다.
GET /api/v1/poll-votes/:id 
ID로 단일 설문 투표를 읽습니다.
익명 설문에 대한 투표는 읽을 수 없으며, 요청은 poll-anonymous 오류와 함께 실패합니다. 설문의 privacy 설정이 적용되는 방식은 PollVote 구조를 참조하십시오.



POST /api/v1/poll-votes 
설문에 대한 투표를 기록합니다.
투표자는 설문당 최대 하나의 투표만 할 수 있습니다. 동일한 투표자에 대해 이 API를 다시 호출하면 두 번째 투표를 추가하는 것이 아니라 기존 투표를 새로운 옵션으로 이동시킵니다, 그리고 이미 선택한 옵션에 다시 투표하면 아무 변화도 없습니다.
응답에 설문이 포함되어 있어 두 번째 요청 없이 업데이트된 투표 수를 확인할 수 있습니다.




익명 투표
anonUserId를 userId 대신 설정하여 로그인하지 않은 사용자의 투표를 기록합니다. 해당 ID는 어느 곳의 사용자와도 일치할 필요가
없으며 - 세션을 식별할 뿐이므로 같은 사람이 두 번 계산되지 않습니다.
사이트에서 익명 투표를 활성화해야 합니다. 투표가 로그인한 사용자에게만 제한된 경우, anonUserId만 포함된 투표는 poll-login-required
오류로 실패합니다.
익명 투표는 설문당 IP별로 속도 제한이 적용되어, 한 사람이 세션을 초기화하여 설문을 채우는 것을 방지합니다. 최종 사용자의 ip를 전송하면 제한이 서버가 아니라 해당 사용자에게 적용됩니다.
기타 참고 사항
userId는 사이트에 존재하는 사용자여야 합니다. 다른 사이트에 속한 사용자를 위한 투표는 거부됩니다.- 닫힌 설문에 대한 투표는
poll-closed오류로 실패합니다. - 이 API는 설문의 투표 수를 업데이트하고 연결된 위젯에 실시간으로 푸시합니다.
DELETE /api/v1/poll-votes/:id 
투표를 취소합니다. 투표가 이루어진 옵션의 카운트가 복원되며, 투표자는 다시 투표할 수 있습니다.



기타 참고 사항
- 동일한 투표를 두 번 삭제하면 두 번째 시도에서는
not-found응답이 반환되고, 카운트는 변경되지 않습니다. - 투표가 이루어진 이후에 설문이 교체된 경우, 투표는 제거되지만 카운트는 변하지 않으며, 교체는 0부터 시작했기 때문입니다.
PendingWebhookEvent 구조 
A PendingWebhookEvent 객체는 대기 중인 큐에 저장된 웹훅 이벤트를 나타냅니다.
PendingWebhookEvent 객체는 자동으로 생성되며 API를 통해 수동으로 생성할 수 없습니다. 또한 1년 후 만료됩니다.
큐에서 작업을 제거하는 삭제가 가능합니다.
이벤트 유형에는 여러 가지가 있습니다 - eventType (OutboundSyncEventType) 및 type (OutboundSyncType)을 확인하세요.
이 API의 일반적인 사용 사례 중 하나는 맞춤형 모니터링 구현입니다. 주기적으로 /count 엔드포인트를 호출하여 주어진 필터에 대한 미해결 수를 폴링할 수 있습니다.
PendingWebhookEvent 객체의 구조는 다음과 같습니다:

GET /api/v1/pending-webhook-events 
이 경로는 pendingWebhookEvents 매개변수 아래의 대기 중인 웹후크 이벤트 목록을 반환합니다.
이 API는 페이징을 사용하며, 이는 skip 매개변수로 제공됩니다. PendingWebhookEvents는 100개씩 페이지로 반환되며 createdAt을 기준으로 최신 순으로 정렬됩니다.



GET /api/v1/pending-webhook-events/count 
이 경로는 보류 중인 웹훅 이벤트 수를 count 매개변수로 포함한 객체를 반환합니다.
필터는 /pending-webhook-events 엔드포인트와 동일한 매개변수로 할 수 있습니다.



DELETE /api/v1/pending-webhook-events/:id 
이 경로는 단일 PendingWebhookEvent를 삭제할 수 있습니다.
대량 삭제가 필요한 경우, 페이징을 사용하여 GET API를 호출한 다음 이 API를 순차적으로 호출하세요.



SSOUser 구조 
FastComments는 사용하기 쉬운 SSO 솔루션을 제공합니다. HMAC 기반 통합으로 사용자의 정보를 업데이트하는 것은 사용자가 업데이트된 페이로드로 페이지를 로드하도록 하는 것만큼 간단합니다.
하지만 일관된 애플리케이션 관리를 위해 해당 흐름 외부에서 사용자를 관리하는 것이 바람직할 수 있습니다.
SSO 사용자 API는 우리가 SSOUsers라고 부르는 객체를 CRUD할 수 있는 방법을 제공합니다. 이 객체들은 일반 Users와 다르며 타입 안전성을 위해 분리되어 보관됩니다.
SSOUser 객체의 구조는 다음과 같습니다:

SSO 사용자 요금 청구
SSO 사용자는 권한 플래그에 따라 다르게 청구됩니다:
- 일반 SSO 사용자: 관리 또는 중재자 권한이 없는 사용자는 일반 SSO 사용자로 청구됩니다
- SSO 관리자:
isAccountOwner또는isAdminAdmin플래그가 있는 사용자는 SSO 관리자(일반 테넌트 관리자와 동일한 요율)로 별도 청구됩니다 - SSO 중재자:
isCommentModeratorAdmin플래그가 있는 사용자는 SSO 중재자(일반 중재자와 동일한 요율)로 별도 청구됩니다
중요: 이중 청구를 방지하기 위해 시스템은 이메일 주소로 SSO 사용자를 일반 테넌트 사용자 및 중재자와 자동으로 중복 제거합니다. SSO 사용자가 일반 테넌트 사용자 또는 중재자와 동일한 이메일을 가지고 있으면 두 번 청구되지 않습니다.
접근 제어
사용자는 그룹으로 나눌 수 있습니다. 이것이 groupIds 필드의 용도이며 선택 사항입니다.
@Mentions
기본적으로 @mentions는 @ 문자를 입력할 때 다른 SSO 사용자를 검색하기 위해 username을 사용합니다. displayName이 사용되면, displayName과 일치하는 결과가 있을 때 username과 일치하는 결과는 무시되며 @mention 검색 결과는 displayName을 사용합니다.
구독
FastComments에서는 사용자가 댓글 위젯의 종 모양 아이콘을 클릭하고 구독을 클릭하면 페이지를 구독할 수 있습니다.
일반 사용자와는 그들의 알림 설정에 따라 알림 이메일을 보냅니다.
SSO 사용자와 함께 우리는 이를 하위 호환성을 위해 분리합니다. 사용자는 optedInSubscriptionNotifications를 true로 설정한 경우에만 이러한 추가 구독 알림 이메일을 받습니다.
배지
badgeConfig 속성을 사용하여 SSO 사용자에게 배지를 할당할 수 있습니다. 배지는 댓글에서 사용자 이름 옆에 표시되는 시각적 표시기입니다.
badgeIds- 사용자에게 할당할 배지 ID 배열입니다. 이들은 모든 페이지에서 보이는 글로벌 배지입니다. FastComments 계정에서 생성된 유효한 배지 ID여야 합니다. 30개의 배지로 제한됩니다.pageBadgeIds- 현재 페이지(urlId)에 범위가 지정된 선택적 배지 ID 배열입니다. 이 배지들은 할당된 페이지에서만 표시됩니다. 서로 다른 페이지는 동일한 사용자에 대해 서로 다른 페이지 범위 배지를 가질 수 있습니다.override- true이면 기존에 표시된 모든 배지를 제공된 배지로 대체합니다. 글로벌 배지와 페이지 범위 배지는 독립적으로 덮어써지므로 글로벌 배지를 덮어써도 페이지 범위 배지에는 영향을 주지 않으며 그 반대도 마찬가지입니다. false이거나 생략된 경우 제공된 배지는 기존 배지에 추가됩니다.update- true이면 사용자가 로그인할 때마다 테넌트 구성에서 배지 표시 속성이 업데이트됩니다.
GET /api/v1/sso-users 
이 라우트는 SSO 사용자들을 페이지당 100개로 반환합니다. 페이지네이션은 skip 파라미터로 제공합니다. 사용자들은 signUpDate와 id로 정렬됩니다.



GET /api/v1/sso-users/by-id/:id 
이 경로는 사용자 ID로 단일 SSO 사용자를 반환합니다.



GET /api/v1/sso-users/by-email/:email 
이 경로는 이메일로 단일 SSO 사용자를 반환합니다.



PATCH /api/v1/sso-users/:id 
이 경로는 단일 SSO 사용자를 업데이트할 수 있는 기능을 제공합니다.



POST /api/v1/sso-users 
이 라우트는 단일 SSO 사용자의 생성을 제공합니다.
동일한 ID로 두 명의 사용자를 생성하려고 하면 오류가 발생합니다.

이 예제에서는 접근 제어를 위해 groupIds를 지정하지만, 이는 선택 사항입니다.


통합 참고 사항
API를 통해 전달된 데이터는 다른 SSO 사용자 HMAC 페이로드를 전달하는 것만으로 간단히 재정의할 수 있습니다. 예를 들어, API를 통해 사용자 이름을 설정한 후, 페이지 로드 시 SSO 흐름을 통해 다른 사용자 이름을 전달하면 자동으로 해당 사용자의 사용자 이름이 업데이트됩니다.
이 흐름에서는 사용자 매개변수를 명시적으로 지정하거나 null로 설정하지 않는 한( undefined가 아닌 경우) 업데이트하지 않습니다.
PUT /api/v1/sso-users/:id 
이 경로는 단일 SSO 사용자를 업데이트할 수 있는 기능을 제공합니다.

이 예에서는 접근 제어를 위해 groupIds를 지정하지만, 이는 선택 사항입니다.


DELETE /api/v1/sso-users/:id 
이 라우트는 id로 단일 SSO 사용자를 제거합니다.
이 사용자의 페이로드로 댓글 위젯을 다시 로드하면 사용자가 원활하게 재생성됩니다.
사용자의 댓글을 삭제하려면 deleteComments 쿼리 매개변수를 통해 가능합니다. 이 값이 true인 경우에 유의하세요:
- 사용자의 모든 댓글이 실시간으로 삭제됩니다.
- 모든 child (이제 고아가 된) 댓글은 각 댓글의 연관된 페이지 설정에 따라 삭제되거나 익명화됩니다. 예를 들어 스레드 삭제 모드가 "anonymize"이면 답글은 남아 있고 사용자의 댓글만 익명화됩니다. 이는
commentDeleteMode가Remove(기본값)일 때만 적용됩니다. creditsCost는2가 됩니다.
익명화된 댓글
사용자의 댓글을 유지하되 commentDeleteMode=1로 설정하여 간단히 익명화할 수 있습니다.
사용자의 댓글이 익명화되면 다음 값들이 null로 설정됩니다:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badges
isDeleted 및 isDeletedUser는 true로 설정됩니다.
렌더링 시 댓글 위젯은 사용자의 이름에 DELETED_USER_PLACEHOLDER (기본값: "[deleted]")을, 댓글에는 DELETED_CONTENT_PLACEHOLDER를 사용합니다. 이는 Widget Customization UI에서 사용자화할 수 있습니다.
예제



Subscription 구조 
Subscription 객체는 사용자의 구독을 나타냅니다.
Subscription 객체는 사용자가 댓글 위젯의 알림 벨을 클릭하고 "이 페이지 구독"을 클릭할 때 생성됩니다.
구독은 API를 통해서도 생성할 수 있습니다.
Subscription 객체가 있으면 연관된 페이지의 루트에 새 댓글이 남겨질 때
해당 Subscription의 대상인 페이지에 대해 Notification 객체가 생성되고 이메일이 전송됩니다. 이메일 전송은 사용자 유형에 따라 달라집니다. 일반 사용자에게는 optedInNotifications에 따라 결정됩니다. SSO 사용자에게는 optedInSubscriptionNotifications에 따라 결정됩니다. 일부 애플리케이션은 웹에서 접근 가능한 페이지 개념이 없을 수 있으므로, 그런 경우 구독하려는 항목의 id(댓글 위젯에 전달할 urlId와 동일한 값)를 urlId에 설정하면 됩니다.
Subscription 객체의 구조는 다음과 같습니다:

GET /api/v1/subscriptions/:id 
이 경로는 createdAt 기준으로 정렬된 최신순으로 최대 30개의 Subscription 객체를 반환합니다.
userId로 필터링할 수 있습니다. SSO를 사용하는 경우 사용자 ID는 <tenant id>:<user id> 형식입니다.



POST /api/v1/subscriptions 
이 API 엔드포인트는 Subscription을 생성하는 기능을 제공합니다. 사용자는 페이지당 하나의 구독만 가질 수 있다는 점에 유의하세요. 이는 중복되므로, 그리고
동일한 사용자와 동일한 페이지에 대해 둘 이상의 구독을 생성하려고 하면 오류가 발생합니다.
구독을 생성하면, 구독된 urlId의 루트에 새 댓글이 남겨질 때(댓글의 parentId가 null인 경우) Notification 객체가 생성됩니다.



DELETE /api/v1/subscriptions/:id 
이 경로는 id로 단일 Subscription 객체를 삭제합니다.



TenantDailyUsage 구조 
TenantDailyUsage 객체는 특정 날짜의 테넌트 사용량을 나타냅니다. 특정 날짜에 테넌트의 활동이 없었다면, 그 날짜에는 TenantDailyUsage 객체가 존재하지 않습니다.
TenantDailyUsage 객체는 실시간이 아니며, 실제 사용량보다 몇 분 늦을 수 있습니다.
TenantDailyUsage 객체의 구조는 다음과 같습니다:

GET /api/v1/tenant-daily-usage 
이 라우트는 연, 월, 일 단위로 테넌트의 사용량을 검색할 수 있게 해줍니다. 최대 365개의 객체를 반환할 수 있으며, 비용은 10개 객체당 1 api credit입니다.
응답 객체는 생성된 날짜순으로 정렬됩니다(가장 오래된 것이 먼저).



Tenant 구조 
Tenant는 FastComments.com의 고객을 정의합니다. 화이트 라벨링 권한이 있는 테넌트는 API를 통해 생성할 수 있습니다. 화이트 라벨 테넌트는 다른 화이트 라벨 테넌트를 생성할 수 없습니다(중첩은 한 단계만 허용됩니다).
다음은 Tenant 객체의 구조입니다:

GET /api/v1/tenants/:id 
이 경로는 ID로 단일 Tenant를 반환합니다.



GET /api/v1/tenants 
이 API는 귀하의 테넌트가 관리하는 테넌트를 반환합니다.
페이지네이션은 skip 쿼리 매개변수로 제공됩니다. 테넌트는 signUpDate 및 id로 정렬되어 100개 단위의 페이지로 반환됩니다.
비용은 반환된 테넌트 수에 따라 결정되며, 반환된 테넌트 10개당 1 credit per 10가 발생합니다.

Tenant 객체에 meta 매개변수를 정의하고 일치하는 테넌트를 쿼리할 수 있습니다. 예를 들어, 키가 someKey이고 메타 값이 some-value인 경우, 이 키/값 쌍으로 JSON 객체를 구성한 다음 이를 쿼리 파라미터로 URI 인코딩하여 필터할 수 있습니다:



POST /api/v1/tenants 
이 라우트는 단일 Tenant를 추가하는 기능을 제공합니다.
Tenant를 생성할 때 다음과 같은 제한이 있습니다:
name은 필수입니다.domainConfiguration은 필수입니다.Tenant를 생성할 때 다음 값들은 제공할 수 없습니다:hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmount
signUpDate는 미래 날짜일 수 없습니다.name은200 characters를 초과할 수 없습니다.email은300 characters를 초과할 수 없습니다.email은 FastComments.com의 모든 테넌트에서 고유해야 합니다.- 부모 테넌트에 유효한
TenantPackage가 정의되어 있지 않으면 테넌트를 생성할 수 없습니다.- 테넌트가 FastComments.com을 통해 생성된 경우 이는 문제가 되지 않습니다.
- 패키지에 정의된
maxWhiteLabeledTenants보다 많은 테넌트를 생성할 수 없습니다. - 화이트 라벨링이 활성화된
parent tenant의 id인tenantId쿼리 파라미터를 반드시 지정해야 합니다.
우리는 몇 가지 파라미터만으로 Tenant를 생성할 수 있습니다:



PATCH /api/v1/tenants/:id 
이 API 엔드포인트는 id 로 Tenant 를 업데이트할 수 있는 기능을 제공합니다.
Tenant 를 업데이트할 때는 다음 제한 사항이 있습니다:
- 다음 값은 업데이트할 수 없습니다:
hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmountmanagedByTenantId
signUpDate은 미래일 수 없습니다.name은200 characters보다 길 수 없습니다.email은300 characters보다 길 수 없습니다.email은 FastComments.com 모든 테넌트에서 고유해야 합니다.billingInfoValid를true로 설정할 때, 동일한 요청에billingInfo를 제공해야 합니다.- 자신의 테넌트와 연결된
packageId를 업데이트할 수 없습니다. - 자신의 테넌트와 연결된
paymentFrequency를 업데이트할 수 없습니다.



DELETE /api/v1/tenants/:id 
이 경로는 id로 Tenant 및 연관된 모든 데이터 (사용자, 댓글 등)를 제거합니다.
다음과 같은 테넌트 제거에 대한 제한이 있습니다:
- 해당 테넌트는 귀하의 것이어야 하거나, 귀하가 관리하는 화이트라벨 테넌트여야 합니다.
- 쿼리 매개변수
sure는true로 설정되어 있어야 합니다.



Tenant Package 구조 
TenantPackage는 Tenant에 제공되는 패키지 정보를 정의합니다. 테넌트는 여러 패키지를 사용할 수 있지만, 주어진 시점에는 하나만 사용할 수 있습니다.
Tenant의 packageId가 유효한 TenantPackage를 가리키기 전까지는 어떤 제품에도 사용할 수 없습니다.
TenantPackage 객체에는 두 가지 유형이 있습니다:
- 고정 가격 패키지 -
hasFlexPricing이 false인 경우. - 유연한 가격 책정 -
hasFlexPricing이 true인 경우.
두 경우 모두 패키지를 사용하는 계정에 한도가 정의되지만, Flex의 경우 테넌트는 기본 가격에 flex* 매개변수로 정의된 사용량만큼 추가로 청구됩니다.
테넌트는 여러 테넌트 패키지를 가질 수 있으며, 청구 정보 페이지에서 직접 패키지를 변경할 수 있습니다.
테넌트의 청구를 직접 처리할 경우에도 각 테넌트의 한도를 정의하기 위해 패키지를 정의해야 합니다. Tenant에서 billingHandledExternally를 true로 설정하기만 하면, 테넌트가 직접 청구 정보나 활성 패키지를 변경할 수 없게 됩니다.
부모 테넌트보다 높은 한도를 가진 패키지는 생성할 수 없습니다.
TenantPackage 객체의 구조는 다음과 같습니다:

GET /api/v1/tenant-packages/:id 
이 라우트는 id로 단일 Tenant Package를 반환합니다.



GET /api/v1/tenant-packages 
이 API는 페이징을 사용하며, skip 쿼리 매개변수로 제공됩니다. TenantPackages는 100개 단위로 페이지별로 반환되며, createdAt 및 id로 정렬됩니다.
비용은 반환되는 tenant packages 수를 기준으로 하며, 반환되는 tenant packages 10개당 1 credit per 10가 소요됩니다.



POST /api/v1/tenant-packages 
이 라우트는 단일 TenantPackage를 추가할 수 있는 기능을 제공합니다.
TenantPackage 생성에는 다음과 같은 제한 사항이 있습니다:
- 다음 매개변수가 필요합니다:
nametenantIdmonthlyCostUSD- null일 수 있습니다.yearlyCostUSD- null일 수 있습니다.maxMonthlyPageLoadsmaxMonthlyAPICreditsmaxMonthlyCommentsmaxConcurrentUsersmaxTenantUsersmaxSSOUsersmaxModeratorsmaxDomainshasDebrandingforWhoTextfeatureTaglineshasFlexPricing- true이면 모든flex*매개변수가 필요합니다.
name은50 characters보다 길 수 없습니다.- 각
forWhoText항목은200 characters보다 길 수 없습니다. - 각
featureTaglines항목은100 characters보다 길 수 없습니다. TenantPackage는 부모 테넌트보다 "작아야" 합니다. 예를 들어 모든max*매개변수는 부모 테넌트보다 낮은 값을 가져야 합니다.- 화이트 라벨링된 테넌트는 최대 다섯 개의 패키지를 가질 수 있습니다.
- 화이트 라벨링 접근 권한이 있는 테넌트만
TenantPackage를 생성할 수 있습니다. - 자신의 테넌트에는 패키지를 추가할 수 없습니다. :)
다음과 같이 TenantPackage를 생성할 수 있습니다:



PATCH /api/v1/tenant-packages/:id 
이 API 엔드포인트는 id로 TenantPackage를 업데이트하는 기능을 제공합니다.
TenantPackage를 업데이트할 때 다음 제한 사항이 적용됩니다:
hasFlexPricing를 true로 설정하는 경우, 같은 요청에서 모든flex*매개변수가 필요합니다.name은50 characters보다 길 수 없습니다.- 각
forWhoText항목은200 characters보다 길 수 없습니다. - 각
featureTaglines항목은100 characters보다 길 수 없습니다. TenantPackage는 상위 테넌트보다 "작아야" 합니다. 예를 들어, 모든max*매개변수는 상위 테넌트보다 낮은 값을 가져야 합니다.TenantPackage에 연결된tenantId는 변경할 수 없습니다.



DELETE /api/v1/tenant-packages/:id 
이 경로는 id로 TenantPackage를 삭제합니다.
사용 중인 TenantPackage(테넌트의 packageId가 해당 패키지를 가리키는 경우)는 삭제할 수 없습니다. 먼저 Tenant를 업데이트하세요.



Tenant User 구조 
The TenantUser는 특정 테넌트에 의해 관리되는 User를 정의합니다. 해당 계정은 연관된 테넌트가 완전히 제어하며, 계정은 UI 또는 API를 통해 업데이트하거나 삭제할 수 있습니다.
테넌트 사용자는 Tenant에 대한 모든 권한과 접근을 가진 관리자일 수 있거나, 댓글을 관리하고 API 키에 접근하는 등 특정 권한만 제한적으로 가질 수 있습니다.
TenantUser 객체의 구조는 다음과 같습니다:

GET /api/v1/tenant-users/:id 
이 경로는 id로 단일 TenantUser를 반환합니다.



GET /api/v1/tenant-users 
이 API는 페이지네이션을 사용하며, skip 쿼리 매개변수로 제공됩니다. TenantUsers는 100개 단위의 페이지로 반환되며 signUpDate, username 및 id 순으로 정렬됩니다.
비용은 반환되는 tenant users 수를 기준으로 계산되며, 반환되는 tenant users 10명당 1 credit이 소모됩니다.



POST /api/v1/tenant-users 
이 라우트는 단일 TenantUser를 추가하는 기능을 제공합니다.
TenantUser를 생성할 때 다음과 같은 제한이 있습니다:
username은 필수입니다.email은 필수입니다.signUpDate는 미래일 수 없습니다.locale은 Supported Locales 목록에 있어야 합니다.username은 FastComments.com 전체에서 고유해야 합니다. 문제가 발생하면 대신 SSO 사용을 권장합니다.email은 FastComments.com 전체에서 고유해야 합니다. 문제가 발생하면 대신 SSO 사용을 권장합니다.- 패키지에 정의된
maxTenantUsers보다 더 많은 테넌트 사용자를 생성할 수 없습니다.
다음과 같이 TenantUser를 생성할 수 있습니다



POST /api/v1/tenant-users/:id/send-login-link 
이 경로는 단일 TenantUser에게 로그인 링크를 보낼 수 있는 기능을 제공합니다.
사용자들을 일괄 생성할 때 그들에게 FastComments.com에 로그인하는 방법을 안내할 필요가 없을 때 유용합니다. 이는 만료 기간이 30 days인 "매직 링크"를 전송합니다.
TenantUser에게 로그인 링크를 보내기 위해 다음과 같은 제한이 있습니다:
TenantUser는 이미 존재해야 합니다.TenantUser가 속한Tenant를 관리할 수 있는 권한이 있어야 합니다.
다음과 같이 TenantUser에게 로그인 링크를 보낼 수 있습니다:

이것은 Bob at TenantName is inviting you to be a moderator... 같은 이메일을 보냅니다.


PATCH /api/v1/tenant-users/:id 
이 라우트는 단일 TenantUser를 업데이트하는 기능을 제공합니다.
TenantUser 업데이트에는 다음과 같은 제한이 있습니다:
signUpDate는 미래일 수 없습니다.locale는 지원되는 로케일 목록에 있어야 합니다.username은 FastComments.com 전체에서 고유해야 합니다. 문제가 되는 경우 대신 SSO 사용을 권장합니다.email은 FastComments.com 전체에서 고유해야 합니다. 문제가 되는 경우 대신 SSO 사용을 권장합니다.- 사용자의
tenantId는 업데이트할 수 없습니다.
다음과 같이 TenantUser를 생성할 수 있습니다



DELETE /api/v1/tenant-users/:id 
이 라우트는 id로 TenantUser를 삭제하는 기능을 제공합니다.
deleteComments 쿼리 파라미터를 통해 사용자의 댓글을 삭제할 수 있습니다. 이 값이 true인 경우 다음에 유의하세요:
- 사용자의 모든 댓글이 실시간으로 삭제됩니다.
- 모든 자식 (이제 고아가 된) 댓글은 각 댓글에 연결된 페이지 설정에 따라 삭제되거나 익명화됩니다. 예를 들어 스레드 삭제 모드가 "anonymize"인 경우 답글은 남아 있고 사용자의 댓글은 익명화됩니다. 이는
commentDeleteMode가Remove(기본값)일 때만 적용됩니다. creditsCost가2가 됩니다.
익명화된 댓글
commentDeleteMode=1로 설정하면 사용자의 댓글을 유지하면서 단순히 익명화할 수 있습니다.
사용자의 댓글이 익명화되면 다음 값들이 null로 설정됩니다:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badges
isDeleted와 isDeletedUser는 true로 설정됩니다.
렌더링 시 댓글 위젯은 사용자 이름에 DELETED_USER_PLACEHOLDER(기본값: "[deleted]")를, 댓글 내용에 DELETED_CONTENT_PLACEHOLDER를 사용합니다. 이는 위젯 커스터마이제이션 UI를 통해 사용자 정의할 수 있습니다.
예제



User 구조 
User는 모든 사용자들의 공통 분모를 나타내는 객체입니다.
FastComments에서는 사용자에 대한 여러 가지 다른 사용 사례가 있다는 점을 염두에 두세요:
- Secure SSO
- Simple SSO
- Tenant Users (For example: Administrators)
- Commenters
이 API는 Commenters 및 Simple SSO를 통해 생성된 사용자들을 위한 것입니다. 기본적으로 사이트를 통해 생성된 모든 사용자는 이 API로 접근할 수 있습니다. Tenant Users도 이렇게 가져올 수 있지만, /tenant-users/ API와 상호작용하면 더 많은 정보를 얻을 수 있습니다.
Secure SSO의 경우에는 /sso-users/ API를 사용하세요.
이 유형의 사용자는 업데이트할 수 없습니다. 이들은 귀하의 사이트를 통해 계정을 생성했기 때문에 일부 읽기 전용 기본 액세스만 제공되며 변경은 할 수 없습니다. 이런 흐름을 원하시면 Secure SSO를 설정해야 합니다.
User 객체의 구조는 다음과 같습니다:

GET /api/v1/users/:id 
이 라우트는 id로 단일 User를 반환합니다.



Vote 구조 
Vote 객체는 사용자가 남긴 투표를 나타냅니다.
댓글과 투표 간의 관계는 commentId로 정의됩니다.
Vote 객체의 구조는 다음과 같습니다:

GET /api/v1/votes 
투표는 urlId로 가져와야 합니다.
투표 유형
투표에는 세 가지 유형이 있습니다:
- 인증된 투표(Authenticated Votes)는 해당 댓글에 적용됩니다. 이 API를 통해 생성할 수 있습니다.
- 인증된 투표(Authenticated Votes) 중 검증 대기(pending) 상태인 투표는 아직 댓글에 적용되지 않았습니다. 사용자가 FastComments.com의 login to vote 메커니즘을 사용할 때 생성됩니다.
- 익명 투표(Anonymous Votes)는 해당 댓글에 적용됩니다. 익명 댓글 작성과 함께 생성됩니다.
혼동을 줄이기 위해 API는 이를 별도의 목록으로 반환합니다.



익명 투표 참고
이 API를 통해 생성된 익명 투표는 appliedAuthorizedVotes 목록에 나타납니다. API 키로 API를 통해 생성되었기 때문에 권한이 부여된 것으로 간주됩니다.
appliedAnonymousVotes 구조는 이메일, API 키 등이 없이 생성된 투표에 대한 것입니다.
GET /api/v1/votes/for-user 
지정된 urlId에 대해 사용자가 남긴 투표를 가져올 수 있습니다. userId는 FastComments.com의 사용자 또는 SSO User가 될 수 있습니다.
이는 사용자가 댓글에 투표했는지 보여주려는 경우에 유용합니다. 댓글을 가져올 때 동일한 urlId로 사용자에 대해 이 API를 함께 호출하면 됩니다.
익명 투표를 사용하는 경우 대신 anonUserId를 전달하세요.


익명 투표는 appliedAuthorizedVotes 목록에 표시됩니다. 이들은 API 키로 API를 통해 생성되었기 때문에 권한이 있는 것으로 간주됩니다.


POST /api/v1/votes 
이 라우트는 단일 인증된 Vote를 추가하는 기능을 제공합니다. 투표는 up(+1) 또는 down(-1)일 수 있습니다.




익명 투표 생성하기
쿼리 파라미터에서 userId 대신 anonUserId를 설정하여 익명 투표를 생성할 수 있습니다.
이 ID는 어디에도 사용자 객체와 연결될 필요가 없습니다(익명이므로). 단순히 세션을 위한 식별자로, 같은 세션에서 투표를 다시 조회하여 댓글에 투표했는지 확인할 수 있습니다.
FastComments처럼 "익명 세션"과 같은 개념이 없다면, UUID와 같은 무작위 ID를 설정하면 됩니다(공간 절약을 위해 더 짧은 식별자를 권장합니다).
기타 참고 사항
- 이 API는 테넌트 수준 설정을 따릅니다. 예를 들어, 특정 페이지에 대해 투표를 비활성화한 상태에서 API를 통해 투표를 생성하려고 하면
voting-disabled오류 코드와 함께 실패합니다. - 이 API는 기본적으로 실시간입니다.
- 이 API는 해당
Comment의votes를 업데이트합니다.
DELETE /api/v1/votes/:id 
이 라우트는 단일 Vote를 삭제할 수 있는 기능을 제공합니다.



Notes:
- 이 API는 테넌트 수준 설정을 따릅니다. 예를 들어 특정 페이지에서 투표를 비활성화한 상태에서 API를 통해 투표를 생성하려고 하면 오류 코드
voting-disabled로 실패합니다. - 이 API는 기본적으로 라이브 상태입니다.
- 이 API는 해당
Comment의votes를 업데이트합니다.
DomainConfig 구조 
DomainConfig 객체는 테넌트의 도메인에 대한 구성을 나타냅니다.
DomainConfig 객체의 구조는 다음과 같습니다:


인증 관련
도메인 구성은 귀하의 계정에 대해 어떤 사이트가 FastComments 위젯을 호스팅할 수 있는지 결정하는 데 사용됩니다. 이는 기본적인 인증 형태로, 도메인 구성을 추가하거나 제거하면 프로덕션 환경에서 FastComments 설치의 가용성에 영향을 줄 수 있습니다.
해당 도메인을 비활성화하려는 의도가 없다면, 현재 사용 중인 도메인의 Domain Config에서 domain 속성을 제거하거나 업데이트하지 마십시오.
이는 /auth/my-account/configure-domains에서 도메인을 제거하는 것과 동일한 동작을 합니다.
또한 My Domains UI에서 도메인을 제거하면 이 UI를 통해 추가된 해당 도메인의 관련 구성도 함께 제거된다는 점에 유의하십시오.
이메일 사용자 정의 관련
이메일 푸터의 수신 거부 링크와 많은 이메일 클라이언트에서 제공하는 원클릭 수신 거부 기능은 각각 footerUnsubscribeURL과 emailHeaders를 정의하여 이 API를 통해 구성할 수 있습니다.
DKIM 관련
DKIM DNS 레코드를 정의한 후, 정의된 구조를 사용하여 DKIM 구성으로 DomainConfig를 업데이트하기만 하면 됩니다.
GET /api/v1/domain-configs 
이 API는 테넌트의 모든 DomainConfig 객체를 가져오는 기능을 제공합니다.



GET /api/v1/domain-configs/:domain 
개별 DomainConfig는 해당 domain으로 가져올 수 있습니다.



POST /api/v1/domain-configs 
이 API 엔드포인트는 도메인 구성을 생성하는 기능을 제공합니다.
도메인에 대한 구성을 추가하면 해당 도메인이 FastComments 계정에 대해 인증됩니다.
이 API의 일반적인 사용 사례로는 초기 설정, 여러 도메인을 추가하려는 경우, 또는 이메일 발송을 위한 맞춤 구성 등이 있습니다.



PATCH /api/v1/domain-configs/:domain 
이 API 엔드포인트는 도메인과 업데이트할 속성만 지정하여 도메인 구성을 업데이트할 수 있는 기능을 제공합니다.



PUT /api/v1/domain-configs/:domain 
이 API 엔드포인트는 도메인 구성을 교체할 수 있는 기능을 제공합니다.



DELETE /api/v1/domain-configs/:domain 
이 경로는 단일 DomainConfig를 id로 제거합니다.
- 참고:
DomainConfig를 제거하면 해당 도메인이 FastComments 사용 권한을 상실합니다. - 참고: UI를 통해 도메인을 다시 추가하면 객체가 재생성됩니다(단
domain만 채워집니다).



QuestionConfig 구조 
FastComments는 질문을 구성하고 그 결과를 집계하는 방법을 제공합니다. 질문의 예(이하 QuestionConfig라고 함)는 별점, 슬라이더, 또는 NPS 질문(type에 의해 결정될 수 있음)이 될 수 있습니다.
질문 데이터는 개별적으로, 함께, 시간 경과에 따라, 전체적으로, 페이지별로 등으로 집계할 수 있습니다.
이 프레임워크는 클라이언트 측 위젯(이 API 앞에 서버를 두는 방식), 관리자 대시보드 및 리포팅 도구를 구축하는 데 필요한 모든 기능을 제공합니다.
먼저 QuestionConfig를 정의해야 합니다. 구조는 다음과 같습니다:

GET /api/v1/question-configs 
이 경로는 한 번에 페이징된 최대 100개의 QuestionConfig 객체를 반환합니다. 비용은 100개당 1입니다. 그들은
질문 텍스트 오름차순(question 필드)으로 정렬됩니다.



GET /api/v1/question-configs/:id 
이 경로는 id로 단일 QuestionConfig를 반환합니다.



POST /api/v1/question-configs 
이 API 엔드포인트는 QuestionConfig를 생성하는 기능을 제공합니다.



PATCH /api/v1/question-configs/:id 
이 경로는 단일 QuestionConfig를 업데이트하는 기능을 제공합니다.
다음 구조는 변경 가능한 모든 값을 나타냅니다:




DELETE /api/v1/question-configs/:id 
이 경로는 id로 QuestionConfig를 제거합니다.
이 작업은 모든 해당 질문 결과를 삭제합니다(댓글은 삭제되지 않습니다). 이것은 높은 크레딧 비용의 일부입니다.



QuestionResult 구조 
질문에 대한 결과를 저장하려면 QuestionResult를 생성합니다. 그런 다음 질문 결과를 집계할 수 있고, 또한
보고 목적을 위해 댓글에 연결할 수도 있습니다.

GET /api/v1/question-results 
이 라우트는 한 번에 최대 1000개의 QuestionResults 객체를 페이지네이션된 형태로 반환합니다. 비용은 100개당 1입니다. 결과는 createdAt 기준 오름차순으로 정렬됩니다. 다양한 매개변수로 필터링할 수 있습니다.



GET /api/v1/question-results/:id 
이 경로는 id로 단일 QuestionResult를 반환합니다.



POST /api/v1/question-results 
이 API 엔드포인트는 QuestionResult를 생성할 수 있는 기능을 제공합니다.



PATCH /api/v1/question-results/:id 
이 경로는 단일 QuestionResult를 업데이트할 수 있는 기능을 제공합니다.
다음 구조는 변경할 수 있는 모든 값을 나타냅니다:




DELETE /api/v1/question-results/:id 
이 경로는 id로 QuestionResult를 삭제합니다.



GET /api/v1/question-results-aggregate 
여기서 결과 집계가 이루어집니다.
집계 응답 구조는 다음과 같습니다:

집계에 사용할 수 있는 쿼리 파라미터는 다음과 같습니다:

요청 예시는 다음과 같습니다:

응답 예시:


성능 참고 사항
- 캐시 미스 시 집계는 일반적으로 백만 개의 결과당 약 5초가 걸립니다.
- 그 외의 경우 요청은 일정한 시간 내에 처리됩니다.
캐싱 및 비용 참고 사항
forceRecalculate가 지정되면 비용은 일반적인2대신 항상10입니다.- 캐시가 만료되어 데이터가 재계산되더라도,
forceRecalculate가 지정되지 않은 경우 비용은 여전히 일정하게2입니다. 캐시는 집계된 데이터 세트 크기에 따라 만료됩니다(30초에서 5분 사이로 변동 가능). - 이는 캐시 사용을 장려하기 위한 것입니다.
GET /api/v1/question-results-aggregate/combine/comments 
결과와 댓글을 결합하는 기능이 제공되는 엔드포인트입니다. 예를 들어 제품에 대한 "최근 긍정 및 부정 댓글" 차트를 만드는 데 유용합니다.
값의 범위(포함), 하나 이상의 질문, 그리고 시작 날짜(포함)로 검색할 수 있습니다.
응답 구조는 다음과 같습니다:

다음은 집계를 위한 쿼리 매개변수입니다:

다음은 예시 요청입니다:

다음은 예시 응답입니다:


캐싱 및 비용 관련 주의사항
forceRecalculate가 지정된 경우 비용은 일반적인2대신 항상10입니다.- 캐시가 만료되어 데이터가 재계산되는 경우에도,
forceRecalculate가 지정되지 않았다면 비용은 여전히 고정된2입니다. - 이는 캐시 사용을 장려하기 위한 조치입니다.
UserBadge 구조 
UserBadge는 FastComments 시스템에서 사용자에게 할당된 배지를 나타내는 객체입니다.
배지는 사용자의 활동(댓글 수, 답변 시간, 베테랑 상태 등)에 따라 자동으로 할당되거나 사이트 관리자가 수동으로 할당할 수 있습니다.
UserBadge 객체의 구조는 다음과 같습니다:

GET /api/v1/user-badges 
이 엔드포인트를 통해 다양한 기준으로 사용자 배지를 가져올 수 있습니다.
예제 요청:
Run 
다음과 같은 쿼리 매개변수를 추가하여 결과를 필터링할 수 있습니다:
userId- 특정 사용자의 배지를 가져옵니다badgeId- 특정 배지의 인스턴스를 가져옵니다type- 배지 유형으로 필터링 (0=CommentCount, 1=CommentUpVotes, 2=CommentReplies, etc. See UserBadge structure for full list)displayedOnComments- 배지가 댓글에 표시되는지 여부로 필터링 (true/false)limit- 반환할 배지의 최대 수 (기본값 30, 최대 200)skip- 건너뛸 배지 수 (페이지네이션용)
예제 응답:

가능한 오류 응답:


GET /api/v1/user-badges/:id 
이 엔드포인트는 고유 ID로 특정 사용자 배지를 가져올 수 있게 합니다.
Example Request:
Run 
Example Response:

Possible Error Responses:


POST /api/v1/user-badges 
이 엔드포인트를 통해 새로운 사용자 배지 할당을 생성할 수 있습니다.
요청 예제:
Run 
요청 본문에는 다음 매개변수가 포함되어야 합니다:
userId(required) - 배지를 할당할 사용자의 IDbadgeId(required) - 할당할 배지의 IDdisplayedOnComments(optional) - 배지가 사용자의 댓글에 표시될지 여부 (기본값: true)
중요 참고사항:
- 배지는 테넌트의 배지 카탈로그에 존재하고 활성화되어 있어야 합니다
- 배지는 귀하의 테넌트에 속해 있거나 귀하의 사이트에 댓글을 남긴 사용자에게만 할당할 수 있습니다
응답 예제:

가능한 오류 응답:





PUT /api/v1/user-badges/:id 
이 엔드포인트는 사용자 배지 할당을 업데이트할 수 있도록 합니다.
현재 업데이트할 수 있는 유일한 속성은 displayedOnComments이며, 이 속성은 배지가 사용자의 댓글에 표시되는지 여부를 제어합니다.
Example Request:
Run 
Example Response:

Possible Error Responses:



DELETE /api/v1/user-badges/:id 
이 엔드포인트를 통해 사용자 배지 할당을 삭제할 수 있습니다.
요청 예시:
Run 
응답 예시:

가능한 오류 응답:



UserBadgeProgress 구조 
UserBadgeProgress는 FastComments 시스템에서 사용자가 다양한 배지를 획득하기 위한 진행 상황을 나타내는 객체입니다.
이 추적은 커뮤니티에서 사용자의 활동과 참여를 기반으로 사용자가 자동 배지를 받아야 하는 시점을 결정하는 데 도움이 됩니다.
UserBadgeProgress 객체의 구조는 다음과 같습니다:

GET /api/v1/user-badge-progress 
이 엔드포인트는 다양한 기준에 따라 사용자 배지 진행 기록을 가져올 수 있게 해줍니다.
예제 요청:
Run 
결과를 필터링하기 위해 다양한 쿼리 파라미터를 추가할 수 있습니다:
userId- 특정 사용자의 진행 상황을 가져옵니다limit- 반환할 최대 레코드 수 (기본값 30, 최대 200)skip- 건너뛸 레코드 수 (페이지네이션용)
예제 응답:

가능한 오류 응답:


GET /api/v1/user-badge-progress/:id 
이 엔드포인트를 사용하면 고유 ID로 특정 사용자 배지 진행 기록을 가져올 수 있습니다.
요청 예시:
Run 
응답 예시:

가능한 오류 응답:


GET /api/v1/user-badge-progress/user/:userId 
이 엔드포인트를 사용하면 사용자 ID로 사용자의 배지 진행 기록을 가져올 수 있습니다.
요청 예제:
Run 
응답 예제:

가능한 오류 응답:



결론
저희 API 문서가 포괄적이고 이해하기 쉬웠기를 바랍니다. 누락된 부분이 있다면 아래에 알려주세요.