
言語 🇯🇵 日本語
APIリソース
集計
監査ログ
コメント
メールテンプレート
ハッシュタグ
モデレーター
通知数
通知
ページ
保留中のWebhookイベント
SSOユーザー
サブスクリプション
テナント日次使用量
テナント
テナントパッケージ
テナントユーザー
ユーザー
投票
ドメイン設定
質問設定
質問結果
質問結果の集計
ユーザーバッジ
ユーザーバッジ進捗
FastComments の API
FastComments は多数のリソースとやり取りするための API を提供しています。プラットフォームと統合を構築したり、独自のクライアントを作成したりできます!
このドキュメントでは、API がサポートするすべてのリソースを、リクエストとレスポンスの型とともに記載しています。
エンタープライズ顧客向けに、すべての API アクセスは監査ログに記録されます。
生成された SDK
FastComments はコードから API 仕様 を生成するようになりました(まだ完全ではありませんが、多くの API が含まれています)。
We also now have SDKs for popular languages:
- 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 キー と同じページから取得できます。
セキュリティに関する注意
これらのルートはサーバーから呼び出すことを想定しています。ブラウザから呼び出さないでください。そうすると API キーが公開されてしまい、ページのソースコードを閲覧できる誰にでもアカウントへの完全なアクセス権が与えられてしまいます!
認証オプション 1 - ヘッダー
- ヘッダー:
X-API-KEY - ヘッダー:
X-TENANT-ID
認証オプション 2 - クエリパラメータ
- クエリパラメータ:
API_KEY - クエリパラメータ:
tenantId
APIリソース 
リソース使用量
API からデータを取得する行為は、お客様のアカウントの使用量としてカウントされる点にご注意ください。
各リソースは、その使用量を個別のセクションに記載しています。
リソースによっては、提供にかかるコストが高いものがあります。各エンドポイントには API 呼び出しごとに固定のクレジットコストが設定されています。いくつかのエンドポイントでは、オプションやレスポンスのサイズに応じて必要なクレジット数が変動します。
API の使用状況は 請求アナリティクス ページで確認でき、数分ごとに更新されます。
注意!
Comment API で urlId に渡す値を決める際の混乱を減らすため、まず Pages のドキュメントをお読みになることをお勧めします。
データを集計する 
このAPIは、ドキュメントをグループ化(groupByが提供されている場合)し、複数の操作を適用して集計を行います。 sum、countDistinct、avg などのさまざまな操作がサポートされています。
コストは可変です。500件のオブジェクトをスキャンするごとに1 APIクレジットが消費されます。
デフォルトでは、APIコールごとの最大メモリ使用量は64MBで、デフォルトでは同時に実行できる集計は1つだけです。複数の集計を同時に送信すると、それらはキューに入り、送信された順に実行されます。保留中の集計は最大60秒待機し、それを超えるとリクエストはタイムアウトします。個々の集計は最大で5分間実行される場合があります。
管理されたテナントがある場合、parentTenantId クエリパラメータを渡すことで、子テナントのリソースを1回の呼び出しでまとめて集計できます。
例
例: 一意のカウント


例: countDistinct(重複を除くカウント)

レスポンス:

例: 複数フィールドの合計

レスポンス:

例: 複数フィールドの平均

レスポンス:

例: 複数フィールドの最小/最大値

レスポンス:

例: 複数フィールドの一意の値のカウント

レスポンス:

例: クエリ作成の例

レスポンス:

例: レビュー保留中のコメント数をカウント

レスポンス:

例: 承認済み、レビュー済み、スパムのコメントの内訳

レスポンス:

構造


以下のリソースを集計できます:
- AffiliateEvent
- AnonymousVote
- BannedUser
- BatchJob
- BlockedUser
- Comment
- CommentDeleted
- CommentIdToSyncOutbound
- CommentScheduled
- CommentSyncLog
- CustomConfig
- CustomEmailTemplateRenderError
- EmailToSend
- EventLogEntry
- ImportedCommentScheduled
- ModerationGroup
- Moderator
- Page
- PageReact
- PendingVote
- QuestionResult
- SSOUser
- SentEmail
- SpamEvent
- Tenant
- TenantAuditLog
- TenantBadge
- TenantDailyUsage
- TenantInvoiceHistory
- TenantPackage
- User
- UserBadge
- UserBadgeProgress
- UserNotification
- UserSubscription
- UserUsage
- Vote
監査ログの構造 
AuditLog はこの機能にアクセスできるテナントの監査イベントを表すオブジェクトです。
AuditLog オブジェクトの構造は次のとおりです:

監査ログは不変です。手動で書き込むこともできません。FastComments.com のみが監査ログに書き込むタイミングを決定できます。ただし、この API を通じて読み取ることはできます。
監査ログ内のイベントは2年で期限切れになります。
GET /api/v1/audit-logs 
この API はページネーションを使用します。ページネーションは skip、before、after パラメータで行います。AuditLogs は 1000 件ずつのページで返され、when と id によって順序付けられます。
毎回 1000 件のログを取得するにはクレジット 10 が必要です。
デフォルトでは、最新の項目が先に来るリストが返されます。これにより、skip=0 からポーリングを開始し、最後に消費したレコードが見つかるまでページネーションできます。
あるいは、古い順でソートして、レコードがなくなるまでページネーションすることもできます。
ソートは order を ASC または DESC のいずれかに設定して行います。デフォルトは ASC です。
日付でのクエリは、ミリ秒単位のタイムスタンプとしての before と after で可能です。before と after は含まれません。



コメントの構造 
A Comment オブジェクトは、ユーザーが残したコメントを表します。
親コメントと子コメントの関係は parentId を通じて定義されます。
Comment オブジェクトの構造は次のとおりです:

これらのフィールドの一部は READONLY としてマークされています — これらは API によって返されますが、設定することはできません。
コメントテキストの構造
コメントは FastComments 仕様のマークダウンで記述されます。これはマークダウンに、画像用の従来の bbcode スタイルタグ([img]path[/img] のような)を追加したものです。
テキストは 2 つのフィールドに保存されます。ユーザーが入力したテキストは修正されず comment フィールドに保存されます。これがレンダリングされ、commentHTML フィールドに保存されます。
許可されている HTML タグは b, u, i, strike, pre, span, code, img, a, strong, ul, ol, li, and br です。
HTML は非常に限定されたサブセットなので、HTML をレンダリングすることを推奨します。レンダラーを作るのは比較的簡単です。例えば React Native や Flutter 用のライブラリがいくつかあります。
comment フィールドの正規化されていない値をレンダリングすることも選択できます。 例のパーサーはこちら。
この例のパーサーは HTML に合わせて調整し、HTML タグをプラットフォームでレンダリングするための期待される要素に変換することもできます。
タギング
ユーザーがコメント内でタグ付けされた場合、その情報は mentions と呼ばれるリストに保存されます。リスト内の各オブジェクトは次の構造を持ちます。
Run 
ハッシュタグ
ハッシュタグが使用され、正常に解析された場合、その情報は hashTags と呼ばれるリストに保存されます。リスト内の各オブジェクトは次の構造を持ちます。retain が設定されている場合、ハッシュタグはクエリ用にコメントの hashTags 配列に手動で追加することもできます。
Run 
GET /api/v1/comments 
この API はユーザーに表示するためのコメントを取得するために使用されます。例えば、承認されていないコメントやスパムコメントを自動的にフィルタリングします。
Pagination
ページネーションは、パフォーマンス要件やユースケースに応じて、次のいずれかの方法で行うことができます:
- Fastest: Precalculated Pagination:
- これは、当社の事前構築されたウィジェットやクライアントを使用する場合に FastComments が動作する方法です。
- 「次へ」をクリックすると単にページ数が増加します。
- これはキー・バリュー ストアから取得されるように考えることができます。
- この方法では、
pageパラメータを0から開始して定義し、ソート方向をdirectionとして指定します。 - ページサイズはカスタマイズルールで変更できます。
- Most Flexible: Flexible Pagination:
- この方法ではカスタムの
limitとskipパラメータを定義できます。pageを渡さないでください。 - ソートの
directionもサポートされています。 limitはskipを適用した後に返される合計数です。- 例:
page size = 100かつpage = 2の場合、skip = 200, limit = 100を設定します。
- 例:
- 子コメントもページネーションにカウントされます。
asTreeオプションを使うことでこれを回避できます。limitChildrenとskipChildrenにより子のページネーションが可能です。maxTreeDepthにより返されるスレッドの深さを制限できます。
- この方法ではカスタムの
Threads
Precalculated Paginationを使用する場合、コメントは page ごとにグループ化され、スレッド内のコメントは全体のページに影響します。- この方法では、クライアントは
parentIdに基づいてスレッドを判断できます。 - 例えば、あるページにトップレベルのコメントが1件とその返信が29件あり、API に
page=0を設定すると、トップレベルのコメント1件と29件の子コメントが返されます。 - Example image here illustrating multiple pages.
- この方法では、クライアントは
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を設定してください。
- これは
Trees Explained
asTree を使用するとページネーションの考え方が分かりにくくなることがあります。参考になる図はこちらです:
Fetching Comments in The Context of a User
/comments API は、異なるユースケースに対して 2 つのコンテキストで使用できます:
- 自身のクライアントを構築するための情報でソートおよびタグ付けされたコメントを返す場合。
- この場合は query パラメータに
contextUserIdを定義してください。
- この場合は query パラメータに
- カスタム統合のためにバックエンドからコメントを取得する場合。
contextUserIdを指定しない場合、プラットフォームはこれをデフォルトとします。




Get Comments as a Tree
コメントをツリーとして返すことが可能で、ページネーションはトップレベルのコメントのみをカウントします。

トップレベルのコメントとその直下の子のみを取得したいですか? こうする方法の一例を示します:

ただし、UI 上では各コメントに「返信を表示」ボタンを表示するかどうかを知る必要がある場合があります。ツリーとしてコメントを取得すると、該当する場合に hasChildren プロパティがコメントに付与されます。
Get Comments as a Tree, Searching by Hash Tag
API を使用してハッシュタグで検索することが可能で、テナント全体(1 ページや urlId に限定されません)を横断して検索できます。
この例では urlId を省略し、複数のハッシュタグで検索します。API は要求されたすべてのハッシュタグを持つコメントのみを返します。

All Request Params

The Response

Helpful Tips
URL ID
おそらく Comment API を urlId パラメータと一緒に使用したいでしょう。まず Pages API を呼び出して、利用可能な urlId の値がどのようになっているかを確認できます。
Anonymous Actions
匿名でコメントする場合、コメントの取得時やフラグ付け・ブロックを行う際に anonUserId を渡すことをお勧めします。
(!) これは多くのアプリストアで必須です。ユーザーはログインしていなくても、自分が見えるユーザー生成コンテンツを通報できる必要があります。これを行わないと、アプリが当該ストアから削除される可能性があります。
Comments Not Being Returned
コメントが承認されており、スパムではないことを確認してください。
GET /api/v1/comments/:id 
この API は、ID によって単一のコメントを取得する機能を提供します。



POST /api/v1/comments 
このAPIエンドポイントはコメントを作成する機能を提供します。
一般的な使用例はカスタムUI、統合、またはインポートです。
注意事項:
- このAPIは、必要に応じてコメントウィジェットを「ライブ」で更新できます(これにより
creditsCostが1から2に増加します)。 - メールアドレスが提供されると、このAPIはシステム内にユーザーオブジェクトを自動的に作成します。
- 異なるメールアドレスで同じユーザー名のコメントを2件保存しようとすると、2つ目のコメントでエラーになります。
parentIdを指定していて、子コメントのnotificationSentForParentが false の場合、親コメントに対して通知を送信します。これは毎時間行われます(送信されるメール数を減らすために通知をまとめて送信します)。- ユーザー作成時に歓迎メールを送信したり、コメント検証メールを送信したい場合は、クエリパラメータで
sendEmailsをtrueに設定してください。 - このAPIで作成されたコメントは、管理アプリの Analytics および Moderation ページに表示されます。
- 設定がオンになっている場合、コメント投稿者の名前やコメント本文の「悪い言葉」はマスクされます。
- このAPIで作成されたコメントは、必要に応じてスパムチェックを受けることができます。
- Customization Rule 管理ページで設定された最大コメント長などの設定は、ここにも適用されます。
コメントウィジェットに表示されるために送信するのに必要な最小データは、次のとおりです:

より現実的なリクエストは次のようになります:



PATCH /api/v1/comments/:id 
この API エンドポイントは単一のコメントを更新する機能を提供します。
Notes:
- 必要に応じて、この API はコメントウィジェットを「ライブ」で更新できます(これにより基本の
creditsCostが1から2に増加します)。- これにより、ページ間のコメント移行を「ライブ」で行うことができます(
urlIdの変更)。 - この移行はページが事前計算され CPU 負荷が高いため、追加で
2クレジットがかかります。
- これにより、ページ間のコメント移行を「ライブ」で行うことができます(
- 作成 API と異なり、この API はメールが提供されても当社システム内にユーザーオブジェクトを自動で作成しません。
- この API を介して更新されたコメントでも、必要に応じてスパムチェックが可能です。
- カスタマイズルール管理ページで設定された最大コメント長などの設定はここにも適用されます。
- ユーザーがコメント本文を更新できるようにするには、リクエストボディに
commentを指定するだけです。結果のcommentHTMLを生成します。commentとcommentHTMLの両方を定義した場合、HTML は自動生成されません。- ユーザーが新しいテキストにメンションやハッシュタグを追加した場合でも、
POSTAPI と同様に処理されます。
- コメントの
commenterEmailを更新する際は、userIdも指定するのが最善です。そうでない場合は、このメールアドレスのユーザーがあなたのテナントに属していることを確認する必要があります。そうでなければリクエストは失敗します。



DELETE /api/v1/comments/:id 
このAPIエンドポイントはコメントを削除するための機能を提供します。
Notes:
- このAPIは、必要に応じてコメントウィジェットを「ライブ」で更新できます(これにより
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 のユーザー、SSO ユーザー、またはテナントユーザーである可能性があります。
- コメントが自動的に承認取り消し(非表示)された後、そのコメントを再承認できるのは管理者またはモデレーターのみです。フラグ解除はコメントを再承認しません。

匿名でのフラグ付けの場合、anonUserId を指定する必要があります。これは匿名セッションを表す ID、またはランダムな 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 ボディパラメータをサポートします。
注意:
- この呼び出しは常にユーザーのコンテキストで行う必要があります。ユーザーは FastComments.com ユーザー、SSO ユーザー、またはテナントユーザーである可能性があります。
- リクエスト内の
userIdはブロック解除を行うユーザーです。例えば:User AがUser Bのブロックを解除したい場合、userId=User AとUser Bが書いたコメントのIDを渡します。 - ユーザーIDもメールアドレスもない完全に匿名のコメントはブロックできず、エラーが返されます。




メールテンプレートの構造 
An EmailTemplate object represents configuration for a custom email template, for a tenant.
The system will select the email template to use via:
- Its type identifier, we call this
emailTemplateId. These are constants. - The
domain. We will first try to find a template for the domain that the related object (like aComment) is tied to, and if a match is not found then we will try to find a template where domain is null or*.
The structure for the EmailTemplate object is as follows:

注意
- You can get the valid
emailTemplateIdvalues from the/definitionsendpoint. - The
/definitionsendpoint also includes the default translations and test data. - Templates will fail to save with invalid structure or test data.
GET /api/v1/email-templates/:id 
個々の EmailTemplate は対応する id(emailTemplateId ではありません)で取得できます。



GET /api/v1/email-templates 
このAPIはページネーションを使用しており、page クエリパラメータで指定します。EmailTemplates は 100 件ごとのページで返され、createdAt の後に id で並びます。



PATCH /api/v1/email-templates/:id 
このAPIエンドポイントは、idと更新する属性のみを指定することで、メールテンプレートを更新する機能を提供します。
テンプレート作成時と同じ検証が全て適用される点に注意してください。例えば:
- テンプレートはレンダー可能でなければなりません。これは各更新時に検査されます。
- 同一ドメインに対して重複したテンプレートを持つことはできません(そうすると片方が黙って無視されます)。



POST /api/v1/email-templates 
このAPIエンドポイントはメールテンプレートを作成する機能を提供します。
注意:
- 同じドメイン内で同じ
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 を削除します。



ハッシュタグの構造 
A HashTag オブジェクトはユーザーが残すことのできるタグを表します。ハッシュタグは外部のコンテンツへのリンクに使用したり、関連するコメントを結びつけるために使用できます。
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 クエリパラメータで指定します。ハッシュタグは tag によって並べ替えられ、1ページあたり 100 件で返されます。



PATCH /api/v1/hash-tags/:tag 
このルートは単一の HashTag を更新する機能を提供します。



POST /api/v1/hash-tags 
このルートは単一の HashTag を追加する機能を提供します。



POST /api/v1/hash-tags/bulk 
このルートは一度に最大100個のHashTagオブジェクトを追加する機能を提供します。



DELETE /api/v1/hash-tags/:tag 
このルートは、指定されたタグによって HashTag ユーザーを削除します。
自動的な HashTag 作成が無効になっていない限り、ユーザーがコメント時にハッシュタグを指定すると、ハッシュタグは再作成される可能性があることに注意してください。



モデレーターの構造 
A Moderator オブジェクトはモデレーターの設定を表します。
モデレーターには3つのタイプがあります:
isCommentModeratorAdminフラグを持つ管理者ユーザー。isCommentModeratorAdminフラグを持つSSOユーザー。- 招待された通常のコメント投稿者、またはFastComments.comのユーザー。
Moderator 構造はユースケース 3 のモデレーション状態を表すために使用されます。
ユーザーをモデレーターとしてAPI経由で招待したい場合は、Moderator APIを使用して Moderator を作成し、彼らを inviting してください。
ユーザーが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を持つモデレーターを2人追加することはできません。 Moderatorに関連付けられたtenantIdを変更することはできません。



POST /api/v1/moderators 
このルートは単一の Moderator を追加する機能を提供します。
Moderator を作成する際の制限は次の通りです:
nameとemailは常に提供する必要があります。userIdは任意です。- Moderator を作成する際、次の値は指定できません:
acceptedInvitemarkReviewedCountdeletedCountmarkedSpamCountapprovedCounteditedCountbannedCountverificationIdcreatedAt
userIdが指定されている場合、そのユーザーは存在していなければなりません。userIdが指定されている場合、そのユーザーはクエリパラメータで指定されたのと同じtenantIdに属している必要があります。- 同じテナント内で、同一の
emailを持つモデレーターを二人追加することはできません。
メールアドレスのみが分かっているユーザーのために Moderator を作成できます:

または、当社のテナントに所属するユーザーのモデレーション統計を追跡するために Moderator を作成することもできます:



POST /api/v1/moderators/:id/send-invite 
このルートは単一の Moderator を招待する機能を提供します。
招待メールを Moderator に送信するには次の制限があります:
Moderatorは既に存在している必要があります。fromNameは100 charactersを超えてはいけません。
注意:
- 指定したメールアドレスのユーザーが既に存在する場合、そのユーザーはテナントのコメントをモデレートするよう招待されます。
- 指定したメールアドレスのユーザーが 存在しない場合、招待リンクはアカウント作成の手順へ案内します。
- 招待は
30 days後に期限切れになります。
メールアドレスだけしか知らないユーザーのために Moderator を作成できます:

これにより Bob at TenantName is inviting you to be a moderator... のようなメールが送信されます。


DELETE /api/v1/moderators/:id 
このルートはIDによってModeratorを削除します。



通知数の構造 
NotificationCount オブジェクトはユーザーの未読通知数とメタデータを表します。
未読の通知がない場合、ユーザーに対する NotificationCount は存在しません。
NotificationCount オブジェクトは自動的に作成され、API経由で作成することはできません。これらは1年で期限切れになります。
ユーザーの未読通知数は、その NotificationCount を削除することでクリアできます。
NotificationCount オブジェクトの構造は次のとおりです:

GET /api/v1/notification-count/:user_id 
このルートはユーザーIDによる単一の NotificationCount を返します。SSO を使用している場合、ユーザーID は <tenant id>:<user id> の形式になります。
未読の通知がない場合、NotificationCount は存在しないため、404 が返されます。
notifications/count と異なり、本エンドポイントははるかに高速ですが、フィルタリングはできません。



DELETE /api/v1/notification-count/:user_id 
このルートはユーザーIDで単一の NotificationCount を削除します。SSO を使用する場合、ユーザーID は <tenant id>:<user id> の形式です。
これによりユーザーの未読通知数がクリアされます(コメントウィジェットの赤いベルが薄くなり、カウントが消えます)。



通知の構造 
Notificationオブジェクトはユーザーのための通知を表します。
Notificationオブジェクトは自動的に作成され、API経由で作成することはできません。これらはまた1年後に期限切れになります。
通知は削除できません。ただし、viewedをfalseに設定するよう更新することはでき、viewedでクエリすることができます。
ユーザーは、通知のoptedOutをtrueにすることで特定のコメントの通知をオプトアウトできます。再度受け取りたい場合はfalseに設定してください。
通知にはさまざまなタイプがあります — relatedObjectTypeとtypeを確認してください。
通知の作成方法は非常に柔軟で、多くのシナリオでトリガーされます(NotificationTypeを参照)。
現在、Notificationの存在がメールが送信される、または送信されるべきであることを意味するわけではありません。むしろ、通知は通知フィードおよび関連する統合で使用されます。
Notificationオブジェクトの構造は次のとおりです:

GET /api/v1/notifications 
このルートは createdAt でソートされた最大30件の Notification オブジェクトを返します。新しいものが先に来ます。
userId でフィルタできます。SSO を使用する場合、ユーザーIDは <tenant id>:<user id> の形式です。



GET /api/v1/notifications/count 
このルートは、count パラメータの下に通知の数を含むオブジェクトを返します。
これは /notification-count/ より遅く、クレジットの消費は2倍ですが、より多くの次元でフィルタリングできます。
/notifications エンドポイントと同じパラメータ(例:userId)でフィルタリングできます。SSO を使用している場合、ユーザーID は <tenant id>:<user id> の形式になります。




PATCH /api/v1/notifications/:id 
この API エンドポイントは id によって Notification を更新する機能を提供します。
Notification の更新には次の制限があります:
- 次のフィールドのみ更新できます:
viewedoptedOut



ページの構造 
A Page object represents the page that many comments may belong to. This relationship is defined by
urlId.
A Page stores information such as the page title, comment count, and urlId.
The structure for the Page object is as follows:

GET /api/v1/pages 
現在、アカウントに関連付けられたページをすべて取得するか(または /by-url-id 経由で単一のページを取得する)ことのみ可能です。より細かい検索を希望する場合は、お問い合わせください。



役立つヒント
Comment API では urlId が必要です。まず Pages API を呼び出して、利用可能な urlId の値がどのようなものかを確認できます。
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エンドポイントはページを作成する機能を提供します。
一般的なユースケースはアクセス制御です。
注意事項:
- もしあなたがコメントスレッドにコメントしたり、
Commentを作成するためにAPIを呼び出した場合、既にPageオブジェクトが作成されています!同じurlIdをコメントウィジェットに渡したものを使って、/by-url-idのPageルートから取得してみてください。 Page構造にはいくつかの計算された値が含まれます。 現在はcommentCountとrootCommentCountです。 これらは自動で設定され、APIから設定することはできません。設定しようとするとAPIはエラーを返します。



DELETE /api/v1/pages/:id 
このルートは、idで指定された単一のページの削除を行います。
同じ urlId を持つページのコメントウィジェットに対して操作すると、その Page は単にシームレスに再作成されることに注意してください。



保留中のWebhookイベントの構造 
A PendingWebhookEvent object represents a queued webhook event that is pending.
PendingWebhookEvent オブジェクトは自動的に作成され、API 経由で手動作成することはできません。これらはまた 1 年後に期限切れになります。
それらは削除可能で、削除するとキューからタスクが取り除かれます。
異なるイベントタイプがあります — eventType(OutboundSyncEventType)と type(OutboundSyncType)を確認してください。
この API の一般的なユースケースはカスタム監視を実装することです。指定したフィルターに対する未処理数をポーリングするために、/count エンドポイントを定期的に呼び出すことがあるでしょう。
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 
このルートは、保留中の webhook イベントの数を count パラメータとして含むオブジェクトを返します。
/pending-webhook-events エンドポイントと同じパラメータでフィルタできます



DELETE /api/v1/pending-webhook-events/:id 
このルートでは単一の PendingWebhookEvent を削除できます。
一括削除が必要な場合は、ページネーション付きのGET APIを呼び出してから、このAPIを順番に呼び出してください。



SSOユーザーの構造 
FastComments は使いやすい SSO ソリューションを提供します。HMAC ベースの統合を使用したユーザー情報の更新は、ユーザーが更新されたペイロードでページを読み込むだけで簡単に行えます。
ただし、アプリケーションの整合性を高めるために、そのフロー外でユーザーを管理したい場合もあります。
SSO User API は、SSOUsers と呼ぶオブジェクトを 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 
このルートは SSO ユーザーを 100 件ずつのページで返します。ページネーションは skip パラメータで提供されます。ユーザーは signUpDate と id によってソートされます。



GET /api/v1/sso-users/by-id/:id 
このルートは、IDによって単一のSSOユーザーを返します。



GET /api/v1/sso-users/by-email/:email 
このルートはメールアドレスによって単一の SSO ユーザーを返します。



PATCH /api/v1/sso-users/:id 
このルートは単一の SSO ユーザーを更新する機能を提供します。



POST /api/v1/sso-users 
このルートは単一のSSOユーザーを作成します。
同じIDでユーザーを2つ作成しようとするとエラーになります。

この例ではアクセス制御のために groupIds を指定していますが、これはオプションです。


統合に関する注意
APIによって渡されたデータは、別のSSOユーザHMACペイロードを渡すだけで簡単に上書きできます。例えば、APIでusernameを設定した場合でも、ページ読み込み時のSSOフローで別のusernameを渡すと、自動的にそのusernameが更新されます。
このフローでは、明示的に指定するか null(not undefined)に設定した場合を除き、ユーザーのパラメータは更新しません。
PUT /api/v1/sso-users/:id 
このルートは単一のSSOユーザーを更新する機能を提供します。

この例ではアクセス制御のために groupIds を指定していますが、これは任意です。


DELETE /api/v1/sso-users/:id 
このルートは、IDによって単一のSSOユーザーを削除します。
このユーザーのペイロードでコメントウィジェットを再度読み込むと、そのユーザーはシームレスに再作成されることに注意してください。
ユーザーのコメントは deleteComments クエリパラメータで削除できます。これが true の場合、次のことに注意してください:
- ユーザーのすべてのコメントが即時に削除されます。
- すべての child(現在孤立した)コメントは、各コメントに紐づくページの設定に基づいて削除または匿名化されます。たとえば、スレッド削除モードが "anonymize" の場合は返信は残り、ユーザーのコメントは匿名化されます。これは
commentDeleteModeがRemove(デフォルト値)の場合にのみ適用されます。 creditsCostは2になります。
匿名化されたコメント
ユーザーのコメントを保持したまま匿名化するには、commentDeleteMode=1 に設定します。
ユーザーのコメントが匿名化されると、次の値が null に設定されます:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badgesisDeleted と isDeletedUser は true に設定されます。
レンダリング時、コメントウィジェットはユーザー名に DELETED_USER_PLACEHOLDER(デフォルト: "[deleted]")を、コメントには DELETED_CONTENT_PLACEHOLDER を使用します。これらはウィジェットカスタマイズUIから変更できます。
例



サブスクリプションの構造 
A Subscription object represents a subscription for a user.
Subscription objects are created when a user clicks the notification bell in the comment widget and clicks "Subscribe to this page".
Subscriptions can also be created via the 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. Sending of emails depends on the type of user. For regular users this depends on optedInNotifications. For SSO Users this depends on optedInSubscriptionNotifications. Note that some applications may not have the concept of a web-accessible page, in which case simply set urlId to
the id of the item you are subscribing to (same value for urlId you would pass to the comment widget).
A Subscription オブジェクトはユーザーの購読を表します。
Subscription オブジェクトは、ユーザーがコメントウィジェットの通知ベルをクリックし、"このページを購読する" をクリックしたときに作成されます。
購読はAPI経由でも作成できます。
Subscription オブジェクトが存在すると、該当するページのルートに新しいコメントが投稿された際に Notification オブジェクトが生成され、メールが送信されます。メールの送信はユーザーの種類に依存します。通常のユーザーの場合は optedInNotifications に依存します。SSOユーザーの場合は optedInSubscriptionNotifications に依存します。ウェブでアクセス可能なページという概念がないアプリケーションもある点に注意してください。その場合は、購読対象のアイテムの id(コメントウィジェットに渡す urlId と同じ値)を urlId に設定してください。
The structure for the Subscription object is as follows:

GET /api/v1/subscriptions/:id 
このルートは createdAt でソートされた最大30件の Subscription オブジェクトを返します(新しい順)。
userId でフィルターできます。SSO を使用している場合、ユーザーIDは <tenant id>:<user id> の形式です。



POST /api/v1/subscriptions 
このAPIエンドポイントは Subscription を作成する機能を提供します。ユーザーはページごとに1つのサブスクリプションのみ持つことができ、複数は冗長であるため、同じユーザーが同じページに対して複数のサブスクリプションを作成しようとするとエラーになります。
サブスクリプションを作成すると、購読中の urlId のルート(コメントの parentId が null の場合)に新しいコメントが投稿されると Notification オブジェクトが作成されます。



DELETE /api/v1/subscriptions/:id 
このルートはIDによって単一の Subscription オブジェクトを削除します。



テナント日次使用量の構造 
TenantDailyUsage オブジェクトは、特定の日におけるテナントの使用量を表します。特定のテナントにその日にアクティビティがなかった場合、その日には TenantDailyUsage オブジェクトは存在しません。
TenantDailyUsage オブジェクトは リアルタイムではありません。実際の使用状況より数分遅れることがあります。
TenantDailyUsage オブジェクトの構造は次のとおりです:

GET /api/v1/tenant-daily-usage 
このルートでは、年・月・日ごとにテナントの使用状況を検索できます。最大365件のオブジェクトが返され、コストは10件ごとに1 APIクレジットです。
レスポンスオブジェクトは作成日の順(古いものが先)でソートされます。



テナントの構造 
Tenant は FastComments.com の顧客を定義します。ホワイトラベリング権限を持つテナントは API を介してそれらを作成できます。ホワイトラベル化テナントは他のホワイトラベル化テナントを作成できません(ネストは1レベルのみ許可されます)。
Tenant オブジェクトの構造は次の通りです:

GET /api/v1/tenants/:id 
このルートは id によって単一の Tenant を返します。



GET /api/v1/tenants 
このAPIは、あなたのテナントによって管理されているテナントを返します。
ページネーションは skip クエリパラメータで提供されます。テナントは 100 件ずつのページで返され、signUpDate と id の順で並びます。
コストは返されるテナントの数に基づき、返される10件ごとに 1 credit per 10 がかかります。

Tenant オブジェクトに meta パラメータを定義して一致するテナントをクエリできます。例えば、キーが someKey でメタ値が some-value の場合、このキー/値ペアを含むJSONオブジェクトを作成し、それをURIエンコードしてクエリパラメータとして渡してフィルタリングできます:



POST /api/v1/tenants 
このルートは単一の Tenant を追加する機能を提供します。
Tenant を作成する際の制約は以下の通りです:
nameは必須です。domainConfigurationは必須です。Tenantを作成する際に以下の値を指定してはいけません:hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmount
signUpDateは未来の日付にできません。nameは200 charactersを超えてはいけません。emailは300 charactersを超えてはいけません。emailは FastComments.com の全テナントで一意でなければなりません。- 親テナントに有効な
TenantPackageが定義されていない場合、テナントを作成できません。- もしあなたのテナントが FastComments.com 経由で作成されているなら、この問題は発生しないはずです。
- パッケージで定義されている
maxWhiteLabeledTenantsより多くのテナントを作成することはできません。 - white labeling が有効な
parent tenantの ID であるtenantIdクエリパラメータを指定する必要があります。
少数のパラメータのみで Tenant を作成できます:



PATCH /api/v1/tenants/:id 
このAPIエンドポイントは id によって Tenant を更新する機能を提供します。
Tenant の更新には以下の制限があります:
- 次の値は更新できません:
hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmountmanagedByTenantId
signUpDateは未来日には設定できません。nameは200 charactersを超えてはいけません。emailは300 charactersを超えてはいけません。emailは FastComments.com のすべてのテナント間で一意でなければなりません。billingInfoValidをtrueに設定する場合、同じリクエスト内でbillingInfoを提供する必要があります。- 自身のテナントに紐付いた
packageIdを更新することはできません。 - 自身のテナントに紐付いた
paymentFrequencyを更新することはできません。



DELETE /api/v1/tenants/:id 
このルートはIDによって Tenant およびすべての関連データ(ユーザー、コメントなど)を削除します。
テナント削除に関して次の制限があります:
- テナントはあなた自身のものであるか、あなたが管理するホワイトラベルされたテナントである必要があります。
sureクエリパラメータはtrueに設定されている必要があります。



テナントパッケージの構造 
TenantPackage は、Tenant が利用できるパッケージ情報を定義します。テナントは複数のパッケージを利用可能にすることができますが、特定の時点で使用できるのは一つだけです。
packageId が有効な TenantPackage を指していない限り、Tenant はいかなる製品にも使用できません。
TenantPackage オブジェクトには次の2種類があります:
- 固定価格のパッケージ -
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 の数に基づき、10 件ごとに 1 credit がかかります。



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を削除します。
テナントの packageId がそのパッケージを指しているような、使用中の TenantPackage は削除できません。先に 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 credit per 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 で期限切れになります。
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 を使用します。これらはウィジェットカスタマイズ UI でカスタマイズ可能です。
例



ユーザーの構造 
User はすべてのユーザーの最も一般的な共通要素を表すオブジェクトです。
Keep in mind that at FastComments we have a bunch of different use cases for users:
- Secure SSO
- Simple SSO
- Tenant Users (For example: Administrators)
- 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 object represents a vote left by a user.
コメントと投票の関係は commentId によって定義されます。
Vote オブジェクトの構造は次のとおりです:

GET /api/v1/votes 
投票は urlId によって取得する必要があります。
投票の種類
投票には3種類あります。
- 認証済み投票は対応するコメントに適用されます。これらはこのAPIを通じて作成できます。
- 検証が保留中の認証済み投票であり、そのためまだコメントに適用されていません。これはユーザーが FastComments.com の ログインして投票 機能を使用したときに作成されます。
- 匿名投票は対応するコメントに適用されます。これらは匿名コメントとともに作成されます。
これらは混乱を避けるためにAPIでは別々のリストで返されます。



匿名投票の注意点
このAPIを通じて作成された匿名投票は appliedAuthorizedVotes リストに表示されることに注意してください。これらはAPIで API key を使って作成されたため、承認済みと見なされます。
appliedAnonymousVotes は、メールや API key などがない状態で作成された投票用の構造です。
GET /api/v1/votes/for-user 
指定した urlId に対してユーザーが行った投票を取得できます。userId は FastComments.com のユーザーまたは SSO User を指定できます。
コメントに対してユーザーが投票したかどうかを表示したい場合に便利です。コメントを取得する際、単にユーザーのために同時にこの API を呼び出し、
同じ urlId を使用してください。
匿名投票を使用している場合は、代わりに anonUserId を渡してください。


匿名の投票は appliedAuthorizedVotes リストに表示されます。API キーを使用して API 経由で作成されたため、承認済みとして扱われます。


POST /api/v1/votes 
このルートは、単一の認可された Vote を追加する機能を提供します。投票は up (+1) または down (-1) にできます。




匿名投票の作成
匿名投票は、クエリパラメータで userId の代わりに anonUserId を設定することで作成できます。
このIDはどこかのユーザーオブジェクトに対応している必要はありません(したがって匿名です)。これは単にセッションの識別子であり、同じセッション内で再度投票を取得して、コメントが投票されているかを確認できます。
もし FastComments のような「匿名セッション」がない場合は、単純にランダムなID(UUIDなど)を設定できます(ただし、スペース節約のために短い識別子の方が好ましいです)。
その他の注意点
- このAPIはテナントレベルの設定に従います。例えば、特定のページで投票を無効にしている場合、API経由で投票を作成しようとすると、エラーコード
voting-disabledで失敗します。 - このAPIはデフォルトでライブです。
- このAPIは対応する
Commentのvotesを更新します。
DELETE /api/v1/votes/:id 
このルートは単一の Vote を削除する機能を提供します。



注意事項:
- この API はテナントレベルの設定に従います。たとえば、特定のページで投票を無効にしていて、API 経由で投票を作成しようとすると、エラーコード
voting-disabledで失敗します。 - この API はデフォルトでライブです。
- この API は対応する
Commentのvotesを更新します。
ドメイン設定の構造 
A DomainConfig object represents configuration for a domain for a tenant.
The structure for the DomainConfig object is as follows:


認証について
ドメイン構成は、どのサイトがあなたのアカウントのFastCommentsウィジェットをホストできるかを決定するために使用されます。これは基本的な形態 の認証であり、ドメイン構成の追加または削除はあなたのFastCommentsインストールの可用性に影響を与える可能性があります 本番環境で。
Don't remove or update the domain property of a Domain Config for a domain that is currently in use unless disabling that domain is intended.
This has the same behavior as removing a domain from /auth/my-account/configure-domains.
Also note that removing a domain from the My Domains UI will remove any corresponding configuration for that domain that may have been added via this UI.
メールのカスタマイズについて
The unsubscribe link in the email footer, and the one-click-unsubscribe feature offered by many email clients, can be configured via this API by defining footerUnsubscribeURL and emailHeaders, respectively.
DKIMについて
After defining your DKIM DNS records, simply update the DomainConfig with your DKIM configuration using the defined structure.
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 
ここでは結果の集計が行われます。
集計のレスポンス構造は以下の通りです:

集計で利用できるクエリパラメータは以下の通りです:

リクエストの例:

レスポンス例:


パフォーマンスに関する注意
- キャッシュミスの場合、集計は通常100万件の結果あたり約5秒かかります。
- それ以外では、リクエストは定数時間で処理されます。
キャッシュとコストに関する注意
forceRecalculateが指定されている場合、通常の2の代わりにコストは常に10になります。- キャッシュが期限切れになりデータが再計算されても、
forceRecalculateが指定されていなければコストは依然として定数の2です。キャッシュの有効期限は集計されるデータセットのサイズに応じて決まり(30秒〜5分の間で変動します)。 - これはキャッシュの利用を促すための仕組みです。
GET /api/v1/question-results-aggregate/combine/comments 
これは結果とコメントを結合するエンドポイントです。たとえば、製品の「最近の肯定的および否定的なコメント」チャートを作成するのに便利です。
値の範囲(両端含む)、1つ以上の質問、開始日(含む)で検索できます。
レスポンス構造は次のとおりです:

集計で使用できるクエリパラメータは次のとおりです:

リクエストの例はこちら:

レスポンスの例:


キャッシュとコストに関する注意事項
forceRecalculateが指定されている場合、通常の2ではなくコストは常に10になります。- キャッシュが期限切れになりデータが再計算される場合でも、
forceRecalculateが指定されていなければコストは依然として一定の2です。 - これはキャッシュの利用を奨励するためです。
ユーザーバッジの構造 
UserBadge は FastComments システムでユーザーに付与されるバッジを表すオブジェクトです。
バッジは、ユーザーのアクティビティ(コメント数、返信時間、ベテランステータスなど)に基づいて自動的に付与されるか、サイト管理者によって手動で付与されます。
The structure for the UserBadge object is as follows:

GET /api/v1/user-badges 
このエンドポイントでは、さまざまな条件でユーザーバッジを取得できます。
Example Request:
Run 
結果を絞り込むために、さまざまなクエリパラメータを追加できます:
userId- 特定のユーザーのバッジを取得badgeId- 特定のバッジのインスタンスを取得type- バッジのタイプでフィルタ (0=CommentCount, 1=CommentUpVotes, 2=CommentReplies, など。完全な一覧は UserBadge 構造を参照してください)displayedOnComments- バッジがコメントに表示されるかどうかでフィルタ (true/false)limit- 返されるバッジの最大数 (デフォルト 30、最大 200)skip- スキップするバッジ数(ページネーション用)
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:
- バッジはテナントのバッジカタログに存在し、有効になっている必要があります
- バッジは、あなたのテナントに所属しているユーザー、またはあなたのサイトにコメントしたことのあるユーザーにのみ割り当てることができます
Example Response:

Possible Error Responses:





PUT /api/v1/user-badges/:id 
このエンドポイントでは、ユーザーバッジの割り当てを更新できます。
現在、更新可能なプロパティは displayedOnComments のみで、これはバッジがユーザーのコメントに表示されるかどうかを制御します。
リクエスト例:
Run 
レスポンス例:

考えられるエラー応答:



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ドキュメントが網羅的で分かりやすいと感じていただけていれば幸いです。もし不足点を見つけた場合は、下にお知らせください。