
언어 🇰🇷 한국어
API 리소스
집계
감사 로그
댓글
이메일 템플릿
해시태그
모더레이터
알림 카운트
알림
페이지
보류 중인 웹훅 이벤트
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 키를 X-API-KEY 헤더 또는 API_KEY 쿼리 매개변수로 전달하여 인증합니다. 또한 API 호출을 위해 tenantId가 필요합니다. 이 값은 API 키와 동일한 페이지에서 확인할 수 있습니다.
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
자신의 작성 내용 읽기
FastComments는 Active-Active 가용성을 제공합니다. 데이터센터에서 보내는 요청은 자동으로 귀하의 위치에 가장 가까운 the nearest point of presence로 라우팅됩니다. 이는 자동으로 이루어지며, 보통은 자신의 쓰기(작성)를 읽는 동작을 관찰할 수 있습니다. 자신의 작성 내용을 확실히 읽고 싶다면 해당 리전을 API 호스트로 사용하여 요청을 특정 리전에 고정(pinning)할 수 있습니다(그러나 대부분의 통합에서는 보통 필요하지 않습니다):
- 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
참고: 이렇게 할 경우 과거에 엔트리포인트 노드를 더 이상 사용하지 않게(deprecated)하고 전환 시 새 이름을 사용한 사례가 있으므로 페일백(fallback)을 정의하는 것이 좋습니다.
API 리소스 
리소스 사용량
API에서 데이터를 가져오는 것은 귀하의 계정 사용량으로 집계된다는 점을 유의해야 합니다.
각 리소스는 해당 사용량을 자체 섹션에 나열합니다.
일부 리소스는 다른 리소스보다 제공 비용이 더 높습니다. 각 엔드포인트는 API 호출당 고정된 크레딧 비용을 가집니다. 일부 엔드포인트의 경우 옵션 및 응답 크기에 따라 필요한 크레딧 수가 달라집니다.
API 사용량은 청구 분석 페이지에서 확인할 수 있으며, 몇 분마다 업데이트됩니다.
참고!
혼란을 줄이기 위해 urlId에 전달할 값을 결정할 때 먼저 Pages 문서를 읽어보시길 권장합니다.
데이터 집계 
이 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 객체의 구조는 다음과 같습니다:

감사 로그는 불변입니다. 수동으로 쓸 수도 없습니다. FastComments.com만 감사 로그에 기록할 시점을 결정할 수 있습니다. 그러나 이 API를 통해 감사 로그를 읽을 수 있습니다.
이 감사 로그의 이벤트는 2년 후에 만료됩니다.
GET /api/v1/audit-logs 
이 API는 skip, before, after 매개변수로 제공되는 페이지네이션을 사용합니다. AuditLogs는 when과 id로 정렬되며 한 페이지당 1000개가 반환됩니다.
매 1000개의 로그를 가져오는 데는 크레딧 10이 소모됩니다.
기본적으로, 가장 최신 항목이 먼저인 목록을 받습니다. 이렇게 하면 skip=0부터 폴링을 시작하여 마지막으로 처리한 레코드를 찾을 때까지 페이지네이션할 수 있습니다.
또는 오래된 항목부터 정렬하여 더 이상 레코드가 없을 때까지 페이지네이션할 수 있습니다.
정렬은 order를 ASC 또는 DESC로 설정하여 수행할 수 있습니다. 기본값은 ASC입니다.
날짜로 쿼리하는 것은 밀리초 단위 타임스탬프로 before와 after를 사용하는 방식으로 가능합니다. before와 after는 포함되지 않습니다.



댓글 구조 
A Comment object represents a comment left by a user.
The relationship between parent and child comments is defined via parentId.
The structure for the Comment object is as follows:

Some of these fields are marked READONLY - these are returned by the API but cannot be set.
댓글 텍스트 구조
Comments are written in a FastComments flavor of markdown, which is just markdown plus traditional bbcode style tags for images, like [img]path[/img].
텍스트는 두 필드에 저장됩니다. 사용자가 입력한 텍스트는 수정되지 않은 채 comment 필드에 저장됩니다. 렌더링된 결과는 commentHTML 필드에 저장됩니다.
The allowed HTML tags are b, u, i, strike, pre, span, code, img, a, strong, ul, ol, li, and br.
HTML은 아주 작은 부분집합이므로 HTML을 렌더링하는 것을 권장합니다. 렌더러를 만드는 것은 비교적 간단합니다. 예를 들어 React Native와 Flutter용으로 이를 도와주는 여러 라이브러리가 있습니다
You may choose to render the un-normalized value of the comment field. An example parser is here..
예제 파서는 HTML에 맞게 조정하여 HTML 태그를 플랫폼에 맞는 렌더링 요소로 변환하도록 할 수도 있습니다.
태깅
When users are tagged in a comment, the information is stored in a list called mentions. Each object in that list
has the following structure.
Run 
해시태그
When hashtags are used and successfully parsed, the information is stored in a list called hashTags. Each object in that list
has the following structure. Hashtags can also be manually added to the comment hashTags array for querying, if retain is set.
Run 
GET /api/v1/comments 
이 API는 사용자가 볼 수 있도록 댓글을 가져오는 데 사용됩니다. 예를 들어, 승인되지 않았거나 스팸인 댓글을 자동으로 필터링합니다.
Pagination
페이지네이션은 성능 요구 사항 및 사용 사례에 따라 두 가지 방법 중 하나로 수행할 수 있습니다:
- Fastest: Precalculated Pagination:
- FastComments는 사전 구축된 위젯과 클라이언트를 사용할 때 이렇게 동작합니다.
- "next"를 클릭하면 페이지 수가 단순히 증가합니다.
- 이를 키-값 저장소에서 가져오는 것으로 생각할 수 있습니다.
- 이 경우
page매개변수를0부터 시작하도록 정의하고 정렬 방향을direction으로 지정하면 됩니다. - 페이지 크기는 커스터마이징 규칙을 통해 맞춤 설정할 수 있습니다.
- Most Flexible: Flexible Pagination:
- 이 방법을 사용하면 사용자 정의
limit및skip매개변수를 정의할 수 있습니다.page는 전달하지 마세요. direction정렬도 지원됩니다.limit은skip이 적용된 후 반환할 총 개수입니다.- 예:
page size = 100이고page = 2인 경우skip = 200, limit = 100으로 설정합니다.
- 예:
- 자식 댓글도 페이지네이션에 포함됩니다.
asTree옵션을 사용하면 이를 우회할 수 있습니다.limitChildren및skipChildren을 사용하여 자식 댓글을 페이지네이션할 수 있습니다.maxTreeDepth를 사용하여 반환되는 스레드의 깊이를 제한할 수 있습니다.
- 이 방법을 사용하면 사용자 정의
Threads
Precalculated Pagination을 사용할 때, 댓글은 page별로 그룹화되며 스레드 내 댓글이 전체 페이지에 영향을 줍니다.- 이 경우 클라이언트에서
parentId를 기준으로 스레드를 결정할 수 있습니다. - 예를 들어, 최상위 댓글이 하나이고 29개의 답글이 있는 페이지에서 API에
page=0을 설정하면 최상위 댓글 하나와 29개의 자식 댓글만 반환됩니다.
- 이 경우 클라이언트에서
Flexible Pagination을 사용할 때parentId매개변수를 정의할 수 있습니다.- 이를 null로 설정하면 최상위 댓글만 가져옵니다.
- 그런 다음 스레드를 보려면 API를 다시 호출하고
parentId를 전달합니다. - 일반적인 해결책은 최상위 댓글에 대해 API 호출을 한 뒤, 각 댓글의 자식 댓글을 가져오기 위해 병렬 API 호출을 수행하는 것입니다.
- NEW 2023년 2월부터!
&asTree=true를 사용하여 트리 형태로 가져옵니다.- 이를
Flexible Pagination as a Tree로 생각할 수 있습니다. - 페이지네이션에는 최상위 댓글만 포함됩니다.
- 트리를 루트에서 시작하려면
parentId=null로 설정합니다(parentId를 반드시 설정해야 합니다). - 페이지네이션을 위해
skip및limit을 설정합니다. asTree를true로 설정합니다.- 이 시나리오에서는 백엔드가 훨씬 더 많은 작업을 수행해야 하므로 크레딧 비용이
2x증가합니다. - 원하는 대로
maxTreeDepth,limitChildren,skipChildren을 설정합니다.
- 이를
Trees Explained
asTree를 사용할 때 페이지네이션을 이해하기 어려울 수 있습니다. 다음은 유용한 그래픽입니다:
Fetching Comments in The Context of a User
/comments API는 두 가지 컨텍스트에서 사용될 수 있으며, 각각 다른 사용 사례에 적용됩니다:
- 자신의 클라이언트를 구축하기 위해 정렬되고 태그된 정보를 포함한 댓글을 반환합니다.
- 이 경우
contextUserId쿼리 매개변수를 정의합니다.
- 이 경우
- 맞춤형 통합을 위해 백엔드에서 댓글을 가져옵니다.
- 플랫폼은
contextUserId없이도 기본적으로 이 방식을 사용합니다.
- 플랫폼은




Get Comments as a Tree
트리를 반환하도록 요청할 수 있으며, 페이지네이션은 최상위 댓글만 계산됩니다.

최상위 댓글과 즉시 자식만 가져오고 싶나요? 다음과 같이 할 수 있습니다:

하지만 UI에서는 각 댓글에 “답글 보기” 버튼을 표시할지 여부를 알아야 할 수도 있습니다. 트리 형태로 댓글을 가져올 때는 해당 경우에 hasChildren 속성이 댓글에 태그됩니다.
Get Comments as a Tree, Searching by Hash Tag
해시태그로 검색할 수 있으며, 전체 테넌트(특정 페이지나 urlId에 제한되지 않음)에서 검색합니다.
이 예시에서는 urlId를 생략하고 여러 해시태그로 검색합니다. API는 요청된 모든 해시태그를 포함하는 댓글만 반환합니다.

All Request Params

The Response

Helpful Tips
URL ID
Comment API를 urlId 매개변수와 함께 사용하는 것이 좋습니다. 먼저 Pages API를 호출하면 사용 가능한 urlId 값이 어떻게 생겼는지 확인할 수 있습니다.
Anonymous Actions
익명 댓글을 달 때는 댓글을 가져올 때와 신고·차단을 수행할 때 anonUserId를 전달하는 것이 좋습니다.
(!) 많은 앱 스토어에서 이는 필수이며, 사용자는 로그인하지 않아도 볼 수 있는 사용자 생성 콘텐츠를 신고할 수 있어야 합니다. 이를 수행하지 않으면 해당 스토어에서 앱이 삭제될 수 있습니다.
Comments Not Being Returned
댓글이 승인되었고 스팸이 아닌지 확인하십시오.
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 엔드포인트는 특정 사용자를 위해 댓글을 신고할 수 있는 기능을 제공합니다.
Notes:
- 이 호출은 항상 사용자 컨텍스트에서 이루어져야 합니다. 사용자는 FastComments.com 사용자, SSO 사용자, 또는 테넌트 사용자가 될 수 있습니다.
- 숨김 임계값(flag-to-hide threshold)이 설정되어 있으면, 댓글이 정의된 횟수만큼 신고되면 실시간으로 자동으로 숨김 처리됩니다.
- 댓글이 자동으로 미승인(숨김) 처리된 후에는 관리자나 모더레이터만이 댓글을 다시 승인할 수 있습니다. 플래그 해제는 댓글을 다시 승인하지 않습니다.

For anonymous flagging, we must specify an anonUserId. This can be an ID that represents the anonymous session, or a random UUID.
This allows us to support flagging and un-flagging comments even if a user is not logged in. This way, the comment can be marked as
flagged when comments are fetched with the same 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를 제거합니다.



해시태그 구조 
HashTag 객체는 사용자가 남길 수 있는 태그를 나타냅니다. HashTags는 외부 콘텐츠로 연결하거나
관련된 댓글들을 묶는 데 사용할 수 있습니다.
The structure for the HashTag object is as follows:

Notes:
- In some API endpoints you will see that the hashtag is used in the URL. Remember to URI-Encoded values. For example,
#should instead be represented as%23. - Some of these fields are marked
READONLY- these are returned by the API but cannot be set.
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 생성이 비활성화되지 않은 한, 사용자가 댓글 작성 시 해시태그를 제공하면 해시태그가 다시 생성될 수 있습니다.



모더레이터 구조 
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



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

GET /api/v1/pages 
현재 계정과 연결된 모든 페이지(또는 /by-url-id를 통해 단일 페이지)만 가져올 수 있습니다. 보다 세분화된 검색을 원하시면, 문의해 주세요.



Helpful Tip
The Comment API requires a urlId. You can call the Pages API first, to see what the urlId values available to you
look like.
GET /api/v1/pages/by-url-id 
개별 페이지는 해당 urlId로 가져올 수 있습니다. 이는 페이지 제목이나 댓글 수를 조회하는 데 유용합니다.



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



참고
Page 객체의 일부 매개변수는 자동으로 업데이트됩니다. 이러한 항목에는 카운트와 title 속성이 포함됩니다. 카운트는 계산된 값이므로
API를 통해 업데이트할 수 없습니다. 페이지 title은 API를 통해 설정할 수 있지만, 동일한 urlId를 가진 페이지에서 댓글 위젯을 사용하고 페이지 제목이 다를 경우 덮어써질 수 있습니다.
POST /api/v1/pages 
이 API 엔드포인트는 페이지를 생성하는 기능을 제공합니다.
일반적인 사용 사례는 접근 제어입니다.
참고:
- 댓글 스레드에 댓글을 달았거나,
Comment를 생성하는 API를 호출했다면, 이미Page객체를 생성한 것입니다! You can try fetching it via the/by-url-idPageroute, passing in the sameurlIdpassed to the comment widget. - The
Pagestructure contains some calculated values. Currently, these arecommentCountandrootCommentCount. They are populated automatically and cannot be set by the API. Attempting to do so will cause the API to return an error.



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



보류 중인 웹훅 이벤트 구조 
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를 순차적으로 호출하세요.



SSO 사용자 구조 
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로 두 사용자를 생성하려 하면 오류가 발생합니다.

In this example we specify groupIds for access control, but this is optional.


통합 참고
API로 전달된 데이터는 다른 SSO User HMAC 페이로드를 전달하는 것만으로 간단히 덮어쓸 수 있습니다. For example, if API를 통해 username을 설정했지만 페이지 로드 시 SSO 흐름에서 다른 username을 전달하면, 우리는 자동으로 업데이트 해당 사용자의 username.
We will not update user parameters in this flow unless you explicitly specify them or set them to null (not 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 객체는 사용자가 댓글 위젯의 알림 벨을 클릭하고 "이 페이지 구독"을 클릭할 때 생성됩니다.
구독은 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 객체를 삭제합니다.



테넌트 일일 사용량 구조 
A TenantDailyUsage 객체는 특정 날짜에 대한 테넌트의 사용량을 나타냅니다. 특정 테넌트가 해당 날짜에 활동이 없었다면 그 날짜에는 TenantDailyUsage 객체가 생성되지 않습니다.
The TenantDailyUsage object is not real time and may be minutes behind actual usage.
TenantDailyUsage 객체의 구조는 다음과 같습니다:

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



테넌트 구조 
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로 설정되어 있어야 합니다.



테넌트 패키지 구조 
The TenantPackage defines package information available to a Tenant. A tenant may have many packages available, but only
one in use at a given time.
A Tenant cannot be used for any products until its packageId points to a valid TenantPackage.
There are two types of TenantPackage objects:
- Fixed-pricing packages - where
hasFlexPricingis false. - Flexible pricing - where
hasFlexPricingis true.
In both case limits are defined on the account using the package, however with Flex the tenant is charged a base price plus
what they used, defined by the flex* parameters.
A tenant may have multiple tenant packages and have the ability to change the package themselves from the 청구 정보 페이지.
If you will be handling billing for tenants yourselves, you will still need to define a package for each tenant to define their limits. Simply set billingHandledExternally to true on the Tenant and they
will not be able to change their billing information, or active package, themselves.
You may not create packages with higher limits than the parent tenant.
The structure for the TenantPackage object is as follows:

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를 업데이트하세요.



테넌트 사용자 구조 
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인 경우:
- 사용자의 모든 댓글이 실시간으로 삭제됩니다.
- 모든 child (이제는 고아가 된) 댓글은 각 댓글에 연결된 페이지 구성에 따라 삭제되거나 익명처리됩니다. 예를 들어 스레드 삭제 모드가 "anonymize"인 경우 답글은 남아 있고 사용자의 댓글만 익명화됩니다. 이는
commentDeleteMode가Remove일 때만 적용됩니다(기본값). creditsCost는2가 됩니다.
Anonymized Comments
사용자의 댓글을 유지하되 단순히 익명화하려면 commentDeleteMode=1로 설정하십시오.
사용자의 댓글이 익명화되면 다음 값들이 null로 설정됩니다:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badges
isDeleted 및 isDeletedUser는 true로 설정됩니다.
렌더링 시 댓글 위젯은 사용자 이름에 DELETED_USER_PLACEHOLDER (기본값: "[deleted]")를, 댓글에는 DELETED_CONTENT_PLACEHOLDER를 사용합니다. 이는 위젯 사용자 지정 UI를 통해 변경할 수 있습니다.
Examples



사용자 구조 
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 객체는 사용자가 남긴 투표를 나타냅니다.
댓글과 투표 간의 관계는 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는 어느 곳의 사용자 객체와 일치할 필요가 없습니다(따라서 익명입니다). 이것은 단순히 식별자 세션을 위한 것이며, 같은 세션에서 다시 투표를 가져와 댓글에 투표가 되었는지 확인할 수 있습니다.
If you do not have such a thing as "anonymous sessions" like FastComments does - you can simply set this to a random ID, like a UUID (although we appreciate smaller identifiers to save space).
기타 참고
- 이 API는 테넌트 수준 설정을 따릅니다. 예를 들어 특정 페이지에 대해 투표를 비활성화하고 API를 통해 투표를 생성하려고 하면,
voting-disabled오류 코드로 실패합니다. - 이 API는 기본적으로 라이브 상태입니다.
- 이 API는 해당
Comment의votes를 업데이트합니다.
DELETE /api/v1/votes/:id 
이 라우트는 단일 Vote를 삭제할 수 있는 기능을 제공합니다.



Notes:
- 이 API는 테넌트 수준 설정을 따릅니다. 예를 들어 특정 페이지에서 투표를 비활성화한 상태에서 API를 통해 투표를 생성하려고 하면 오류 코드
voting-disabled로 실패합니다. - 이 API는 기본적으로 라이브 상태입니다.
- 이 API는 해당
Comment의votes를 업데이트합니다.
도메인 구성 구조 
A DomainConfig object represents configuration for a domain for a tenant.
The structure for the DomainConfig object is as follows:


인증을 위해
도메인 구성은 귀하의 계정에 대해 FastComments 위젯을 호스팅할 수 있는 사이트를 결정하는 데 사용됩니다. 이것은 기본적인 형태의 인증으로, 도메인 구성을 추가하거나 제거하면 운영 환경의 FastComments 설치 가용성에 영향을 줄 수 있습니다.
현재 사용 중인 도메인의 Domain Config에서 domain 속성을 비활성화하려는 의도가 아닌 한 제거하거나 업데이트하지 마세요.
이 동작은 /auth/my-account/configure-domains에서 도메인을 제거하는 것과 동일합니다.
또한 My Domains UI에서 도메인을 제거하면 해당 UI를 통해 추가되었을 수 있는 해당 도메인에 대한 구성도 제거된다는 점을 유의하세요.
이메일 커스터마이징을 위해
이메일 푸터의 수신거부 링크와 많은 이메일 클라이언트에서 제공하는 원클릭 수신거부 기능은 각각 footerUnsubscribeURL 및 emailHeaders를 정의하여 이 API를 통해 구성할 수 있습니다.
DKIM을 위해
DKIM DNS 레코드를 정의한 후, 정의된 구조를 사용하여 DomainConfig를 DKIM 구성으로 업데이트하면 됩니다.
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만 채워집니다).



질문 구성 구조 
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를 생성합니다. 그런 다음 질문 결과를 집계할 수 있고, 또한
보고 목적을 위해 댓글에 연결할 수도 있습니다.

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 
여기서 결과의 집계가 수행됩니다.
The aggregation response structure is as follows:

Here are the query parameters available for aggregation:

Here's an example request:

Example response:


Performance Notes
- For a cache miss aggregations generally take five seconds per million results.
- Otherwise, requests are constant-time.
Caching and Cost Notes
- When
forceRecalculateis specified the cost is always10, instead of the normal2. - If the cache expires and data is recalculated, the cost is still a constant
2ifforceRecalculateis not specified. The cache expires based on the data set size aggregated (can vary between 30 seconds and 5 minutes). - This is to incentivize using the cache.
GET /api/v1/question-results-aggregate/combine/comments 
결과와 댓글을 결합하는 기능이 제공되는 엔드포인트입니다. 예를 들어 제품에 대한 "최근 긍정 및 부정 댓글" 차트를 만드는 데 유용합니다.
값의 범위(포함), 하나 이상의 질문, 그리고 시작 날짜(포함)로 검색할 수 있습니다.
응답 구조는 다음과 같습니다:

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

다음은 예시 요청입니다:

다음은 예시 응답입니다:


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

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는 FastComments 시스템에서 사용자가 다양한 배지를 획득하기 위한 진행 상황을 나타내는 객체입니다.
이 추적은 사용자의 활동 및 커뮤니티 참여를 기반으로 언제 자동으로 배지를 수여할지 결정하는 데 도움이 됩니다.
The structure for the UserBadgeProgress object is as follows:

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 문서가 포괄적이고 이해하기 쉬웠기를 바랍니다. 누락된 부분이 있다면 아래에 알려주세요.