
語言 🇹🇼 繁體中文
API 資源
驗證
彙總
稽核日誌
評論
電子郵件範本
動態貼文
標籤
我的資訊
版主
通知計數
通知
頁面回應
頁面
投票
投票結果
待處理Webhook事件
SSO 使用者
訂閱
租戶每日使用量
租戶
租戶套件
租戶使用者
使用者
網域設定
問題設定
問題結果
問題結果彙總
使用者徽章
使用者徽章進度
即時評論 API
FastComments API
FastComments 提供一套 API 讓您與多種資源互動。您可以使用我們的平台建置整合,甚至自行開發客戶端!
在本文件中,您將找到 API 所支援的所有資源,並附有其請求與回應類型的說明。
對於企業客戶,所有 API 存取皆會記錄於稽核日誌中。
產生的 SDK
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
認證
API 透過在 X-API-KEY 標頭或 API_KEY 查詢參數中傳遞您的 api key 來驗證。您還需要提供 tenantId 以呼叫 API。tenantId 可從與 API 金鑰相同的頁面取得。
安全說明
這些路由應該由 伺服器 呼叫。請勿 從瀏覽器呼叫。若這樣做會暴露您的 API 金鑰,任何能看到頁面原始碼的人都能取得完整帳號存取權限!
認證方式一 – 標頭
- 標頭:
X-API-KEY - 標頭:
X-TENANT-ID
認證方式二 – 查詢參數
- 查詢參數:
API_KEY - 查詢參數:
tenantId
認證方式三 – OAuth Bearer Token
- 標頭:
Authorization: Bearer fcat_...
第三方應用程式(如 Zapier)以及 MCP 伺服器 的客戶端會透過 OAuth 取得 token,而非使用 API 金鑰。此 token 可用於此處的所有端點。token 已隱含租戶資訊,故 tenantId 為可選,但若提供則必須與 token 相符。GET 請求需要 read 範圍,其他方法則需要 write 範圍。完整流程(包括客戶端註冊、PKCE、刷新與撤銷)請參考 OAuth Authorization。發現端點位於 https://fastcomments.com/.well-known/oauth-authorization-server。
讀取自己的寫入
FastComments 提供 Active-Active 可用性。來自您資料中心的請求會自動路由至離您最近的 presence 點。這是自動化的,通常您可以觀察到讀寫一致性(read‑your‑write)語意。若您想確保讀取自己的寫入,可將請求固定到特定區域的 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 呼叫所需點數。對於某些端點,點數會根據選項和回應大小而變化。
您可以在 Billing Analytics 頁面檢查 API 使用情況,且資料每隔幾分鐘會更新一次。
注意!
我們建議先閱讀 Pages 文件,以減少在決定傳遞給 Comment API 的 urlId 值時的混淆。
Webhooks
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 帳號的 token,並在本指南的所有端點上使用它來取代 API 金鑰。Zapier 應用、MCP 伺服器 以及其他第三方整合皆透過此方式連線。
Token 透過使用 PKCE 的授權碼流程發行。不存在 client credentials 或隱式授權。
Discovery
端點位置、支援的授權類型與驗證方法皆在標準的 metadata URL 上公布:

它描述的端點:

EU 區域的帳號使用 https://eu.fastcomments.com 作為發行者,路徑相同。
Registering a client
客戶端在開始流程前需要一個 client_id 與已註冊的 redirect_uri。取得方式有兩種:
- 動態客戶端註冊。 依 RFC 7591 使用 JSON 主體
POST /oauth/register(redirect_uris、client_name、client_uri、logo_uri、token_endpoint_auth_method)。回應會攜帶client_id,對於機密客戶端,還會返回client_secret。註冊不需驗證,且依 IP 受速率限制。 - 客戶端 ID 中繼文件。 客戶端使用其控制的
httpsURL 作為client_id。FastComments 會抓取該 URL,並從中讀取相同的中繼欄位。無需呼叫註冊。
在 FastComments 控制台列出的合作應用(如 Zapier)由 FastComments 直接註冊。若您正在建立市集列表並需要第一方客戶端,請聯絡支援。
Scopes

未指定範圍的請求會同時授予兩者。使用者會在同意頁面看到請求的範圍。若請求的範圍不是上述兩者之一,則會回傳 invalid_scope。
Step 1 - Authorization request
將使用者的瀏覽器導向授權端點。每個客戶端都必須使用 S256 方法的 PKCE。


使用者若需要會先登入 FastComments,並看到一個同意頁面,列出您的應用程式、將要連結的帳號,以及請求的範圍。使用者必須在該帳號上擁有 API Admin 權限;其他使用者會看到權限錯誤而非同意表單。批准後會將瀏覽器重新導向至您的 redirect_uri,附帶 code 與 state。拒絕則會以 error=access_denied 重新導向。
授權碼有效期為 10 分鐘,且只能兌換一次。第二次兌換相同的授權碼會撤銷第一次兌換所產生的所有 token。
Step 2 - Token request
使用授權碼換取 token。請求主體為表單編碼。機密客戶端使用 client_secret_basic(HTTP Basic)或 client_secret_post(在主體中提供 secret)進行驗證。公開客戶端僅傳送 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。
Step 3 - Calling the API
將存取 token 作為 bearer token 傳送。租戶資訊由 token 隱含,因此 tenantId 為可選。若提供,必須與 token 中的租戶相符,否則請求失敗。

GET /api/v1/me 會回傳租戶、授權使用者以及已授予的範圍,是測試連線的合適呼叫。使用過期或已撤銷的 token 會得到 HTTP 401。若請求的方法需要 token 未持有的範圍,則會得到 HTTP 403。
Step 4 - Refreshing


回應與授權碼交換的結構相同。Refresh token 會輪替:每次刷新都會返回新的 refresh_token,並在 30 秒寬限期後撤銷舊的 token,以支援同時請求。若提供的 refresh token 已在 30 秒前被輪替,則視為重放攻擊,並撤銷整個授權。由 FastComments 註冊的合作應用免於輪替,會返回相同的 refresh token,且其有效期再延長 30 天。
刷新同時也會重新檢查授權使用者是否仍在該帳號上擁有 API Admin 權限。若沒有,授權會被撤銷,回應為 invalid_grant。
Revocation

撤銷 refresh token 會撤銷同一授權所產生的所有 access token。撤銷 access token 只會撤銷該 token。本端點無論是否找到 token,都會回傳 HTTP 200 且空的 JSON 物件,符合 RFC 7009。
使用者也可以在 FastComments 控制台的 已連結的應用 中撤銷連線。該應用的所有 token 會立即失效。
彙總您的資料 
此 API 會對文件進行彙總(若提供 groupBy 則會先分群),並套用多個運算。支援不同的運算(例如 sum、countDistinct、avg 等)。
費用為 可變。每掃描 500 個物件會耗費 1 個 API 點數。
預設每次 API 呼叫可使用的最大記憶體為 64MB,並且預設同一時間只允許一個彙總在執行。若同時提交多個彙總,將會排入佇列並依提交順序執行。待處理的彙總最多會等待 60 秒,超過後請求將會逾時。單一彙總最多可執行 5 分鐘。
若您有管理的租戶,可在一次呼叫中透過傳遞 parentTenantId 查詢參數來彙總所有子租戶的資源。
範例
範例:計算唯一值


範例:計算不同值

Response:

範例:多欄位加總值

Response:

範例:多欄位平均值

Response:

範例:多欄位最小/最大值

Response:

範例:多欄位唯一值計數

Response:

範例:建立查詢

Response:

範例:計算待審核評論

Response:

範例:已核准、已審核與垃圾評論的分類統計

Response:

結構


The following resources can be aggregated:
- 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
稽核日誌結構 
An AuditLog 是一個物件,代表具有此功能存取權限的租戶的稽核事件。
AuditLog 物件的結構如下:

targetId 與 targetLabel 描述事件執行的對象;userId 與 username 描述執行者。對於更新,objectDetails.changes 包含一個 {field: {from, to}} 的映射,說明實際變更的內容。
稽核日誌是不可變的,也無法手動寫入。FastComments.com 僅能決定何時寫入稽核日誌。然而,您可以透過此 API 讀取它。
稽核日誌中的事件會在兩年後過期。
GET /api/v1/audit-logs 
此 API 使用分頁,由 skip、limit、before 與 after 參數提供。AuditLogs 預設以 1000 筆為一頁返回,最大 limit 為 10000,依 when 與 id 排序。由於此端點通常用於一次性匯出歷史記錄,而非互動式分頁,頁面會相當大。
每返回 100 筆日誌會消耗 1 點信用。
預設情況下,您會收到 最新項目優先 的列表。如此,您可以從 skip=0 開始輪詢,持續分頁直到找到您已消耗的最後一筆記錄。
或者,您也可以將排序設為最舊優先,並持續分頁直到沒有更多記錄。
可透過將 order 設為 ASC 或 DESC 來排序。預設為 DESC。
可使用 before 與 after(以毫秒為單位的時間戳記)進行日期查詢。before 與 after 為不含等於的範圍,且任一參數皆可單獨使用。
找出某人的發生事件
每個事件都會記錄執行者(username、userId、ip)以及被執行的對象。targetLabel 為該對象的可讀標籤,例如 jsmith (jsmith@example.com),targetId 為其 ID。當您知道某人的姓名或電子郵件但不知道其 ID 時,可使用 target 進行不區分大小寫的子字串匹配。
刪除操作會在事件發生時捕獲標籤,因此即使底層記錄已被移除,仍可辨識被刪除的使用者或審核員。
管理的租戶
如果您的租戶管理其他租戶,請將 includeManagedTenants=true,以在單一回應中返回您租戶及其管理的所有租戶的事件。每筆返回的日誌的 tenantId 會告訴您其來源租戶。



評論結構 
一個 Comment 物件代表使用者留下的一則評論。
父評論與子評論之間的關聯是透過 parentId 定義的。
Comment 物件的結構如下:

有些欄位被標示為 READONLY — 這些欄位由 API 回傳但無法設定。
評論文字結構
評論是使用 FastComments 的一種 Markdown 變體撰寫,這就是 Markdown 外加傳統 bbcode 風格的圖片標籤,例如 [img]path[/img]。
文字儲存在兩個欄位。使用者輸入的原始文字會不作修改地儲存在 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 
主題標籤
當使用 hashtag 並成功解析時,資訊會儲存在名為 hashTags 的清單中。該清單中的每個物件具有以下結構。若設定了 retain,也可以手動將 hashtags 新增到評論的 hashTags 陣列以供查詢。
Run 
GET /api/v1/comments 
此 API 用於取得供使用者顯示的評論。例如,它會自動過濾未批准或垃圾評論。
Pagination
分頁可以依照效能需求與使用情境以兩種方式進行:
- 最快:Precalculated Pagination:
- 這是使用我們預建小工具與客戶端時 FastComments 的運作方式。
- 點擊「next」只會增加頁數。
- 你可以將其視為由鍵值儲存庫取得。
- 以此方式,只需定義從
0開始的page參數以及排序方向direction。 - 可透過自訂規則調整每頁大小。
- 最彈性: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 取得每則評論的子評論。
- 設為
- NEW As of Feb 2023! 使用
&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
可以使用 API 依標籤搜尋,遍及整個租戶(不限於單一頁面或 urlId)。
在此範例中,我們省略 urlId,並以多個標籤搜尋。API 只會返回同時具備所有請求標籤的評論。

All Request Params

The Response

Helpful Tips
URL ID
你可能想使用帶有 urlId 參數的 Comment API。你可以先呼叫 Pages API,查看可用的 urlId 值長什麼樣子。
Anonymous Actions
對於匿名評論,你可能想在取得評論以及執行檢舉與封鎖時傳遞 anonUserId。
(!) 這在許多應用商店是必須的,因為使用者必須能檢舉他們能看到的使用者產生內容,即使未登入。未執行此步驟可能導致你的應用被移除出該商店。
Comments Not Being Returned
確認你的評論已被批准,且不是垃圾評論。
GET /api/v1/comments/:id 
此 API 提供依 id 取得單一評論的功能。



POST /api/v1/comments 
此 API 端點提供建立評論的功能。
常見用例包括自訂使用者介面、整合或匯入。
注意事項:
- 如果需要,此 API 可以「即時」更新評論小工具(這會將
creditsCost從1增加到2)。 - 如果提供了 email,這個 API 會自動在系統中建立使用者物件。
- 嘗試儲存兩則使用不同 email 但相同使用者名稱的評論,第二則評論會發生錯誤。
- 如果您指定了
parentId,且子評論的notificationSentForParent為 false,我們將會為父評論發送通知。此操作每小時進行(我們會將通知批次一起發送以減少郵件數量)。 - 如果您想在建立使用者時發送歡迎郵件,或想發送評論驗證郵件,請在查詢參數中將
sendEmails設為true。 - 透過此 API 建立的評論將顯示在管理應用程式的 Analytics 與 Moderation 頁面中。
- 如果該設定已開啟,評論者名稱與評論文字中的「髒話」仍會被遮罩。
- 透過此 API 建立的評論仍可視需要進行垃圾訊息檢查。
- 若透過「自訂規則」管理頁面設定的配置(例如最大評論長度)將在此處套用。
要在評論小工具中顯示,提交的最小資料如下:

更實際的請求範例如下:



PATCH /api/v1/comments/:id 
此 API 端點提供更新單則評論的功能。
Notes:
- 此 API 可在需要時將評論元件「即時」更新(這會將基本
creditsCost從1提高為2)。- 這可讓在頁面之間遷移評論成為「即時」(更改
urlId)。 - 由於頁面會被預先計算且此操作耗費大量 CPU,遷移會額外收取
2點額度。
- 這可讓在頁面之間遷移評論成為「即時」(更改
- 與建立 API 不同,如果提供 email,本 API 不會自動在系統中建立使用者物件。
- 透過此 API 更新的評論仍可在需要時進行垃圾郵件檢查。
- 若透過自訂規則管理頁面設定的配置(例如最大評論長度),將在此生效。
- 若要允許使用者更新他們的評論文字,只需在請求主體中指定
comment。我們會生成相應的commentHTML。- 若同時定義了
comment與commentHTML,我們將不會自動生成 HTML。 - 若使用者在新文字中加入提及或標籤,依然會像
POSTAPI 一樣處理。
- 若同時定義了
- 在更新評論的
commenterEmail時,最好也指定userId。否則,您必須確保該 email 所對應的使用者屬於您的租戶,否則請求將失敗。 - 如果目標評論被鎖定(
isLocked: true),則請求會以code: 'locked'被拒絕。請先解除鎖定再更新,若需要可於更新後重新鎖定。



DELETE /api/v1/comments/:id 
此 API 端點提供刪除評論的功能。
注意事項:
- 如果需要,此 API 可以將評論小工具 "live" 即時更新(這會將
creditsCost從1增加到2)。 - 此 API 將刪除所有子評論。
- 如果目標評論已鎖定(
isLocked: true),請求會以code: 'locked'被拒絕。請先解鎖該評論,然後再刪除。



POST /api/v1/comments/:id/flag 
此 API 端點可讓您為特定使用者標記(檢舉)評論。
注意事項:
- 此呼叫必須在使用者上下文中執行。該使用者可以是 FastComments.com 使用者、SSO 使用者或租戶使用者。
- 若已設定標記以隱藏的閾值,當評論被標記達到該次數時,將會即時自動隱藏該評論。
- 在評論被自動取消核准(隱藏)之後,該評論只能由管理員或版主重新核准。取消標記不會使評論重新核准。

對於匿名檢舉,我們必須指定一個 anonUserId。這可以是代表匿名會話的 ID,或是一個隨機的 UUID。
這讓我們即使在使用者未登入時也能支援對評論的標記與取消標記。這樣一來,該評論可以被標示為
已標記,當以相同的 anonUserId 取回評論時。



POST /api/v1/comments/:id/un-flag 
此 API 端點提供對特定使用者取消標記評論的功能。
Notes:
- 此呼叫必須始終在使用者的上下文中執行。該使用者可以是 FastComments.com User、SSO User,或 Tenant User。
- 當評論被自動取消核可(隱藏)後,該評論只能由管理員或版主重新核可。取消標記不會重新核可該評論。

For anonymous flagging, we must specify an anonUserId. This can be an ID that represents the anonymous session, or a random UUID.



POST /api/v1/comments/:id/block 
此 API 端點提供封鎖撰寫特定評論的使用者的功能。它支援封鎖來自 FastComments.com 使用者、SSO 使用者 和 租戶使用者 的評論。
它支援一個 commentIdsToCheck 主體參數,用來檢查在此操作完成後客戶端上是否有任何其他可能可見的評論應該被封鎖/解除封鎖。
注意:
- 此呼叫必須始終在使用者的上下文中進行。該使用者可以是 FastComments.com 使用者、SSO 使用者,或租戶使用者。
- 請求中的
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 的 body 參數,用來檢查在此操作執行後,客戶端上任何其他可能可見的評論是否應該被封鎖/解除封鎖。
注意:
- 此呼叫必須始終在某個使用者的上下文中進行。該使用者可以是 FastComments.com 使用者、SSO 使用者,或租戶使用者。
- 請求中的
userId指的是正在解除封鎖的那個使用者。例如:User A想要解除封鎖User B。傳入userId=User A以及User B所撰寫的評論 id。 - 完全匿名的評論(沒有使用者 id、沒有 email)無法被封鎖,系統將回傳錯誤。




電子郵件範本結構 
一個 EmailTemplate 物件代表租戶的自訂電子郵件範本設定。
系統會透過下列方式選擇要使用的電子郵件範本:
- 其類型識別符,我們稱之為
emailTemplateId。這些是常數。 domain。我們會先嘗試尋找與相關物件(例如Comment)所屬網域相符的範本,若找不到相符者,則會嘗試尋找 domain 為 null 或*的範本。
以下為 EmailTemplate 物件的結構:

注意事項
- 您可以從
/definitions端點取得有效的emailTemplateId值。 /definitions端點也包含預設翻譯和測試資料。- 如果結構或測試資料無效,範本將無法儲存。
GET /api/v1/email-templates/:id 
可以透過對應的 id 來擷取單一 EmailTemplate(不是 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 端點提供建立電子郵件範本的功能。
注意事項:
- 相同網域下不能有多個使用相同
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 
此路由會刪除單一 EmailTemplate(依 id)。



動態貼文結構 
A FeedPost 物件代表 FastComments 供稿中的一篇貼文。供稿是一系列貼文的串流,每篇貼文都有自己的評論串,透過 Feed 小工具呈現。每篇貼文都有作者、可選的富內容、媒體與連結,且可以加上標籤,以便過濾供稿。
FeedPost 物件的結構如下:

注意事項:
- 其中一些欄位標記為
READONLY—— 這些欄位由 API 回傳,但無法設定。 - 貼文的評論是一般評論,其
urlId為post:加上貼文的_id。使用此值搭配評論 API,即可讀取或建立貼文的評論。
GET /api/v1/feed-posts 
取得供稿中的貼文,最新的優先。分頁採用游標方式:傳遞您收到的最後一篇貼文的 _id 作為
afterId 以取得下一頁。
每返回十篇貼文消耗一點信用,最低消耗一點信用。



POST /api/v1/feed-posts 
此路由會建立單一個 FeedPost。每篇貼文都有作者,因此 fromUserId 為必填,且必須是帳號中已存在的 FastComments 或 SSO 使用者的 ID。



PATCH /api/v1/feed-posts/:id 
此路由會更新單一 FeedPost。僅傳送您想變更的欄位。



標籤結構 
一個 HashTag 物件代表使用者可以留下的標籤。HashTag 可用於連結到外部的內容或將相關評論串連起來。
HashTag 物件的結構如下:

注意:
- 在某些 API 端點中,你會看到 hashtag 被用在 URL 中。請記得對值進行 URI 編碼。例如,
#應該表示為%23。 - 其中某些欄位被標示為
READONLY- 這些欄位由 API 回傳,但無法設定。
GET /api/v1/hash-tags 
此 API 使用分頁,透過 page 查詢參數提供。HashTags 會以每頁 100 筆返回,並依 tag 排序。



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 bearer token 時,回應還會攜帶 授權的使用者以及已授予的範圍。


版主結構 
A Moderator object represents configuration for a moderator.
有三種類型的版主:
- 擁有
isCommentModeratorAdmin標記的管理員使用者。 - 具有
isCommentModeratorAdmin標記的 SSO 使用者。 - 被邀請為版主的一般留言者,或 FastComments.com 的使用者。
Moderator 結構用於表示用例 3 的審核狀態。
如果您想透過 API 邀請某人成為版主,請使用 Moderator API,建立一個 Moderator 並邀請他們。
如果該使用者沒有 FastComments.com 帳號,邀請信將協助他們完成設定。如果他們已經有帳號,他們會被授予對您租戶的審核存取權,且 Moderator 物件的 userId 將更新為指向他們的使用者。您不會有該使用者的 API 存取權,因為在這種情況下該帳號屬於他們自己並由 FastComments.com 管理。
如果您需要完整管理該使用者的帳戶,我們建議使用 SSO,或將他們新增為 租戶使用者,然後再新增一個 Moderator 物件以追蹤他們的統計資料。
Moderator 結構可以用作用例 1 和 2 的統計追蹤機制。建立使用者後,新增一個定義了他們 userId 的 Moderator 物件,他們的統計將會在 留言版主頁面 上被追蹤。
Moderator 物件的結構如下:

GET /api/v1/moderators/:id 
此路由會依其 id 回傳單一位管理員。



GET /api/v1/moderators 
此 API 使用分頁,由 skip 查詢參數提供。管理員會以每頁 100 名的方式回傳,依據 createdAt 和 id 排序。
成本基於回傳的管理員數量計算,為每回傳 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:

或者,我們可以為屬於我們租戶的使用者建立 Moderator,以追蹤其審核統計資料:



POST /api/v1/moderators/:id/send-invite 
此路由提供邀請單一位 Moderator 的功能。
The following restrictions exist to send an invite email to a Moderator:
Moderator必須已經存在。fromName長度不得超過100 characters。
Notes:
- 如果具有該電子郵件的使用者已存在,他們將會被邀請來管理您租戶的評論。
- 如果具有該電子郵件的使用者 不存在,邀請連結會引導他們建立帳戶。
- 邀請將在
30 days後到期。
我們可以為只知道電子郵件的使用者建立 Moderator:

This will send an email like Bob at TenantName is inviting you to be a moderator...


DELETE /api/v1/moderators/:id 
此路由提供依 id 刪除 Moderator 的功能。



通知計數結構 
A NotificationCount 物件表示使用者的未讀通知數量與相關的描述性資訊。
如果沒有未讀通知,該使用者將不會有 NotificationCount。
NotificationCount 物件會自動建立,無法透過 API 建立。它們也會在一年後過期。
您可以透過刪除使用者的 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 建立。它們也會在一年後過期。
通知無法被刪除。但可以更新將 viewed 設為 false,且您可以依 viewed 進行查詢。
使用者也可以透過將通知中的 optedOut 設為 true 來取消特定評論的通知。再將其設為 false 即可重新訂閱。
有不同的通知類型 ─ 請檢查 relatedObjectType 與 type。
通知的產生方式相當彈性,可由多種情境觸發(請參考 NotificationType)。
截至目前,Notification 的存在並不代表會或應該發送電子郵件。相反地,通知用於通知資訊流與相關整合。
Notification 物件的結構如下:

GET /api/v1/notifications 
此路由會回傳最多 30 個 Notification 物件,依 createdAt 排序,最新的在前。
你可以以 userId 過濾。使用 SSO 時,使用者 id 的格式為 <tenant id>:<user id>。



GET /api/v1/notifications/count 
此路由會回傳一個物件,包含在 count 參數下的通知數量。
它比 /notification-count/ 慢且花費雙倍點數,但允許在更多維度上過濾。
您可以使用與 /notifications 端點相同的參數進行過濾,例如 userId。使用 SSO 時,使用者 ID 的格式為 <tenant id>:<user id>。




PATCH /api/v1/notifications/:id 
此 API 端點提供透過 id 更新 Notification 的功能。
更新 Notification 有以下限制:
- 您只能更新以下欄位:
viewedoptedOut



頁面回應公共 API 
Page Reacts 讓您的使用者可以按讚頁面,或使用您自訂的一組回應圖示來回應。 Page Reacts 小工具 與 Floating Likes 小工具是基於這些端點建置的,您也可以自行呼叫它們來建立自己的按讚按鈕。
與本指南的其他部分不同,Page Reacts 端點是公開的。它們從使用者的瀏覽器呼叫,不需要 API 金鑰,也不會消耗 API 點數。每個回應都屬於發出請求的使用者,因此使用者只能新增或移除自己的回應。
有兩組端點:
/page-reacts/v1/likes/:tenantId- 每位使用者每頁僅有一個「讚」。用於按讚按鈕。/page-reacts/v2/:tenantId- 每頁可有多個回應,每個回應以您自行選擇的短id(例如heart或laugh)識別。
兩者也都在我們的 SDK 中作為 PublicApi 的一部份提供,例如在 JavaScript SDK 中的 getV1PageLikes、createV1PageReact 與 deleteV1PageReact。
Identifying the User
回應與發出請求的使用者相關聯:
- SSO 使用者: 傳遞
sso查詢參數,設定為與您提供給評論小工具的相同 SSO 物件的 URI 編碼 JSON。請參閱 SSO。 - 匿名使用者: 當沒有
sso參數且未登入 FastComments 時,伺服器會為瀏覽器指派一個儲存在 FastComments 會話 Cookie 中的匿名 ID。請以credentials: 'include'送出請求,以便在請求之間保留 Cookie。阻擋第三方 Cookie 的瀏覽器將不會保留匿名 ID,若每位使用者必須可靠辨識,請使用 SSO。
The urlId
urlId 用於識別頁面,與評論的識別方式相同。請使用您提供給評論小工具的相同 urlId,以便在同一頁面上同時計算讚與評論。記得對其進行 URI 編碼。

GET /page-reacts/v1/likes/:tenantId 
返回頁面上的讚數,以及目前使用者是否已讚過。尚未存在的頁面會返回 likeCount 為 0。



POST /page-reacts/v1/likes/:tenantId 
以當前使用者的身份為頁面點讚。每位使用者只能對同一頁面點讚一次:再次點讚會成功回傳代碼 already-liked,且不會改變計數。
如果頁面尚未存在,系統會自動建立。傳遞 title 以設定或更新頁面的標題。



DELETE /page-reacts/v1/likes/:tenantId 
移除目前使用者對頁面的讚。如果使用者尚未對該頁面按讚,請求仍會成功,回傳代碼 not-liked,且不會改變計數。



GET /page-reacts/v2/:tenantId 
返回頁面上每個回應的計數,以及當前使用者已加入的回應。



GET /page-reacts/v2/:tenantId/list 
返回對頁面添加回應的使用者名稱,按字母順序排序。最多查詢 100 個回應,且不包括匿名使用者。



POST /page-reacts/v2/:tenantId 
以目前使用者的身份為頁面新增回應。使用者每個回應 id 只能新增一次:再次新增時會成功回傳代碼 already-reacted,且不會改變計數。使用者可以對同一頁面新增多個不同的回應。
回應 id 由您自行決定,長度上限為 36 個字元。如果頁面尚未存在,系統會自動建立。傳遞 title 以設定或更新頁面的標題。



DELETE /page-reacts/v2/:tenantId 
從頁面中移除目前使用者的一個回應。如果使用者尚未加入該回應,請求仍會成功,回傳代碼 no-react,且不會改變計數。



頁面結構 
一個 Page 物件代表許多評論可能屬於的頁面。這種關係是由 urlId 定義的。
Page 儲存像是頁面標題、評論數量及 urlId 等資訊。
Page 物件的結構如下:

GET /api/v1/pages 
你目前只能擷取與你的帳戶相關的所有頁面(或透過 /by-url-id 擷取單一頁面)。如果你想要更細緻的搜尋,請聯絡我們。



有用提示
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 端點提供建立頁面的功能。
一個常見的使用情境是存取控制。
Notes:
- If you've commented on a comment thread, or called the API to create a
Comment, you've already created aPageobject! You can try fetching it via the/by-url-idPageroute, passing in the sameurlIdpassed to the comment widget. - The
Pagestructure contains some 計算得出 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 Poll 會附加在評論上,而不是作為獨立的物件。它會在建立評論時一起建立(請參考 POST /api/v1/comments),或之後使用 PUT /api/v1/polls/:commentId 加到既有評論上。
投票計數保存在投票本身上,因此讀取投票即可取得結果,無需自行加總。計算背後的個別投票則是 PollVote 物件。
每個選項都有在建立投票時產生的 id。此 id 用於投票、重新標記選項,以及在使用 PUT 更新投票時保留選項(及其投票),不論是新增或移除選項。這是唯一安全的引用方式——絕不要以列表中的位置來指代選項。

Limits
- 必須提供問題,且長度上限為 200 個字元。
- 投票必須有 2 到 10 個選項。
- 必須提供選項標籤,長度上限為 100 個字元,且在同一投票中必須唯一(不分大小寫)。
closesAt必須在投票建立時設定為未來的時間。若要立即關閉投票,可使用PATCH並將日期設為過去。
Site Settings
投票遵循站台設定,您可以在「自訂小工具」下進行變更:
- 必須先啟用投票功能才能建立投票,否則 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 
從其評論中移除投票,並同時刪除所有已投的票。評論本身保持不變。
刪除評論會同時移除其投票與投票記錄,因此僅在您想保留評論時才需要此操作。



投票結果結構 
A PollVote 是單個使用者對投票的回答。投票本身顯示的計數會與這些保持同步,因此只有在想知道 誰 投了哪個選項,而不是總計時才需要這些資料。
每位投票者在同一個投票中最多只能有一票。再次投票會將他們原本的投票移至新選項,而不是新增第二票,updatedAt 會記錄此變更的時間。
voterId 為投票者登入時的 userId,若未登入則為 anonUserId。

隱私
投票的 privacy 設定對此 API 的作用方式與在評論小工具中的作用方式相同:
- Anonymous(預設):沒有人能看到任何人的投票方式,因此投票內容無法被讀取。
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 錯誤而失敗。請參閱 PollVote 結構以了解投票的 privacy 設定如何套用。



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 
撤回投票。投票所屬的選項會恢復其計數,且投票者可以再次投票。



Other Notes
- 刪除相同的投票兩次時,第二次會回傳
not-found,且計數保持不變。 - 如果自投票以來投票已被取代,投票會被移除,但計數不會變化,因為取代是從零開始的。
待處理Webhook事件結構 
A PendingWebhookEvent 物件代表一個排隊中的 webhook 事件,處於待處理狀態。
PendingWebhookEvent 物件會自動建立,且無法透過 API 手動建立。它們也會在一年後過期。
可以刪除它們,這會將任務從佇列中移除。
有不同的事件類型 - 請檢查 eventType(OutboundSyncEventType)和 type(OutboundSyncType)。
此 API 的常見使用情境是實作自訂監控。您可能會定期呼叫 /count 端點,以根據給定的篩選條件查詢未處理的計數。
PendingWebhookEvent 物件的結構如下:

GET /api/v1/pending-webhook-events 
此路由會回傳位於 pendingWebhookEvents 參數下的待處理 webhook 事件列表。
此 API 使用分頁,由 skip 參數提供。PendingWebhookEvents 以每頁 100 筆回傳,依 createdAt 由新到舊排序。



GET /api/v1/pending-webhook-events/count 
此路由會回傳一個物件,其在 count 參數中包含待處理的 webhook 事件數量。
您可以使用與 /pending-webhook-events 端點相同的參數進行篩選



DELETE /api/v1/pending-webhook-events/:id 
此路由允許刪除單一的 PendingWebhookEvent。
如果需要大量刪除,請先呼叫帶分頁的 GET API,然後依序呼叫此 API。



SSO 使用者結構 
FastComments 提供一個易於使用的 SSO 解決方案。使用基於 HMAC 的整合更新使用者資訊就像讓使用者載入含有更新 payload 的頁面一樣簡單。
然而,可能會希望在該流程之外管理使用者,以提高應用程式的一致性。
SSO 使用者 API 提供一種對我們稱為 SSOUsers 的物件進行 CRUD 的方式。這些物件與一般 Users 不同,為了型別安全而分開保存。
SSOUser 物件的結構如下:

SSO 使用者計費
SSO 使用者的計費會根據其權限標記而不同:
- Regular SSO Users:沒有管理或版主權限的使用者會以一般 SSO 使用者計費
- SSO Admins:具有
isAccountOwner或isAdminAdmin標記的使用者會被另外計費為 SSO 管理員(與一般租戶管理員相同費率) - SSO Moderators:具有
isCommentModeratorAdmin標記的使用者會被另外計費為 SSO 版主(與一般版主相同費率)
重要:為避免重複計費,系統會自動根據電子郵件地址對 SSO 使用者與一般租戶使用者及版主進行去重。如果 SSO 使用者的電子郵件與一般租戶使用者或版主相同,將不會重複計費。
存取控制
使用者可以被劃分為群組。這就是 groupIds 欄位的用途,且為選用。
@提及
預設情況下,當輸入 @ 字元時,@mentions 將使用 username 搜尋其他 SSO 使用者。如果使用 displayName,當有符合 displayName 的結果時,會忽略符合 username 的結果,且 @mention 的搜尋結果將使用 displayName。
訂閱
在 FastComments 中,使用者可以透過在留言元件中點擊鈴鐺圖示並點選訂閱,來訂閱某個頁面。
對於一般使用者,我們會根據他們的通知設定發送通知電子郵件。
對於 SSO 使用者,為了向後相容我們將此行為做了區分。僅當您將 optedInSubscriptionNotifications 設為 true 時,使用者才會收到這些額外的訂閱通知電子郵件。
徽章
您可以使用 badgeConfig 屬性為 SSO 使用者指派徽章。徽章是顯示在使用者名稱旁的視覺標示。
badgeIds- 指派給使用者的徽章 ID 陣列。這些為在所有頁面可見的全域徽章。必須是您 FastComments 帳戶中已建立的有效徽章 ID。限制為 30 個徽章。pageBadgeIds- 選用的徽章 ID 陣列,僅限於當前頁面(urlId)。這些徽章只會在指派它們的頁面上顯示。不同頁面對同一使用者可以有不同的頁面範圍徽章。override- 若為 true,所有現有顯示的徽章將被提供的徽章取代。全域與頁面範圍的徽章獨立覆蓋 — 覆蓋全域徽章不會影響頁面範圍徽章,反之亦然。若為 false 或省略,則會將提供的徽章新增到任何現有徽章上。update- 若為 true,使用者登入時會從租戶設定更新徽章顯示屬性。
GET /api/v1/sso-users 
此路由會以每頁 100 名的分頁方式回傳 SSO 使用者。分頁由 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 User HMAC payload 來覆寫。例如,如果 您透過 API 設定了一個 username,但在頁面載入時透過 SSO 流程傳遞了不同的 username,我們會自動更新 他們的 username。
除非您明確指定或將其設為 null(不是 undefined),否則我們不會在此流程中更新使用者參數。
PUT /api/v1/sso-users/:id 
此路由提供更新單一 SSO 使用者的功能。

在此範例中,我們為存取控制指定了 groupIds,但這是可選的。


DELETE /api/v1/sso-users/:id 
此路由可透過使用者的 id 刪除單一 SSO 使用者。
請注意,若再次以該使用者的 payload 載入留言小工具,系統會無縫地重新建立該使用者。
可透過查詢參數 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。可透過 Widget Customization UI 自訂這些內容。
範例



訂閱結構 
一個 Subscription 物件代表使用者的訂閱。
Subscription 物件會在使用者在評論小工具中點擊通知鈴鐺並點選 "訂閱此頁面" 時建立。
也可以透過 API 建立訂閱。
擁有 Subscription 物件會在與該 Subscription 相關聯的頁面
根層留下新留言時,會產生 Notification 物件並發送電子郵件。
是否發送電子郵件取決於使用者類型。對於一般使用者,這取決於 optedInNotifications。對於 SSO 使用者,則取決於 optedInSubscriptionNotifications。請注意,有些應用程式可能沒有可由網頁存取的頁面概念,在這種情況下,只需將 urlId 設為
您要訂閱的項目的 id(與傳遞給評論小工具的 urlId 值相同)。
以下為 Subscription 物件的結構:

GET /api/v1/subscriptions/:id 
此路由會回傳最多 30 個 Subscription 物件,依 createdAt 排序,最新的在前。
你可以以 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 物件。
TenantDailyUsage 物件 不是即時的,可能會比實際使用量落後數分鐘。
TenantDailyUsage 物件的結構如下:

GET /api/v1/tenant-daily-usage 
此路由允許按年份、月份和日期搜尋租戶的使用情況。最多可回傳 365 個物件,費用為每 10 個物件 1 個 API 點數。
回應物件依建立日期排序(最舊的在前)。



租戶結構 
The Tenant 定義 FastComments.com 的客戶。具有白標存取權的租戶可以透過 API 建立這些租戶。白標租戶無法建立其他白標租戶(僅允許一層巢狀)。
Tenant 物件的結構如下:

GET /api/v1/tenants/:id 
此路由會依 id 回傳單一 Tenant。



GET /api/v1/tenants 
此 API 回傳由您的租戶所管理的租戶。
分頁由 skip 查詢參數提供。租戶以每頁 100 筆回傳,依照 signUpDate 與 id 排序。
費用依回傳的租戶數量計算,每回傳 10 位租戶收取 1 credit。

您可以在 Tenant 物件上定義 meta 參數並查詢符合條件的租戶。例如,對於鍵 someKey 與 meta 值 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定義的租戶數量。 - 您必須指定
tenantId查詢參數,此參數為啟用白牌(white labeling)的parent tenant的 id。
我們只需少數參數即可建立 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 定義可供 Tenant 使用的方案資訊。租戶可能有多個可用方案,但在任何時間點僅能有一個被使用。
A 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 排序。
費用依回傳的 TenantPackages 數量計算,成本為 1 credit per 10 回傳的 TenantPackages。



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。



租戶使用者結構 
TenantUser 定義了一個由特定租戶管理的 User。他們的帳戶完全由所屬的租戶控制,且可以透過 UI 或 API 更新或刪除。
租戶使用者可以是擁有全部權限並可存取該 Tenant 的管理者,或僅限於特定權限以
管理留言、存取 API 金鑰等。
The structure for the TenantUser object is as follows: (Wait, original had backticks around whole sentence? Actually original was: The structure for the TenantUser object is as follows:)
TenantUser 物件的結構如下:

GET /api/v1/tenant-users/:id 
此路由會根據 id 回傳單一 TenantUser。



GET /api/v1/tenant-users 
此 API 使用分頁機制,由 skip 查詢參數提供。TenantUsers 以每頁 100 筆回傳,排序依序為 signUpDate、username 與 id。
費用依回傳的租戶使用者數量計算,花費為 1 credit per 10(每 10 位租戶使用者)。



POST /api/v1/tenant-users 
此路由提供新增單一 TenantUser 的功能。
建立 TenantUser 有下列限制:
username為必填。email為必填。signUpDate不能是未來的時間。locale必須位於 支援的語系 列表中。username必須在整個 FastComments.com 中唯一。如果這成為問題,我們建議改用 SSO。email必須在整個 FastComments.com 中唯一。如果這成為問題,我們建議改用 SSO。- 您不得建立超過套件中
maxTenantUsers定義的租戶使用者數量。
我們可依下列方式建立 TenantUser



POST /api/v1/tenant-users/:id/send-login-link 
此路由提供向單一 TenantUser 發送登入連結的功能。
在批量建立使用者且不需指示他們如何登入 FastComments.com 時非常有用。此操作會向他們發送一個可於 30 days 後過期的 "magic link" 用以登入。
發送登入連結給 TenantUser 時有下列限制:
- The
TenantUsermust already exist. - 您必須能管理該
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。
匿名化的評論
您可以保留使用者的評論,但透過設定 commentDeleteMode=1 來將其匿名化。
若使用者的評論被匿名化,則下列欄位會被設為 null:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badges
isDeleted 及 isDeletedUser 會被設為 true。
在渲染時,評論元件會使用 DELETED_USER_PLACEHOLDER(預設:"[deleted]")作為使用者名稱,並使用 DELETED_CONTENT_PLACEHOLDER 作為評論內容。這些可透過 Widget 自訂 UI 來自訂化。
範例



使用者結構 
User is an object that represents a most-common denominator of all users.
Keep in mind that at FastComments we have a bunch of different use cases for users:
- 安全 SSO
- 簡易 SSO
- 租戶使用者(例如:管理者)
- 留言者
This API is for 留言者 and users created via 簡易 SSO. Basically, any user created
through your site can be accessed via this API. Tenant Users can also be fetched this way, but you'll get more information by interacting with the /tenant-users/ API.
For Secure SSO please use the /sso-users/ API.
You cannot update these types of users. They created their account through your site, so we provide some basic read-only access, but
you cannot make changes. If you want to have this type of flow - you need to setup Secure SSO.
The structure for the User object is as follows:

GET /api/v1/users/:id 
此路由會根據 id 回傳單一使用者。



投票結構 
一個 Vote 物件代表使用者所留下的投票。
留言與投票之間的關係由 commentId 定義。
Vote 物件的結構如下:

GET /api/v1/votes 
投票必須透過 urlId 取得。
投票類型
有三種類型的投票:
- 已認證的投票,會套用到相對應的留言。您可以透過此 API 建立這些投票。
- 待驗證的已認證投票,因此尚未套用到留言。當使用者使用 FastComments.com login to vote 機制時,會建立這些投票。
- 匿名投票,會套用到相對應的留言。這些會在匿名留言時一併建立。
為了減少混淆,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)。




建立匿名投票
可透過在查詢參數中設定 anonUserId 而非 userId 來建立匿名投票。
此 id 不必對應到任何地方的使用者物件(因此為匿名)。它只是一個識別符, 用於識別會話,讓你能在相同會話中再次取得投票,以檢查某則留言是否已被投票。
如果你沒有像 FastComments 那樣的「匿名會話」,你可以將其設為隨機 ID,例如 UUID(但我們偏好較短的識別符以節省空間)。
其他備註
- 此 API 遵從租戶層級的設定。例如,若你對特定頁面停用投票,並嘗試透過 API 建立投票,會以錯誤代碼
voting-disabled失敗。 - 預設此 API 為上線狀態。
- 此 API 會更新對應
Comment的votes。
DELETE /api/v1/votes/:id 
此路由提供刪除單一 Vote 的功能。



Notes:
- This API obeys tenant-level settings. For example, if you disable voting for a given page, and you attempt to create a vote via the API, it will fail with error code
voting-disabled. - This API is live by default.
- This API will update the
votesof the correspondingComment.
網域設定結構 
A DomainConfig 物件代表租戶的網域設定。
DomainConfig 物件的結構如下:


For Authentication
Domain Configuration 用於決定哪些網站可以為您的帳號託管 FastComments 小工具。這是一種基本的驗證形式,意味著新增或移除任何 Domain Configurations 都可能影響您在正式環境中 FastComments 安裝的可用性。
除非確實要停用該網域,否則不要移除或更新 Domain Config 中的 domain 屬性,尤其是該網域目前仍在使用中。
此行為與從 /auth/my-account/configure-domains 移除網域的行為相同。
另請注意,從 My Domains 介面中移除網域,會同時刪除透過此 UI 新增的任何相對應設定。
For Email Customization
電子郵件底部的退訂連結,以及許多郵件客戶端提供的一鍵退訂功能,都可以透過此 API 設定,分別使用 footerUnsubscribeURL 與 emailHeaders。
For DKIM
在定義好 DKIM DNS 記錄後,只需使用上述結構將 DKIM 設定更新至 DomainConfig 即可。
GET /api/v1/domain-configs 
此 API 提供擷取租戶的所有 DomainConfig 物件的功能。



GET /api/v1/domain-configs/:domain 
可根據對應的 domain 取得個別的 DomainConfigs。



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 
此路由提供透過 id 移除單一 DomainConfig 的功能。
- 注意:移除
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 
這裡是結果彙總的地方。
彙總回應結構如下:

Here are the query parameters available for aggregation:

Here's an example request:

Example response:


效能注意事項
- 對於快取未命中,彙總通常每百萬筆結果約需五秒。
- 否則,請求為常數時間。
快取與費用說明
- 當
forceRecalculate是指定時,費用恆為10,而不是一般的2。 - 如果快取過期且資料被重新計算,若未指定
forceRecalculate,費用仍為固定的2。快取的過期時間取決於被彙總資料集的大小(可介於 30 秒到 5 分鐘之間)。 - 此機制是為了鼓勵使用快取。
GET /api/v1/question-results-aggregate/combine/comments 
這是將結果與留言結合的地方。舉例來說,對於建立某產品的「最近正面與負面留言」圖表非常有用。
你可以透過一個值範圍(包含端點)、一個或多個問題,以及起始日期(包含)來搜尋。
回應結構如下:

以下是可用於彙總的查詢參數:

這是一個範例請求:

範例回應:


快取與成本說明
- 當指定
forceRecalculate時,成本固定為10,而非通常的2。 - 如果快取過期且資料被重新計算,若未指定
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 取得特定使用者徽章。
範例請求:
Run 
範例回應:

可能的錯誤回應:


POST /api/v1/user-badges 
此端點允許您建立新的使用者徽章指派。
Example Request:
Run 
The request body must contain the following parameters:
userId(required) - 要指派徽章之使用者的 IDbadgeId(required) - 要指派之徽章的 IDdisplayedOnComments(optional) - 是否應在使用者的留言上顯示該徽章(預設為 true)
Important Notes:
- The badge must exist and be enabled in your tenant's badge catalog
- You can only assign badges to users who belong to your tenant or have commented on your site
Example Response:

Possible Error Responses:





PUT /api/v1/user-badges/:id 
此端點允許您更新使用者徽章指派。
目前,唯一可更新的屬性是 displayedOnComments,它用來控制該徽章是否在使用者的評論上顯示。
Example Request:
Run 
Example Response:

Possible Error Responses:



DELETE /api/v1/user-badges/:id 
此端點允許您刪除使用者徽章指派。
範例請求:
Run 
範例回應:

可能的錯誤回應:



使用者徽章進度結構 
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 擷取該使用者的徽章進度紀錄。
Example Request:
Run 
Example Response:

Possible Error Responses:



總結
我們希望您覺得我們的 API 文件詳盡且易於理解。如果您發現任何缺漏,請在下方告知我們。