
語言 🇹🇼 繁體中文
API 資源
彙總
稽核日誌
評論
電子郵件範本
主題標籤
版主
通知計數
通知
頁面
待處理 Webhook 事件
SSO 使用者
訂閱
租戶每日使用量
租戶
租戶方案
租戶使用者
使用者
投票
網域設定
問題設定
問題結果
問題結果彙總
使用者徽章
使用者徽章進度
FastComments 的 API
FastComments 提供一個可與多種資源互動的 API。可用來建立與我們平台的整合,或甚至自行建立客戶端!
在本文件中,您將會找到 API 支援的所有資源,並列出它們的請求與回應類型。
對於企業客戶,所有 API 存取都會被記錄在稽核日誌中。
已產生的 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
驗證
API 的驗證方式是將您的 api key 以 X-API-KEY 標頭或 API_KEY 查詢參數傳送。您還需要您的 tenantId 來進行 API 呼叫。這可以從與您的 api key 相同的頁面取得。
安全注意事項
這些路由應從 伺服器 呼叫。 請勿 從瀏覽器呼叫它們。這樣做會暴露您的 API key - 任何能查看頁面原始碼的人都會取得對您帳戶的完全存取權!
驗證選項一 - 標頭
- 標頭:
X-API-KEY - 標頭:
X-TENANT-ID
驗證選項二 - 查詢參數
- 查詢參數:
API_KEY - 查詢參數:
tenantId
API 資源 
資源使用
請注意,從 API 擷取資料會計入您帳戶的使用量。
每個資源會在其專屬章節列出該使用量。
有些資源的服務成本高於其他資源。每個端點在每次 API 呼叫時都有固定的點數成本。對於某些端點,點數數量 會根據選項和回應大小而變化。
API 使用情況可在 帳單分析 頁面檢查,且每幾分鐘更新一次。
注意!
我們建議先閱讀 Pages 文件,以便在為 Comment API 傳入 urlId 值時減少混淆。
彙整您的資料 
此 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 是一個物件,代表對有權使用此功能的租戶所記錄的稽核事件。
The structure for the AuditLog object is as follows:

稽核日誌是不可變的。也無法手動寫入。FastComments.com 可能是唯一能決定何時寫入稽核日誌的實體。不過,你可以透過此 API 讀取它。
Events in the audit log expire after two years.
GET /api/v1/audit-logs 
此 API 使用分頁,由 skip、before 與 after 參數提供。AuditLogs 會以每頁 1000 筆回傳,依 when 與 id 排序。
每取得 1000 筆日誌會花費 10 點額度。
預設會以 最新項目在前 的方式回傳清單。如此一來,您可以從 skip=0 開始輪詢,分頁直到找到您已消費的最後一筆紀錄。
或者,您可以將排序改為最舊優先,然後分頁直到沒有更多紀錄。
可透過將 order 設為 ASC 或 DESC 來設定排序。預設為 ASC。
可以使用帶毫秒的時間戳記透過 before 與 after 查詢日期。before 與 after 不包含邊界值。



評論結構 
一個 Comment 物件代表使用者留下的評論。
父子評論之間的關係由 parentId 定義。
Comment 物件的結構如下:

Some of these fields are marked READONLY - these are returned by the API but cannot be set.
評論文字結構
評論以 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 
HashTags
當使用 hashtag 並成功解析時,相關資訊會儲存在名為 hashTags 的清單中。該清單中的每個物件具有以下結構。若將 retain 設定為 true,hashtag 也可以手動加入至評論的 hashTags 陣列以供查詢。
Run 
GET /api/v1/comments 
此 API 用於取得要顯示給使用者的留言。例如,它會自動過濾未核准或垃圾留言。
分頁
分頁可以用兩種方式之一,取決於效能需求和使用情境:
- Fastest: Precalculated Pagination:
- 這是當您使用我們預建的小工具與客戶端時 FastComments 的運作方式。
- 點擊「下一頁」只是簡單地增加頁數。
- 你可以把這視為由鍵值儲存取得。
- 因此,只需定義從
0開始的page參數和一個作為direction的排序方向。 - 頁面大小可透過自訂規則進行調整。
- Most Flexible: Flexible Pagination:
- 在這種方式中你可以定義自訂的
limit和skip參數。不要傳遞page。 - 也支援排序
direction。 limit是在套用skip後要回傳的總數。- 例子:當
page size = 100且page = 2時,設定skip = 200, limit = 100。
- 例子:當
- 子留言仍會被計入分頁。你可以使用
asTree選項來避開這點。- 你可以透過
limitChildren和skipChildren對子留言進行分頁。 - 你可以透過
maxTreeDepth限制回傳的討論串深度。
- 你可以透過
- 在這種方式中你可以定義自訂的
討論串
- 當使用
Precalculated Pagination時,留言會以「頁」分組,而討論串內的留言會影響整體頁面。- 如此一來,客戶端可根據
parentId判斷討論串。 - 例如,某頁有一則頂層留言與 29 則回覆,並在 API 中設定
page=0— 你會只得到該頂層留言與 29 個子留言。 - 範例圖片,說明多頁情形。
- 如此一來,客戶端可根據
- 當使用
Flexible Pagination時,你可以定義parentId參數。- 將其設為 null 以僅取得頂層留言。
- 然後要查看討論串時,再次呼叫 API 並傳入
parentId。 - 常見的解法是先對頂層留言進行 API 呼叫,然後並行對每則留言的子留言進行 API 呼叫。
- NEW As of Feb 2023! 使用
&asTree=true以樹狀方式取得。- 你可以把這視為
Flexible Pagination as a Tree。 - 分頁僅計算頂層留言。
- 將
parentId=null設為樹的根(你必須設定parentId)。 - 設定
skip和limit以進行分頁。 - 將
asTree設為true。 - 消耗的信用額度會增加為
2x,因為後端在此情況下須做更多工作。 - 視需要設定
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 端點提供建立評論的功能。
常見用例包括自訂使用者介面、整合或匯入。
注意事項:
- 如果需要,此 API 可以「即時」更新評論小工具(這會將
creditsCost從1增加到2)。 - 如果提供了 email,這個 API 會自動在系統中建立使用者物件。
- 嘗試儲存兩則使用不同 email 但相同使用者名稱的評論,第二則評論會發生錯誤。
- 如果您指定了
parentId,且子評論的notificationSentForParent為 false,我們將會為父評論發送通知。此操作每小時進行(我們會將通知批次一起發送以減少郵件數量)。 - 如果您想在建立使用者時發送歡迎郵件,或想發送評論驗證郵件,請在查詢參數中將
sendEmails設為true。 - 透過此 API 建立的評論將顯示在管理應用程式的 Analytics 與 Moderation 頁面中。
- 如果該設定已開啟,評論者名稱與評論文字中的「髒話」仍會被遮罩。
- 透過此 API 建立的評論仍可視需要進行垃圾訊息檢查。
- 若透過「自訂規則」管理頁面設定的配置(例如最大評論長度)將在此處套用。
要在評論小工具中顯示,提交的最小資料如下:

更實際的請求範例如下:



PATCH /api/v1/comments/:id 
此 API 端點提供更新單一留言的功能。
注意事項:
- 如需,此 API 可以使留言小工具「即時」更新(會將基本
creditsCost從1提高到2)。- 這可讓在不同頁面之間遷移留言成為「即時」(變更
urlId)。 - 遷移會額外花費
2點數,因為頁面會被預先計算,且這對 CPU 要求高。
- 這可讓在不同頁面之間遷移留言成為「即時」(變更
- 與建立 API 不同,若提供電子郵件,本 API 不會在我們系統中自動建立使用者物件。
- 透過本 API 更新的留言仍可在需要時進行垃圾留言檢查。
- 透過自訂規則(Customization Rule)管理頁面設定的配置(例如最大留言長度)也會在此適用。
- 若要允許使用者更新留言內容,只需在請求主體中指定
comment。我們將產生對應的commentHTML。- 如果同時定義
comment與commentHTML,我們將不會自動生成 HTML。 - 如果使用者在新文字中加入提及或主題標籤(hashtags),仍會像
POSTAPI 一樣進行處理。
- 如果同時定義
- 在更新留言的
commenterEmail時,最好同時指定userId。否則,您必須確保該電子郵件對應的使用者屬於您的租戶,否則請求將失敗。



DELETE /api/v1/comments/:id 
此 API 端點提供刪除留言的功能。
注意事項:
- 此 API 可以在需要時即時更新留言小工具(live)。這會將
creditsCost從1提高到2。 - 此 API 會刪除所有子留言。



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)。



主題標籤結構 
一個 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 建立,否則使用者在留言時提供該標籤時,該標籤可能會被重新建立。



版主結構 
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 object represents a notification for a user.
Notification objects are created automatically and cannot be created via the API. They also expire after one year.
Notifications cannot be deleted. They can however be updated to set viewed to false, and you can query by viewed.
A user may also opt out of notifications for a specific comment by setting optedOut in the notification to true. You can opt in again by setting it to false.
There are different notification types - check relatedObjectType and type.
The ways notifications are created is quite flexible and can be triggered by many scenarios (see NotificationType).
As of today, the existence of a Notification does not actually imply an email is or should be sent. Rather, the notifications
are used for the notification feed and related integrations.
The structure for the Notification object is as follows:

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



頁面結構 
一個 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。



待處理 Webhook 事件結構 
A PendingWebhookEvent object represents a queued webhook event that is pending.
PendingWebhookEvent objects are created automatically and cannot be manually created via the API. They also expire after one year.
They can be deleted which removes the task from the queue.
There are different event types - check eventType (OutboundSyncEventType) and type (OutboundSyncType).
A common use case for this API is to implement custom monitoring. You may want to call the /count endpoint periodically
to poll the outstanding count for given filters.
The structure for the PendingWebhookEvent object is as follows:

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 的整合更新使用者資訊,就像讓使用者載入帶有更新載荷的頁面一樣簡單。
不過,您可能會希望在該流程之外管理使用者,以改善應用程式的一致性。
SSO 使用者 API 提供一種對我們稱為 SSOUser 的物件進行 CRUD 的方式。這些物件不同於一般的 Users,並為了型別安全而分開保存。
SSOUser 物件的結構如下:

SSO 使用者計費
SSO 使用者會根據其權限標記以不同方式計費:
- 一般 SSO 使用者:沒有管理員或版主權限的使用者將以一般 SSO 使用者計費
- SSO 管理員:具有
isAccountOwner或isAdminAdmin標記的使用者會被另外計費為 SSO 管理員(與一般租戶管理員相同費率) - SSO 版主:具有
isCommentModeratorAdmin標記的使用者會被另外計費為 SSO 版主(與一般版主相同費率)
重要:為了避免重複計費,系統會自動根據電子郵件地址將 SSO 使用者與一般租戶使用者和版主去重。如果 SSO 使用者與一般租戶使用者或版主具有相同的電子郵件,則不會被重複計費。
存取控制
使用者可以被分到不同群組。這就是 groupIds 欄位的用途,且為選用。
@ 提及
預設情況下,當輸入 @ 字元時,@mentions 會使用 username 來搜尋其他 SSO 使用者。如果使用 displayName,當 displayName 有匹配時,符合 username 的結果將被忽略,而 @mention 的搜尋結果會使用 displayName。
訂閱
在 FastComments 中,使用者可以透過在留言小工具中點擊鈴鐺圖示並選擇訂閱來訂閱頁面。
對於一般使用者,我們會根據他們的通知設定發送通知電子郵件。
對於 SSO 使用者,我們為了向後相容將此行為拆分。只有當您將 optedInSubscriptionNotifications 設為 true 時,使用者才會收到這些額外的訂閱通知電子郵件。
徽章
您可以使用 badgeConfig 屬性為 SSO 使用者指定徽章。徽章是在留言中顯示於使用者名稱旁的視覺指標。
badgeIds- 指派給使用者的徽章 ID 陣列。這些必須是您在 FastComments 帳戶中建立的有效徽章 ID。最多限制為 30 個徽章。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
- badgesisDeleted 與 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 object represents the usage for a tenant on a given day. If there was no activity for a given tenant on a given
day, that day will not have a TenantDailyUsage object.
The TenantDailyUsage object is not real time and may be minutes behind actual usage.
The structure for the TenantDailyUsage object is as follows:

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 theTenantUserobject 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
- badgesisDeleted 及 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 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 移除網域也會刪除此介面中為該網域新增的任何對應設定。
用於電子郵件自訂
電子郵件頁尾的退訂連結,以及許多郵件用戶端提供的一鍵退訂功能,可以透過此 API 分別定義 footerUnsubscribeURL 與 emailHeaders 來設定。
用於 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 系統中使用者的徽章。
徽章可以根據使用者的活動自動分配(例如留言數、回覆時間、資深使用者狀態),或由網站管理員手動分配。
以下為 UserBadge 物件的結構:

GET /api/v1/user-badges 
此端點允許您根據各種條件取得使用者徽章。
Example Request:
Run 
You can add various query parameters to filter the results:
userId- 取得特定使用者的徽章badgeId- 取得特定徽章的實例type- 依徽章類型篩選 (0=CommentCount, 1=CommentUpVotes, 2=CommentReplies, etc. See UserBadge structure for full list)displayedOnComments- 根據徽章是否顯示於評論上篩選 (true/false)limit- 要返回的徽章最多數量 (預設 30, max 200)skip- 要跳過的徽章數量 (for pagination)
Example Response:

Possible Error Responses:


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 文件詳盡且易於理解。如果您發現任何缺漏,請在下方告知我們。