
语言 🇨🇳 简体中文
API 资源
聚合
审计日志
评论
邮件模板
标签
版主
通知计数
通知
页面
待处理 Webhook 事件
SSO 用户
订阅
租户每日使用量
租户
租户套餐
租户用户
用户
投票
域配置
问题配置
问题结果
问题结果聚合
用户徽章
用户徽章进度
FastComments API
FastComments 提供用于与多个资源交互的 API。可与我们的平台构建集成,或构建您自己的客户端!
在本文档中,您将找到 API 支持的所有资源的文档及其请求和响应类型。
对于企业客户,所有 API 访问都会记录在审核日志中。
生成的 SDK
FastComments 现在从我们的代码生成了一个 API 规范(尚未完成,但包含许多 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 密钥 作为 X-API-KEY 请求头或 API_KEY 查询参数传递来完成。您在调用 API 时还需要 tenantId。可以从与您的 api key 相同的页面检索到它。
安全提示
这些路由应从 服务器 调用。 切勿 从浏览器调用它们。这样会暴露您的 API 密钥——任何能查看页面源代码的人都将获得对您帐户的完全访问权限!
身份验证选项一 - 请求头
- 请求头:
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 查询参数在一次调用中聚合所有子租户资源。
示例
示例:统计唯一值


示例:统计不同值

响应:

示例:多个字段求和

响应:

示例:多个字段平均值

响应:

示例:多个字段最小/最大值

响应:

示例:多个字段统计唯一值

响应:

示例:创建查询示例

响应:

示例:统计待审核评论

响应:

示例:已批准、已审核和垃圾评论的分类统计

响应:

结构


以下资源可被聚合:
- 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 读取它。
审计日志中的事件在两年后过期。
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 对象的结构如下:

其中一些字段标注为 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 数组中以便查询。
Run 
GET /api/v1/comments 
此 API 用于获取要向用户显示的评论。例如,它会自动过滤掉未批准或垃圾评论。
分页
分页可以根据性能需求和用例通过两种方式之一完成:
- 最快:预计算分页(Precalculated Pagination):
- 当您使用我们预构建的小部件和客户端时,这就是 FastComments 的工作方式。
- 单击“下一页”仅会增加页数。
- 您可以将其视为通过键值存储检索。
- 用这种方式,只需定义从
0开始的page参数和作为direction的排序方向。 - 页面大小可以通过自定义规则进行调整。
- 最灵活:灵活分页(Flexible Pagination):
- 在这种方式中,您可以定义自定义的
limit和skip参数。不要传递page。 - 也支持排序
direction。 limit是在应用了skip后要返回的总数量。- 示例:当页面大小 = 100 且
page = 2时,设置skip = 200, limit = 100。
- 示例:当页面大小 = 100 且
- 子评论仍计入分页。您可以使用
asTree选项绕过此问题。- 您可以通过
limitChildren和skipChildren对子评论进行分页。 - 您可以通过
maxTreeDepth限制返回的线程深度。
- 您可以通过
- 在这种方式中,您可以定义自定义的
线程(Threads)
- 使用
Precalculated Pagination时,评论按页面分组,线程中的评论会影响整个页面。- 这样,线程可以基于客户端的
parentId来确定。 - 例如,在一个页面中有一个顶级评论和 29 个回复,并在 API 中设置
page=0—— 您将只获得顶级评论和这 29 个子评论。 - 示例图,说明多页。
- 这样,线程可以基于客户端的
- 使用
Flexible Pagination时,您可以定义parentId参数。- 将其设置为 null 以仅获取顶级评论。
- 然后要查看线程,请再次调用 API 并传递
parentId。 - 一个常见的解决方案是对顶级评论进行一次 API 调用,然后并行调用 API 以获取每个评论的子评论。
- 新功能(截至 2023 年 2 月)! 使用
&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 端点提供创建评论的功能。
常见用例包括自定义 UI、集成或导入。
注意:
- 如果需要,此 API 可以将评论小部件实时更新(这会将
creditsCost从1增加到2)。 - 如果提供了电子邮件地址,此 API 会在我们的系统中自动创建用户对象。
- 尝试保存两个电子邮件不同但用户名相同的评论,会导致第二条评论出现错误。
- 如果您指定了
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 更新的评论仍可以在需要时进行垃圾邮件检查。
- 通过自定义规则管理页面配置的设置(例如最大评论长度)也会在此适用。
- 要允许用户更新评论文本,只需在请求体中指定
comment。我们将生成相应的commentHTML。- 如果同时定义了
comment和commentHTML,我们将不会自动生成 HTML。 - 如果用户在新文本中添加了提及或标签(hashtags),仍会像
POSTAPI 那样进行处理。
- 如果同时定义了
- 在更新评论的
commenterEmail时,最好同时指定userId。否则,您必须确保该电子邮件对应的用户属于您的租户,否则请求将失败。



DELETE /api/v1/comments/:id 
此 API 端点提供删除评论的功能。
Notes:
- 如果需要,此 API 可以实时更新评论小部件(这会将
creditsCost从1提高到2)。 - 此 API 将删除该评论的所有子评论。



POST /api/v1/comments/:id/flag 
此 API 端点提供为特定用户标记评论的功能。
Notes:
- 此调用必须始终在用户上下文中进行。该用户可以是 FastComments.com 用户、SSO 用户或租户用户。
- 如果设置了用于隐藏的标记阈值,评论在被标记达到定义次数后将会被实时自动隐藏。
- 在评论被自动取消批准(隐藏)之后,只有管理员或版主可以重新批准该评论。取消标记不会重新批准评论。

对于匿名标记,我们必须指定一个 anonUserId。这可以是代表匿名会话的 ID,或随机 UUID。
这允许我们在用户未登录的情况下也支持对评论的标记和取消标记。这样,当使用相同的 anonUserId 获取评论时,该评论可以被标记为已标记。



POST /api/v1/comments/:id/un-flag 
此 API 端点提供取消特定用户对评论的标记的能力。
Notes:
- 此调用必须始终在用户上下文中进行。该用户可以是 FastComments.com 用户、SSO 用户或租户用户。
- 在评论被自动取消批准(隐藏)后——该评论只能由管理员或版主重新批准。取消标记不会重新批准该评论。

对于匿名标记,我们必须指定 anonUserId。这可以是表示匿名会话的 ID,或一个随机 UUID。



POST /api/v1/comments/:id/block 
此 API 端点提供封锁撰写特定评论的用户的能力。它支持对由 FastComments.com 用户、SSO 用户和租户用户撰写的评论进行封锁。
它支持一个名为 commentIdsToCheck 的 body 参数,用于在执行此操作后检查客户端上是否有任何其他可能可见的评论应被封锁/解封。
Notes:
- 此调用必须始终在某个用户的上下文中进行。该用户可以是 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 请求体参数,用于在执行此操作后检查客户端上其他可能可见的评论是否应被封禁/解封。
注意:
- 此调用必须始终在用户上下文中进行。该用户可以是 FastComments.com 用户、SSO 用户或租户用户。
- 请求中的
userId是正在执行解除封禁操作的用户。例如:User A想要解除对User B的封禁。传入userId=User A以及User B所写的评论 id。 - 完全匿名的评论(没有用户 id、没有电子邮件)无法被封禁,会返回错误。




邮件模板结构 
EmailTemplate 对象表示租户的自定义电子邮件模板的配置。
系统将通过以下方式选择要使用的电子邮件模板:
- 其类型标识符,我们称之为
emailTemplateId。这些是常量。 domain。我们会首先尝试查找与相关对象(例如Comment)关联的域的模板,如果未找到匹配项,则会尝试查找 domain 为 null 或*的模板。
EmailTemplate 对象的结构如下:

注意
- 您可以从
/definitions端点获取有效的emailTemplateId值。 /definitions端点还包含默认翻译和测试数据。- 如果结构或测试数据无效,模板将保存失败。
GET /api/v1/email-templates/:id 
可以通过相应的 id(不是 emailTemplateId)获取单个 EmailTemplate。



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仅在你有不同域名,或想为测试使用特定模板(例如将domain设置为localhost)时才相关。 - 如果你确实指定了
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 以每页 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 创建,否则用户在评论时提供该话题标签时可能会重新创建它们。



版主结构 
Moderator 对象表示版主的配置。
有三种类型的版主:
- 拥有
isCommentModeratorAdmin标志的管理员用户。 - 拥有
isCommentModeratorAdmin标志的 SSO 用户。 - 普通评论者,或被邀请为版主的 FastComments.com 用户。
Moderator 结构用于表示用例 3 的审核状态。
如果您想通过 API 邀请用户成为版主,请使用 Moderator API,创建一个 Moderator 并邀请他们。
如果用户没有 FastComments.com 帐户,邀请邮件会帮助他们完成设置。如果他们已有帐户,他们将
被授予对您租户的审核访问权限,并且 Moderator 对象的 userId 会更新为指向他们的用户。您将无法通过 API
访问他们的用户,因为在这种情况下该用户属于他们自己并由 FastComments.com 管理。
如果您需要完全管理该用户的帐户,我们建议使用 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 提供。版主以每页 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 的功能。
向 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 创建。它们也会在一年后过期。
您可以通过删除用户的 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>。
这将清除用户的未读通知计数(评论小部件中的红色铃铛会淡出,计数将消失)。



通知结构 
一个 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



页面结构 
A Page 对象表示许多评论可能属于的页面。此关系由
urlId 定义。
A 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 对象中的某些参数会自动更新。这些是 counts 和 title 属性。Counts 不能通过 API 更新,因为它们是计算得出的值。页面的 title 可以通过 API 设置,但如果评论小部件在具有相同 urlId 但不同页面标题的页面上使用,则会被覆盖。
POST /api/v1/pages 
此 API 端点提供创建页面的功能。
一个常见的用例是访问控制。
注意:
- 如果您已经在评论线程中发表评论,或调用 API 创建了一个
Comment,您已经创建了一个Page对象!您可以尝试通过/by-url-idPage路由获取它,传入与评论小部件相同的urlId。 Page结构包含一些 计算得出 的值。当前这些是commentCount和rootCommentCount。它们会自动填充,不能由 API 设置。尝试设置这些值会导致 API 返回错误。



DELETE /api/v1/pages/:id 
此路由用于通过 id 删除单个页面。
请注意,对具有相同 urlId 的页面的评论小部件进行交互将简单地无缝重新创建该 Page。



待处理 Webhook 事件结构 
一个 PendingWebhookEvent 对象表示一个处于排队等待中的 webhook 事件。
PendingWebhookEvent 对象会自动创建,不能通过 API 手动创建。它们也会在一年后过期。
可以删除它们,从而将任务从队列中移除。
存在不同的事件类型 —— 请检查 eventType (OutboundSyncEventType) 和 type (OutboundSyncType)。
此 API 的一个常见用例是实现自定义监控。你可能希望定期调用 /count 端点,以轮询给定筛选器下的未完成数量。
PendingWebhookEvent 对象的结构如下:

GET /api/v1/pending-webhook-events 
此路由返回一个待处理的 webhook 事件列表,包含在 pendingWebhookEvents 参数中。
此 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 provides an easy to use SSO solution. Updating a user's information with the HMAC-based integration is as simple as having the user load the page with an updated payload.
但是,可能希望在该流程之外管理用户,以提高应用程序的一致性。
The SSO User API provides a way to CRUD objects that we call SSOUsers. These objects are different from regular Users and kept separate for type safety.
SSOUser 对象的结构如下:

Billing for SSO Users
SSO users are billed differently based on their permission flags:
- Regular SSO Users: Users without admin or moderator permissions are billed as regular SSO users
- SSO Admins: Users with
isAccountOwnerorisAdminAdminflags are billed separately as SSO Admins (same rate as regular tenant admins) - SSO Moderators: Users with
isCommentModeratorAdminflag are billed separately as SSO Moderators (same rate as regular moderators)
Important: To prevent double billing, the system automatically deduplicates SSO users against regular tenant users and moderators by email address. If an SSO user has the same email as a regular tenant user or moderator, they will not be billed twice.
SSO 用户的计费
根据权限标志,SSO 用户的计费方式不同:
- 常规 SSO 用户:没有管理员或版主权限的用户按常规 SSO 用户计费
- SSO 管理员:具有
isAccountOwner或isAdminAdmin标志的用户将作为 SSO 管理员单独计费(与常规租户管理员费率相同) - SSO 版主:具有
isCommentModeratorAdmin标志的用户将作为 SSO 版主单独计费(与常规版主费率相同)
重要:为防止重复计费,系统会根据电子邮件地址自动对 SSO 用户与常规租户用户和版主进行去重。如果 SSO 用户与常规租户用户或版主的电子邮件相同,则不会被重复计费。
Access Control
Users can be broken into groups. This is what the groupIds field is for, and is optional.
访问控制
用户可以被划分为组。这就是 groupIds 字段的用途,且为可选。
@Mentions
By default @mentions will use username to search for other sso users when the @ character is typed. If displayName is used, then results matching
username will be ignored when there is a match for displayName, and the @mention search results will use displayName.
@提及
默认情况下,当输入 @ 字符时,@mentions 将使用 username 来搜索其他 SSO 用户。如果使用 displayName,当有与 displayName 匹配时,
与 username 匹配的结果将被忽略,@mention 搜索结果将使用 displayName。
Subscriptions
With FastComments, users can subscribe to a page by clicking the bell icon in the comment widget and clicking Subscribe.
With a regular user, we send them notification emails based on their notification settings.
With SSO Users, we split this up for backwards compatibility. Users will only get sent these additional subscription notification
emails if you set optedInSubscriptionNotifications to true.
订阅
在 FastComments 中,用户可以通过在评论小部件中点击铃铛图标并选择订阅来订阅页面。
对于常规用户,我们会根据他们的通知设置向其发送通知电子邮件。
对于 SSO 用户,我们为向后兼容而进行了拆分。只有当您将 optedInSubscriptionNotifications 设置为 true 时,用户才会收到这些额外的订阅通知
电子邮件。
Badges
You can assign badges to SSO users using the badgeConfig property. Badges are visual indicators that appear next to a user's name in comments.
badgeIds- An array of badge IDs to assign to the user. These must be valid badge IDs created in your FastComments account. Limited to 30 badges.override- If true, all existing badges displayed on comments will be replaced with the provided ones. If false or omitted, the provided badges will be added to any existing badges.update- If true, badge display properties will be updated from the tenant configuration whenever the user logs in.
徽章
您可以使用 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,但这是可选的。


Integration Note
通过 API 传递的数据可以通过传递不同的 SSO 用户 HMAC 有效负载来覆盖。例如, if you set a username via the API, but then pass a different one via the SSO flow on page load, we will automatically update their username.
除非您显式指定这些参数或将其设置为 null(而不是 undefined),否则我们不会在此流程中更新用户参数。
PUT /api/v1/sso-users/:id 
此路由提供更新单个 SSO 用户的功能。

在此示例中,我们为访问控制指定了 groupIds,但这是可选的。


DELETE /api/v1/sso-users/:id 
此路由根据其 id 删除单个 SSO 用户。
请注意,如果使用该用户的有效负载重新加载评论小部件,系统会无缝地重新创建该用户。
可以通过查询参数 deleteComments 删除该用户的评论。请注意,如果该值为 true:
- 该用户的所有评论将被实时删除。
- 所有 child(现在成为孤儿)的评论将根据每个评论关联页面的配置被删除或匿名化。例如,如果线程删除模式为 "anonymize",则回复将保留,而该用户的评论将被匿名化。仅当
commentDeleteMode为Remove(默认值)时适用。 creditsCost将变为2。
匿名化的评论
您可以保留该用户的评论,但通过设置 commentDeleteMode=1 将其匿名化。
如果该用户的评论被匿名化,则以下字段将被设置为 null:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badgesisDeleted 和 isDeletedUser 将被设置为 true。
在渲染时,评论小部件将在用户名称处使用 DELETED_USER_PLACEHOLDER(默认值: "[deleted]")和在评论处使用 DELETED_CONTENT_PLACEHOLDER。这些可以通过小部件自定义界面进行自定义。
示例



订阅结构 
A Subscription object 表示用户的订阅。
Subscription objects 在用户在评论小部件中点击通知铃铛并点击 "订阅此页面" 时创建。
Subscriptions 也可以通过 API 创建。
Having a Subscription object causes Notification objects to be generated, and emails sent, when new comments are left on the root of the associated page
that the Subscription is for. 电子邮件的发送取决于用户类型。对于普通用户,这取决于 optedInNotifications。对于 SSO 用户,这取决于 optedInSubscriptionNotifications。注意,有些应用可能没有可通过 Web 访问的页面的概念,在这种情况下,只需将 urlId 设置为您要订阅的项目的 id(与传递给评论小部件的 urlId 值相同)。
The structure for the Subscription object is as follows:

GET /api/v1/subscriptions/:id 
此路由返回最多 30 个按 createdAt 排序的 Subscription 对象,最新的在前。
您可以按 userId 过滤。使用 SSO 时,用户 ID 的格式为 <tenant id>:<user id>。



POST /api/v1/subscriptions 
此 API 端点提供创建 Subscription 的功能。请注意,每个用户每个页面只能有一个订阅,因为多个订阅是多余的,尝试为同一用户在同一页面创建多个订阅将导致错误。
当在被订阅的 urlId 的根处留下新评论时(即评论的 parentId 为 null),创建订阅将导致生成 Notification 对象。



DELETE /api/v1/subscriptions/:id 
此路由通过 id 删除单个 Subscription 对象。



租户每日使用量结构 
一个 TenantDailyUsage 对象表示租户在某一天的使用情况。如果在某租户的某个给定
天没有活动,则该天将不会有 TenantDailyUsage 对象。
The TenantDailyUsage object is 不是 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 创建它们。白标租户
不能创建其他白标租户(只允许一层嵌套)。
The structure for the Tenant object is as follows:

GET /api/v1/tenants/:id 
此路由按 id 返回单个 Tenant。



GET /api/v1/tenants 
此 API 返回由您的租户管理的租户。
分页由查询参数 skip 提供。租户以每页 100 个返回,按 signUpDate 和 id 排序。
费用基于返回的租户数量,按 1 credit per 10 租户计费。

您可以在 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查询参数,该参数是启用白标的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。



租户套餐结构 
TenantPackage 定义了可供 Tenant 使用的套餐信息。一个租户可能有多个可用的套餐,但在任意时刻只有一个处于使用中。
Tenant 在其 packageId 指向一个有效的 TenantPackage 之前,不能用于任何产品。
有两种类型的 TenantPackage 对象:
- 固定定价包 - 当
hasFlexPricing为 false 时。 - 灵活定价 - 当
hasFlexPricing为 true 时。
在两种情况下,使用该套餐的账号都会定义限制,然而在灵活(Flex)定价中,租户会被收取基础费用加上其实际使用量,使用 flex* 参数来定义。
租户可以拥有多个租户套餐,并可以从 账单信息页面. 自行更改所使用的套餐。
如果您将自行为租户处理计费,您仍需为每个租户定义一个套餐以规定其限额。只需在 Tenant 上将 billingHandledExternally 设置为 true,他们就无法自行更改其账单信息或当前使用的套餐。
您不得创建比父租户限额更高的套餐。
TenantPackage 对象的结构如下:

GET /api/v1/tenant-packages/:id 
此路由通过 id 返回单个 Tenant Package。



GET /api/v1/tenant-packages 
此 API 使用分页,由 skip 查询参数提供。TenantPackages 按 100 条每页返回,按 createdAt 和 id 排序。
计费基于返回的 tenant packages 数量,计费为 1 credit per 10 个 tenant packages。



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 密钥等。
TenantUser 对象的结构如下:

GET /api/v1/tenant-users/:id 
此路由按 id 返回单个 TenantUser。



GET /api/v1/tenant-users 
此 API 使用分页,通过查询参数 skip 提供。TenantUsers 以每页 100 条的形式返回,按 signUpDate、username 和 id 排序。
费用基于返回的租户用户数量计算,每返回 10 个租户用户消耗 1 积分。



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 后过期。
发送登录链接到 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必须在 Supported Locales 列表中。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 作为评论内容。这些可以通过小部件自定义界面进行定制。
示例



用户结构 
User 是表示所有用户的最通用属性的对象。
请记住,在 FastComments 中,我们有多种不同的用户使用场景:
- Secure SSO
- Simple SSO
- Tenant Users (例如:管理员)
- Commenters
This API is for Commenters and users created via Simple 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 返回单个用户。



投票结构 
A Vote 对象表示用户留下的投票。
评论与投票之间的关系通过 commentId 来定义。
Vote 对象的结构如下:

GET /api/v1/votes 
必须通过 urlId 来获取投票。
投票类型
投票有三种类型:
- 经过身份验证的投票,会应用到相应的评论。您可以通过此 API 创建这些投票。
- 经过身份验证的投票,但处于待验证状态,因此尚未应用于评论。当用户使用 FastComments.com 的 登录以投票 机制时,会创建这些投票。
- 匿名投票,会应用到相应的评论。这些与匿名评论一起创建。
为了减少混淆,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 不必与任何地方的用户对象对应(因此为匿名)。它只是会话的一个标识符 for the session, so you can fetch votes again in the same session, to check if a comment has been voted.
如果您没有像 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 界面移除域将删除通过该界面为该域添加的任何对应配置。
用于电子邮件自定义
电子邮件页脚中的退订链接以及许多邮件客户端提供的一键退订功能,可以通过此 API 分别通过定义 footerUnsubscribeURL 和 emailHeaders 来配置。
用于 DKIM
在定义好 DKIM DNS 记录后,只需使用前述结构将您的 DKIM 配置更新到 DomainConfig 即可。
GET /api/v1/domain-configs 
此 API 提供获取租户的所有 DomainConfig 对象的能力。



GET /api/v1/domain-configs/:domain 
单个 DomainConfigs 可通过其对应的 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 
此路由用于按 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 
这里进行结果的聚合。
聚合响应结构如下:

以下是可用于聚合的查询参数:

下面是一个示例请求:

示例响应:


性能说明
- 对于缓存未命中的情况,聚合通常每百万条结果大约需要五秒。
- 否则,请求为常数时间。
缓存与费用说明
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 
此端点允许您根据各种条件获取用户徽章。
示例请求:
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 
此端点允许您创建新的用户徽章分配。
示例请求:
Run 
请求体必须包含以下参数:
userId(required) - 要分配徽章的用户 IDbadgeId(required) - 要分配的徽章 IDdisplayedOnComments(optional) - 徽章是否应显示在用户的评论上(默认为 true)
重要说明:
- 徽章必须存在于您的租户徽章目录中并已启用
- 您只能将徽章分配给属于您的租户的用户或在您的网站上发表评论的用户
响应示例:

可能的错误响应:





PUT /api/v1/user-badges/:id 
This endpoint allows you to update a user badge assignment.
Currently, the only property that can be updated is displayedOnComments, which controls whether the badge is displayed on the user's comments.
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 获取该用户的徽章进度记录。
示例请求:
Run 
示例响应:

可能的错误响应:



总结
我们希望您认为我们的 API 文档详尽且易于理解。如果您发现任何遗漏,请在下方告诉我们。