
Langue 🇨🇦 Français (Canada)
Ressources de l'API
Agrégations
Journaux d'audit
Commentaires
Modèles de courriel
Mots-clics
Modérateurs
Compteur de notifications
Notifications
Pages
Événements webhook en attente
Utilisateurs SSO
Abonnements
Utilisation quotidienne du locataire
Locataires
Forfaits du locataire
Utilisateurs du locataire
Utilisateurs
Votes
Configurations de domaine
Configurations des questions
Résultats des questions
Agrégation des résultats des questions
Badges utilisateur
Progression du badge utilisateur
L'API FastComments
FastComments fournit une API pour interagir avec de nombreuses ressources. Créez des intégrations avec notre plateforme, ou même créez vos propres clients!
Dans cette documentation, vous trouverez toutes les ressources prises en charge par l'API documentées avec leurs types de requête et de réponse.
Pour les clients Enterprise, tout l'accès à l'API est enregistré dans le journal d'audit.
SDKs générés
FastComments génère maintenant une Spécification d'API à partir de notre code (ceci n'est pas encore complet, mais inclut de nombreuses API).
Nous disposons également maintenant de SDKs pour des langages populaires :
- fastcomments-cpp
- fastcomments-go
- fastcomments-java
- fastcomments-sdk-js
- fastcomments-nim
- fastcomments-php
- fastcomments-php-sso
- fastcomments-python
- fastcomments-ruby
- fastcomments-rust
- fastcomments-swift
Authentification
L'API s'authentifie en passant votre clé API soit comme en-tête X-API-KEY, soit comme paramètre de requête API_KEY. Vous aurez également besoin de votre tenantId
pour effectuer des appels API. Celui-ci peut être récupéré depuis la même page que votre clé API.
Remarque de sécurité
Ces routes doivent être appelées depuis un serveur. NE PAS les appeler depuis un navigateur. Le faire exposera votre clé API — cela donnera un accès complet à votre compte à toute personne pouvant consulter le code source d'une page!
Option d'authentification 1 - En-têtes
- En-tête :
X-API-KEY - En-tête :
X-TENANT-ID
Option d'authentification 2 - Paramètres de requête
- Paramètre de requête :
API_KEY - Paramètre de requête :
tenantId
Ressources de l'API 
Utilisation des ressources
Il convient de noter que la récupération de données depuis l'API est comptabilisée comme utilisation sur votre compte.
Chaque ressource indiquera quelle est cette utilisation dans sa propre section.
Certaines ressources coûtent plus cher à servir que d'autres. Chaque endpoint a un coût fixe de crédits par appel API. Pour certains endpoints, le nombre de crédits varie en fonction des options et des tailles de réponse.
L'utilisation de l'API peut être vérifiée sur la page Analytique de Facturation et est mise à jour toutes les quelques minutes.
Note !
Nous suggérons de lire d'abord la documentation des Pages, pour aider à limiter la confusion lors de la détermination des valeurs à passer pour urlId dans l'API Comment.
Agrégez vos données 
Cette API agrège des documents en les regroupant (si groupBy est fourni) et en appliquant plusieurs opérations. Différentes opérations (par ex. sum, countDistinct, avg, etc.) sont supportées.
Le coût est variable. Chaque 500 objets analysés coûte 1 crédit API.
L'utilisation maximale de mémoire autorisée par appel API par défaut est de 64 Mo, et par défaut vous ne pouvez avoir qu'une agrégation en cours à la fois. Si vous soumettez plusieurs agrégations simultanément, elles seront mises en file d'attente et exécutées dans l'ordre de soumission. Les agrégations en attente attendront un maximum de 60 secondes, après quoi la requête expirera. Les agrégations individuelles peuvent s'exécuter jusqu'à 5 minutes.
Si vous avez des locataires gérés, vous pouvez agréger toutes les ressources des locataires enfants en un seul appel en passant le paramètre de requête parentTenantId.
Exemples
Exemple : Compter les valeurs uniques


Exemple : Compter les valeurs distinctes

Réponse :

Exemple : Somme des valeurs de plusieurs champs

Réponse :

Exemple : Moyenne des valeurs de plusieurs champs

Réponse :

Exemple : Valeurs Min/Max de plusieurs champs

Réponse :

Exemple : Compter les valeurs uniques de plusieurs champs

Réponse :

Exemple : Création de requête

Réponse :

Exemple : Compter les commentaires en attente de révision

Réponse :

Exemple : Répartition des commentaires approuvés, révisés et spam

Réponse :

Structures


Les ressources suivantes peuvent être agrégées :
- 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
Structure du journal d'audit 
Un AuditLog est un objet qui représente un événement audité pour les locataires qui ont accès à cette fonctionnalité.
La structure de l'objet AuditLog est la suivante :

Le journal d'audit est immuable. Il ne peut pas non plus être écrit manuellement. FastComments.com est le seul à décider quand écrire dans le journal d'audit. Cependant, vous pouvez le lire via cette API.
Les événements dans le journal d'audit expirent après deux ans.
GET /api/v1/audit-logs 
Cette API utilise la pagination, fournie par les paramètres skip, before et after. Les AuditLogs sont retournés par pages de 1000, triés par when et id.
La récupération de chaque 1000 logs a un coût en crédits de 10.
Par défaut, vous recevrez une liste avec les éléments les plus récents en premier. De cette façon, vous pouvez interroger en commençant par skip=0, en paginant jusqu'à trouver le dernier enregistrement que vous avez consommé.
Alternativement, vous pouvez trier du plus ancien au plus récent, et paginer jusqu'à ce qu'il n'y ait plus d'enregistrements.
Le tri peut être effectué en définissant order sur ASC ou DESC. La valeur par défaut est ASC.
L'interrogation par date est possible via before et after en tant que timestamps avec millisecondes. before et after ne sont PAS inclusifs.



Structure du commentaire 
Un objet Comment représente un commentaire laissé par un utilisateur.
La relation entre les commentaires parents et enfants est définie via parentId.
La structure de l'objet Comment est la suivante :

Certains de ces champs sont marqués READONLY - ils sont retournés par l'API mais ne peuvent pas être définis.
Structure du texte de commentaire
Les commentaires sont écrits dans une version FastComments de markdown, qui est simplement markdown plus des balises de style bbcode traditionnelles pour les images, comme [img]path[/img].
Le texte est stocké dans deux champs. Le texte entré par l'utilisateur est stocké non modifié dans le champ comment. Il est rendu et stocké dans le champ commentHTML.
Les balises HTML autorisées sont b, u, i, strike, pre, span, code, img, a, strong, ul, ol, li, et br.
Il est recommandé de rendre le HTML, car c'est un sous-ensemble très petit de HTML, construire un moteur de rendu est assez simple. Il existe plusieurs bibliothèques pour React Native et Flutter, par exemple, pour aider avec cela.
Vous pouvez choisir de rendre la valeur non normalisée du champ comment. Un exemple d'analyseur est ici..
L'exemple d'analyseur pourrait également être ajusté pour fonctionner avec HTML, et transformer les balises HTML en éléments attendus à rendre pour votre plateforme.
Marquage
Lorsque des utilisateurs sont tagués dans un commentaire, l'information est stockée dans une liste appelée mentions. Chaque objet dans cette liste
a la structure suivante.
Run 
HashTags
Lorsque des hashtags sont utilisés et analysés avec succès, l'information est stockée dans une liste appelée hashTags. Chaque objet dans cette liste
a la structure suivante. Les hashtags peuvent également être ajoutés manuellement au tableau hashTags du commentaire pour la requête, si retain est défini.
Run 
GET /api/v1/comments 
Cette API est utilisée pour obtenir des commentaires à afficher à un utilisateur. Par exemple, elle filtre automatiquement les commentaires non approuvés ou spam.
Pagination
La pagination peut être effectuée de deux manières, selon les exigences de performance et le cas d'utilisation :
- Le plus rapide : Pagination Précalculée :
- C'est ainsi que FastComments fonctionne lorsque vous utilisez nos widgets et clients préconçus.
- Cliquer sur "suivant" augmente simplement le nombre de pages.
- Vous pouvez penser à cela comme étant récupéré par un magasin clé-valeur.
- De cette façon, définissez simplement un paramètre
pagecommençant à0et une direction de tri commedirection. - Les tailles de page peuvent être personnalisées via les règles de personnalisation.
- Le plus flexible : Pagination Flexible :
- De cette façon, vous pouvez définir des paramètres
limitetskippersonnalisés. Ne passez paspage. - La
directionde tri est également supportée. limitest le total à retourner après queskipsoit appliqué.- Exemple : définir
skip = 200, limit = 100quandtaille de page = 100etpage = 2.
- Exemple : définir
- Les commentaires enfants comptent toujours dans la pagination. Vous pouvez contourner cela en utilisant l'option
asTree.- Vous pouvez paginer les enfants via
limitChildrenetskipChildren. - Vous pouvez limiter la profondeur des fils retournés via
maxTreeDepth.
- Vous pouvez paginer les enfants via
- De cette façon, vous pouvez définir des paramètres
Fils de discussion
- Lors de l'utilisation de la
Pagination Précalculée, les commentaires sont regroupés par page et les commentaires dans les fils affectent la page globale.- De cette façon, les fils peuvent être déterminés côté client basé sur
parentId. - Par exemple, avec une page avec un commentaire de premier niveau, et 29 réponses, et en définissant
page=0dans l'API - vous obtiendrez juste le commentaire de premier niveau et les 29 enfants. - Image d'exemple ici illustrant plusieurs pages.
- De cette façon, les fils peuvent être déterminés côté client basé sur
- Lors de l'utilisation de la
Pagination Flexible, vous pouvez définir un paramètreparentId.- Définissez-le à null pour obtenir uniquement les commentaires de premier niveau.
- Ensuite pour voir les fils, appelez à nouveau l'API et passez
parentId. - Une solution commune est de faire un appel API pour les commentaires de premier niveau puis de faire des appels API parallèles pour obtenir les commentaires pour les enfants de chaque commentaire.
- NOUVEAU Depuis Fév 2023! Récupérer sous forme d'arbre en utilisant
&asTree=true.- Vous pouvez penser à cela comme
Pagination Flexible sous forme d'Arbre. - Seuls les commentaires de premier niveau comptent dans la pagination.
- Définissez
parentId=nullpour démarrer l'arbre à la racine (vous devez définirparentId). - Définissez
skipetlimitpour la pagination. - Définissez
asTreeàtrue. - Le coût en crédits augmente de
2x, car notre backend doit faire beaucoup plus de travail dans ce scénario. - Définissez
maxTreeDepth,limitChildren, etskipChildrenselon vos besoins.
- Vous pouvez penser à cela comme
Les Arbres Expliqués
Lors de l'utilisation de asTree, il peut être difficile de raisonner sur la pagination. Voici un graphique pratique :
Récupérer des Commentaires dans le Contexte d'un Utilisateur
L'API /comments peut être utilisée dans deux contextes, pour différents cas d'utilisation :
- Pour retourner des commentaires triés et tagués avec des informations pour construire votre propre client.
- Dans ce cas, définissez un paramètre de requête
contextUserId.
- Dans ce cas, définissez un paramètre de requête
- Pour récupérer des commentaires depuis votre backend pour des intégrations personnalisées.
- La plateforme utilisera par défaut ceci sans
contextUserId.
- La plateforme utilisera par défaut ceci sans




Obtenir des Commentaires sous forme d'Arbre
Il est possible d'obtenir les commentaires retournés sous forme d'arbre, avec la pagination ne comptant que les commentaires de premier niveau.

Vous voulez obtenir uniquement les commentaires de premier niveau et les enfants immédiats ? Voici une façon :

Cependant, dans votre interface vous pourriez avoir besoin de savoir s'il faut afficher un bouton "afficher les réponses" sur
chaque commentaire. Lors de la récupération des commentaires via un arbre, il y a une propriété hasChildren taguée
sur les commentaires lorsque applicable.
Obtenir des Commentaires sous forme d'Arbre, en Recherchant par Hash Tag
Il est possible de rechercher par hashtag en utilisant l'API, à travers tout votre locataire (pas limité à une page, ou urlId).
Dans cet exemple, nous omettons urlId, et nous recherchons par plusieurs hashtags. L'API ne retournera que les commentaires qui ont tous les hashtags demandés.

Tous les Paramètres de Requête

La Réponse

Conseils Utiles
URL ID
Vous voudrez probablement utiliser l'API Comment avec le paramètre urlId. Vous pouvez appeler l'API Pages d'abord, pour voir à quoi ressemblent les valeurs urlId disponibles pour vous.
Actions Anonymes
Pour les commentaires anonymes, vous voudrez probablement passer anonUserId lors de la récupération des commentaires, et lors du signalement et du blocage.
(!) Ceci est requis pour de nombreux magasins d'applications car les utilisateurs doivent pouvoir signaler le contenu créé par les utilisateurs qu'ils peuvent voir, même s'ils ne sont pas connectés. Ne pas le faire peut causer le retrait de votre application dudit magasin.
Commentaires Non Retournés
Vérifiez que vos commentaires sont approuvés, et ne sont pas spam.
GET /api/v1/comments/:id 
Cette API fournit la capacité de récupérer un commentaire unique par id.



POST /api/v1/comments 
Ce endpoint API fournit la capacité de créer des commentaires.
Les cas d'utilisation courants sont les interfaces personnalisées, les intégrations ou les importations.
Notes :
- Cette API peut mettre à jour le widget de commentaires "en direct" si désiré (cela augmente le
creditsCostde1à2). - Cette API créera automatiquement des objets utilisateur dans notre système si un email est fourni.
- Essayer d'enregistrer deux commentaires avec des emails différents, mais le même nom d'utilisateur, entraînera une erreur pour le deuxième commentaire.
- Si vous spécifiez
parentId, et qu'un commentaire enfant anotificationSentForParentà false, nous enverrons des notifications pour le commentaire parent. Cela se fait toutes les heures (nous regroupons les notifications pour diminuer le nombre d'emails envoyés). - Si vous voulez envoyer des emails de bienvenue lors de la création d'utilisateurs, ou des emails de vérification de commentaires, définissez
sendEmailsàtruedans les paramètres de requête. - Les commentaires créés via cette API apparaîtront dans les pages Analytique et Modération de l'application admin.
- Les "mauvais mots" sont toujours masqués dans les noms des commentateurs et le texte des commentaires si le paramètre est activé.
- Les commentaires créés via cette API peuvent toujours être vérifiés pour le spam si désiré.
- Les configurations telles que la longueur maximale des commentaires, si configurées via la page d'administration des règles de personnalisation, s'appliqueront ici.
Les données minimales requises pour soumettre qui s'afficheront dans le widget de commentaires sont les suivantes :

Une requête plus réaliste pourrait ressembler à :



PATCH /api/v1/comments/:id 
Ce endpoint API fournit la capacité de mettre à jour un commentaire unique.
Notes :
- Cette API peut mettre à jour le widget de commentaires "en direct" si désiré (cela augmente le
creditsCostde base de1à2).- Cela peut rendre la migration des commentaires entre les pages "en direct" (changement de
urlId). - Les migrations coûtent
2crédits supplémentaires car les pages sont précalculées et cela est intensif en CPU.
- Cela peut rendre la migration des commentaires entre les pages "en direct" (changement de
- Contrairement à l'API de création, cette API ne créera PAS automatiquement des objets utilisateur dans notre système si un email est fourni.
- Les commentaires mis à jour via cette API peuvent toujours être vérifiés pour le spam si désiré.
- Les configurations telles que la longueur maximale des commentaires, si configurées via la page d'administration des règles de personnalisation, s'appliqueront ici.
- Pour permettre aux utilisateurs de mettre à jour leur texte de commentaire, vous pouvez simplement spécifier
commentdans le corps de la requête. Nous générerons lecommentHTMLrésultant.- Si vous définissez à la fois
commentetcommentHTML, nous ne générerons pas automatiquement le HTML. - Si l'utilisateur ajoute des mentions ou des hashtags dans son nouveau texte, il sera toujours traité comme l'API
POST.
- Si vous définissez à la fois
- Lors de la mise à jour de
commenterEmailsur un commentaire, il est préférable de spécifier égalementuserId. Sinon, vous devez vous assurer que l'utilisateur avec cet email appartient à votre locataire, sinon la requête échouera.



DELETE /api/v1/comments/:id 
Ce endpoint API fournit la capacité de supprimer un commentaire.
Notes :
- Cette API peut mettre à jour le widget de commentaires "en direct" si désiré (cela augmente le
creditsCostde1à2). - Cette API supprimera tous les commentaires enfants.



POST /api/v1/comments/:id/flag 
Ce endpoint API fournit la capacité de signaler un commentaire pour un utilisateur spécifique.
Notes :
- Cet appel doit toujours être effectué dans le contexte d'un utilisateur. L'utilisateur peut être un utilisateur FastComments.com, un utilisateur SSO ou un utilisateur de locataire.
- Si un seuil de signalement pour masquer est défini, le commentaire sera automatiquement masqué en direct après avoir été signalé le nombre de fois défini.
- Après qu'il soit automatiquement désapprouvé (masqué) - le commentaire ne peut être réapprouvé que par un administrateur ou un modérateur. Annuler le signalement ne réapprouvera pas le commentaire.

Pour le signalement anonyme, nous devons spécifier un anonUserId. Cela peut être un ID qui représente la session anonyme, ou un UUID aléatoire.
Cela nous permet de prendre en charge le signalement et l'annulation du signalement des commentaires même si un utilisateur n'est pas connecté. De cette façon, le commentaire peut être marqué comme
signalé lorsque les commentaires sont récupérés avec le même anonUserId.



POST /api/v1/comments/:id/un-flag 
Ce endpoint API fournit la capacité d'annuler le signalement d'un commentaire pour un utilisateur spécifique.
Notes :
- Cet appel doit toujours être effectué dans le contexte d'un utilisateur. L'utilisateur peut être un utilisateur FastComments.com, un utilisateur SSO ou un utilisateur de locataire.
- Après qu'un commentaire soit automatiquement désapprouvé (masqué) - le commentaire ne peut être réapprouvé que par un administrateur ou un modérateur. Annuler le signalement ne réapprouvera pas le commentaire.

Pour le signalement anonyme, nous devons spécifier un anonUserId. Cela peut être un ID qui représente la session anonyme, ou un UUID aléatoire.



POST /api/v1/comments/:id/block 
Ce endpoint API fournit la capacité de bloquer un utilisateur qui a écrit un commentaire donné. Il prend en charge le blocage des commentaires écrits par les utilisateurs FastComments.com, les utilisateurs SSO et les utilisateurs de locataire.
Il prend en charge un paramètre de corps commentIdsToCheck pour vérifier si d'autres commentaires potentiellement visibles sur le client doivent être bloqués/débloqués après cette action.
Notes :
- Cet appel doit toujours être effectué dans le contexte d'un utilisateur. L'utilisateur peut être un utilisateur FastComments.com, un utilisateur SSO ou un utilisateur de locataire.
- Le
userIddans la requête est l'utilisateur qui effectue le blocage. Par exemple :Utilisateur Aveut bloquerUtilisateur B. PassezuserId=Utilisateur Aet l'id du commentaire queUtilisateur Ba écrit. - Les commentaires complètement anonymes (pas d'id utilisateur, pas d'email) ne peuvent pas être bloqués et une erreur sera retournée.

Pour le blocage anonyme, nous devons spécifier un anonUserId. Cela peut être un ID qui représente la session anonyme, ou un UUID aléatoire.
Cela nous permet de prendre en charge le blocage des commentaires même si un utilisateur n'est pas connecté en récupérant les commentaires avec le même anonUserId.



POST /api/v1/comments/:id/un-block 
Ce endpoint API fournit la capacité de débloquer un utilisateur qui a écrit un commentaire donné. Il prend en charge le déblocage des commentaires écrits par les utilisateurs FastComments.com, les utilisateurs SSO et les utilisateurs de locataire.
Il prend en charge un paramètre de corps commentIdsToCheck pour vérifier si d'autres commentaires potentiellement visibles sur le client doivent être bloqués/débloqués après cette action.
Notes :
- Cet appel doit toujours être effectué dans le contexte d'un utilisateur. L'utilisateur peut être un utilisateur FastComments.com, un utilisateur SSO ou un utilisateur de locataire.
- Le
userIddans la requête est l'utilisateur qui effectue le déblocage. Par exemple :Utilisateur Aveut débloquerUtilisateur B. PassezuserId=Utilisateur Aet l'id du commentaire queUtilisateur Ba écrit. - Les commentaires complètement anonymes (pas d'id utilisateur, pas d'email) ne peuvent pas être bloqués et une erreur sera retournée.




Structure du modèle de courriel 
Un objet EmailTemplate représente la configuration d'un modèle d'email personnalisé, pour un locataire.
Le système sélectionnera le modèle d'email à utiliser via :
- Son identifiant de type, nous l'appelons
emailTemplateId. Ce sont des constantes. - Le
domain. Nous essaierons d'abord de trouver un modèle pour le domaine auquel l'objet associé (comme unComment) est lié, et si aucune correspondance n'est trouvée, nous essaierons de trouver un modèle où le domaine est null ou*.
La structure de l'objet EmailTemplate est la suivante :

Notes
- Vous pouvez obtenir les valeurs valides de
emailTemplateIddepuis l'endpoint/definitions. - L'endpoint
/definitionsinclut également les traductions et données de test par défaut. - Les modèles échoueront à l'enregistrement avec une structure ou des données de test invalides.
GET /api/v1/email-templates/:id 
Les EmailTemplates individuels peuvent être récupérés par leur id correspondant (PAS emailTemplateId).



GET /api/v1/email-templates 
Cette API utilise la pagination, fournie par le paramètre de requête page. Les EmailTemplates sont retournés par pages de 100, triés par createdAt puis id.



PATCH /api/v1/email-templates/:id 
Ce endpoint API fournit la capacité de mettre à jour un modèle d'email en ne spécifiant que l'id et les attributs à mettre à jour.
Notez que toutes les mêmes validations pour créer un modèle s'appliquent également, par exemple :
- Le modèle doit se rendre. Ceci est vérifié à chaque mise à jour.
- Vous ne pouvez pas avoir de modèles en double pour le même domaine (sinon l'un serait silencieusement ignoré).



POST /api/v1/email-templates 
Ce endpoint API fournit la capacité de créer des modèles d'email.
Notes :
- Vous ne pouvez pas avoir plusieurs modèles avec le même
emailTemplateIdavec le même domaine. - Mais vous pouvez avoir un modèle générique (
domain=*) et un modèle spécifique au domaine pour le mêmeemailTemplateId. - Spécifier
domainn'est pertinent que si vous avez différents domaines, ou souhaitez utiliser des modèles spécifiques pour les tests (domaindéfini surlocalhostetc). - Si vous spécifiez
domain, il doit correspondre à unDomainConfig. En cas d'erreur, une liste de domaines valides est fournie. - La syntaxe du modèle est EJS et est rendue avec un timeout de 500ms. Le P99 pour le rendu est <5ms, donc si vous atteignez 500ms, quelque chose ne va pas.
- Votre modèle doit se rendre avec vos
testDatafournies pour être enregistré. Les erreurs de rendu sont agrégées et rapportées dans le tableau de bord (bientôt disponible via l'API).
Les données minimales requises pour ajouter un modèle sont les suivantes :

Vous voudrez peut-être avoir des modèles par site, auquel cas vous définissez domain :



POST /api/v1/email-templates/render 
Ce endpoint API fournit la capacité de prévisualiser des modèles d'email.



DELETE /api/v1/email-templates/:id 
Cette route fournit la suppression d'un unique EmailTemplate par id.



Structure du mot-clic 
Un objet HashTag représente un tag qui peut être laissé par un utilisateur. Les HashTags peuvent être utilisés pour créer un lien vers un contenu externe ou pour
relier des commentaires connexes ensemble.
La structure de l'objet HashTag est la suivante :

Notes :
- Dans certains endpoints API, vous verrez que le hashtag est utilisé dans l'URL. N'oubliez pas d'encoder les valeurs en URI. Par exemple,
#devrait être représenté comme%23. - Certains de ces champs sont marqués
READONLY- ils sont retournés par l'API mais ne peuvent pas être définis.
GET /api/v1/hash-tags 
Cette API utilise la pagination, fournie par le paramètre de requête page. Les HashTags sont retournés par pages de 100, triés par tag.



PATCH /api/v1/hash-tags/:tag 
Cette route fournit la capacité de mettre à jour un seul HashTag.



POST /api/v1/hash-tags 
Cette route fournit la capacité d'ajouter un seul HashTag.



POST /api/v1/hash-tags/bulk 
Cette route fournit la capacité d'ajouter jusqu'à 100 objets HashTag à la fois.



DELETE /api/v1/hash-tags/:tag 
Cette route permet la suppression d'un HashTag utilisateur par le tag fourni.
Notez qu'à moins que la création automatique de HashTag ne soit désactivée, les hashtags peuvent être recréés par un utilisateur fournissant le hashtag lors de la rédaction d'un commentaire.



Structure du modérateur 
Un objet Moderator représente la configuration d'un modérateur.
Il existe trois types de modérateurs :
- Les utilisateurs administrateurs qui ont le drapeau
isCommentModeratorAdmin. - Les utilisateurs SSO avec le drapeau
isCommentModeratorAdmin. - Les commentateurs réguliers, ou utilisateurs FastComments.com, qui sont invités en tant que modérateurs.
La structure Moderator est utilisée pour représenter l'état de modération du cas d'utilisation 3.
Si vous souhaitez inviter un utilisateur à être modérateur, via l'API, utilisez l'API Moderator en créant un Moderator et en l'invitant.
Si l'utilisateur n'a pas de compte FastComments.com, l'email d'invitation l'aidera à se configurer. S'il a déjà un compte, il se verra
accorder l'accès de modération à votre locataire et le userId de l'objet Moderator sera mis à jour pour pointer vers son utilisateur. Vous n'aurez pas d'accès API
à son utilisateur, car dans ce cas il lui appartient et est géré par FastComments.com.
Si vous avez besoin d'une gestion complète du compte de l'utilisateur, nous recommandons soit d'utiliser SSO, soit de l'ajouter en tant qu'Utilisateur Locataire et
ensuite d'ajouter un objet Moderator pour suivre ses statistiques.
La structure Moderator peut être utilisée comme mécanisme de suivi des statistiques pour les cas d'utilisation 1 et 2. Après avoir créé l'utilisateur, ajoutez un objet Moderator
avec son userId défini et ses statistiques seront suivies sur la Page des Modérateurs de Commentaires.
La structure de l'objet Moderator est la suivante :

GET /api/v1/moderators/:id 
Cette route retourne un seul modérateur par son id.



GET /api/v1/moderators 
Cette API utilise la pagination, fournie par le paramètre de requête skip. Les modérateurs sont retournés par pages de 100, triés par createdAt et id.
Le coût est basé sur le nombre de modérateurs retournés, coûtant 1 crédit par 10 modérateurs retournés.



PATCH /api/v1/moderators/:id 
Ce endpoint API fournit la capacité de mettre à jour un Moderator par id.
La mise à jour d'un Moderator a les restrictions suivantes :
- Les valeurs suivantes ne peuvent pas être fournies lors de la mise à jour d'un
Moderator:acceptedInvitemarkReviewedCountdeletedCountmarkedSpamCountapprovedCounteditedCountbannedCountverificationIdcreatedAt
- Lorsqu'un
userIdest spécifié, cet utilisateur doit exister. - Lorsqu'un
userIdest spécifié, il doit appartenir au mêmetenantIdspécifié dans les paramètres de requête. - Deux modérateurs dans le même locataire ne peuvent pas être ajoutés avec le même
email. - Vous ne pouvez pas changer le
tenantIdassocié à unModerator.



POST /api/v1/moderators 
Cette route fournit la capacité d'ajouter un seul Moderator.
La création d'un Moderator a les restrictions suivantes :
- Un
nameet unemaildoivent toujours être fournis. UnuserIdest optionnel. - Les valeurs suivantes ne peuvent pas être fournies lors de la création d'un
Moderator:acceptedInvitemarkReviewedCountdeletedCountmarkedSpamCountapprovedCounteditedCountbannedCountverificationIdcreatedAt
- Lorsqu'un
userIdest spécifié, cet utilisateur doit exister. - Lorsqu'un
userIdest spécifié, il doit appartenir au mêmetenantIdspécifié dans les paramètres de requête. - Deux modérateurs dans le même locataire ne peuvent pas être ajoutés avec le même
email.
Nous pouvons créer un Moderator pour un utilisateur dont nous ne connaissons que l'email :

Ou nous pouvons créer un Moderator pour un utilisateur qui appartient à notre locataire, pour suivre leurs statistiques de modération :



POST /api/v1/moderators/:id/send-invite 
Cette route fournit la capacité d'inviter un seul Moderator.
Les restrictions suivantes existent pour envoyer un email d'invitation à un Moderator :
- Le
Moderatordoit déjà exister. - Le
fromNamene peut pas dépasser100 caractères.
Notes :
- Si un utilisateur avec l'email fourni existe déjà, il sera invité à modérer les commentaires de votre locataire.
- Si un utilisateur avec l'email fourni n'existe pas, le lien d'invitation le guidera dans la création de son compte.
- L'invitation expirera après
30 jours.
Nous pouvons créer un Moderator pour un utilisateur dont nous ne connaissons que l'email :

Cela enverra un email comme Bob de TenantName vous invite à être modérateur...


DELETE /api/v1/moderators/:id 
Cette route permet la suppression d'un Moderator par id.



Structure du compteur de notifications 
Un objet NotificationCount représente le compteur de notifications non lues et les métadonnées pour un utilisateur.
S'il n'y a pas de notifications non lues, il n'y aura pas de NotificationCount pour l'utilisateur.
Les objets NotificationCount sont créés automatiquement et ne peuvent pas être créés via l'API. Ils expirent également après un an.
Vous pouvez effacer le compteur de notifications non lues d'un utilisateur en supprimant son NotificationCount.
La structure de l'objet NotificationCount est la suivante :

GET /api/v1/notification-count/:user_id 
Cette route retourne un seul NotificationCount par id utilisateur. Avec SSO, l'id utilisateur est au format <tenant id>:<user id>.
S'il n'y a pas de notifications non lues, il n'y aura pas de NotificationCount - donc vous obtiendrez un 404.
Ceci est différent de notifications/count en ce qu'il est beaucoup plus rapide, mais ne permet pas le filtrage.



DELETE /api/v1/notification-count/:user_id 
Cette route supprime un seul NotificationCount par id utilisateur. Avec SSO, l'id utilisateur est au format <tenant id>:<user id>.
Cela effacera le compteur de notifications non lues de l'utilisateur (la cloche rouge dans le widget de commentaires s'estompera et le compteur disparaîtra).



Structure de la notification 
Un objet Notification représente une notification pour un utilisateur.
Les objets Notification sont créés automatiquement et ne peuvent pas être créés via l'API. Ils expirent également après un an.
Les notifications ne peuvent pas être supprimées. Elles peuvent cependant être mises à jour pour définir viewed à false, et vous pouvez filtrer par viewed.
Un utilisateur peut également se désabonner des notifications pour un commentaire spécifique en définissant optedOut dans la notification à true. Vous pouvez vous réabonner en le définissant à false.
Il existe différents types de notifications - vérifiez relatedObjectType et type.
Les façons dont les notifications sont créées sont assez flexibles et peuvent être déclenchées par de nombreux scénarios (voir NotificationType).
À ce jour, l'existence d'une Notification n'implique pas réellement qu'un email est ou devrait être envoyé. Plutôt, les notifications
sont utilisées pour le fil de notifications et les intégrations connexes.
La structure de l'objet Notification est la suivante :

GET /api/v1/notifications 
Cette route retourne jusqu'à 30 objets Notification triés par createdAt, les plus récents en premier.
Vous pouvez filtrer par userId. Avec SSO, l'id utilisateur est au format <tenant id>:<user id>.



GET /api/v1/notifications/count 
Cette route retourne un objet contenant le nombre de notifications sous un paramètre count.
Elle est plus lente que /notification-count/ et double le coût en crédits, mais permet le filtrage sur plus de dimensions.
Vous pouvez filtrer par les mêmes paramètres que l'endpoint /notifications comme userId. Avec SSO, l'id utilisateur est au format <tenant id>:<user id>.




PATCH /api/v1/notifications/:id 
Ce endpoint API fournit la capacité de mettre à jour une Notification par id.
La mise à jour d'une Notification a les restrictions suivantes :
- Vous ne pouvez mettre à jour que les champs suivants :
viewedoptedOut



Structure de la page 
Un objet Page représente la page à laquelle plusieurs commentaires peuvent appartenir. Cette relation est définie par
urlId.
Une Page stocke des informations telles que le titre de la page, le nombre de commentaires et urlId.
La structure de l'objet Page est la suivante :

GET /api/v1/pages 
Vous pouvez actuellement uniquement récupérer toutes les pages (ou une seule page via /by-url-id) associées à votre compte. Si vous souhaitez une recherche plus fine, contactez-nous.



Conseil Utile
L'API Comment nécessite un urlId. Vous pouvez d'abord appeler l'API Pages, pour voir à quoi ressemblent les valeurs urlId disponibles pour vous.
GET /api/v1/pages/by-url-id 
Les pages individuelles peuvent être récupérées par leur urlId correspondant. Cela peut être utile pour rechercher les titres de pages ou les compteurs de commentaires.



Conseil Utile
N'oubliez pas d'encoder en URI les valeurs comme le urlId.
PATCH /api/v1/pages/:id 
Cette route fournit la capacité de mettre à jour une seule Page. Les commentaires correspondants seront mis à jour.



Note
Certains paramètres dans l'objet Page sont automatiquement mis à jour. Ce sont les attributs de comptage et de titre. Les comptages ne peuvent pas être mis à jour
via l'API car ce sont des valeurs calculées. Le title de la page peut être défini via l'API, mais serait écrasé si le widget de commentaires est utilisé sur
une page avec le même urlId et un titre de page différent.
POST /api/v1/pages 
Ce endpoint API fournit la capacité de créer des pages.
Un cas d'utilisation courant est le contrôle d'accès.
Notes :
- Si vous avez commenté sur un fil de commentaires, ou appelé l'API pour créer un
Comment, vous avez déjà créé un objetPage! Vous pouvez essayer de le récupérer via la routePage/by-url-id, en passant le mêmeurlIdpassé au widget de commentaires. - La structure
Pagecontient certaines valeurs calculées. Actuellement, ce sontcommentCountetrootCommentCount. Elles sont remplies automatiquement et ne peuvent pas être définies par l'API. Tenter de le faire provoquera une erreur de l'API.



DELETE /api/v1/pages/:id 
Cette route permet la suppression d'une seule page par id.
Notez qu'interagir avec le widget de commentaires pour une page avec le même urlId recréera simplement la Page de manière transparente.



Structure de l'événement webhook en attente 
Un objet PendingWebhookEvent représente un événement webhook en file d'attente qui est en attente.
Les objets PendingWebhookEvent sont créés automatiquement et ne peuvent pas être créés manuellement via l'API. Ils expirent également après un an.
Ils peuvent être supprimés, ce qui retire la tâche de la file d'attente.
Il existe différents types d'événements - vérifiez eventType (OutboundSyncEventType) et type (OutboundSyncType).
Un cas d'utilisation courant pour cette API est d'implémenter une surveillance personnalisée. Vous pouvez vouloir appeler l'endpoint /count périodiquement
pour interroger le compteur en attente pour des filtres donnés.
La structure de l'objet PendingWebhookEvent est la suivante :

GET /api/v1/pending-webhook-events 
Cette route retourne une liste d'événements webhook en attente sous un paramètre pendingWebhookEvents.
Cette API utilise la pagination, fournie par le paramètre skip. Les PendingWebhookEvents sont retournés par pages de 100, triés par createdAt les plus récents en premier.



GET /api/v1/pending-webhook-events/count 
Cette route retourne un objet contenant le nombre d'événements webhook en attente sous un paramètre count.
Vous pouvez filtrer par les mêmes paramètres que l'endpoint /pending-webhook-events



DELETE /api/v1/pending-webhook-events/:id 
Cette route permet la suppression d'un seul PendingWebhookEvent.
Si vous avez besoin d'une suppression en masse, appelez l'API GET avec pagination puis appelez cette API séquentiellement.



Structure de l'utilisateur SSO 
FastComments fournit une solution SSO facile à utiliser. La mise à jour des informations d'un utilisateur avec l'intégration basée sur HMAC est aussi simple que de faire charger la page à l'utilisateur avec un payload mis à jour.
Cependant, il peut être souhaitable de gérer un utilisateur en dehors de ce flux, pour améliorer la cohérence de votre application.
L'API SSO User fournit un moyen de faire du CRUD sur des objets que nous appelons SSOUsers. Ces objets sont différents des Users réguliers et gardés séparés pour la sécurité de type.
La structure de l'objet SSOUser est la suivante :

Facturation pour les Utilisateurs SSO
Les utilisateurs SSO sont facturés différemment selon leurs drapeaux de permission :
- Utilisateurs SSO Réguliers : Les utilisateurs sans permissions d'administrateur ou de modérateur sont facturés comme utilisateurs SSO réguliers
- Administrateurs SSO : Les utilisateurs avec les drapeaux
isAccountOwnerouisAdminAdminsont facturés séparément comme administrateurs SSO (même tarif que les administrateurs de locataire réguliers) - Modérateurs SSO : Les utilisateurs avec le drapeau
isCommentModeratorAdminsont facturés séparément comme modérateurs SSO (même tarif que les modérateurs réguliers)
Important : Pour éviter la double facturation, le système déduplique automatiquement les utilisateurs SSO par rapport aux utilisateurs et modérateurs de locataire réguliers par adresse email. Si un utilisateur SSO a le même email qu'un utilisateur ou modérateur de locataire régulier, il ne sera pas facturé deux fois.
Contrôle d'Accès
Les utilisateurs peuvent être divisés en groupes. C'est à cela que sert le champ groupIds, et c'est optionnel.
@Mentions
Par défaut, @mentions utilisera username pour rechercher d'autres utilisateurs SSO lorsque le caractère @ est tapé. Si displayName est utilisé, alors les résultats correspondant à
username seront ignorés lorsqu'il y a une correspondance pour displayName, et les résultats de recherche @mention utiliseront displayName.
Abonnements
Avec FastComments, les utilisateurs peuvent s'abonner à une page en cliquant sur l'icône de cloche dans le widget de commentaires et en cliquant sur S'abonner.
Avec un utilisateur régulier, nous leur envoyons des emails de notification basés sur leurs paramètres de notification.
Avec les utilisateurs SSO, nous séparons cela pour la rétrocompatibilité. Les utilisateurs ne recevront ces emails de notification d'abonnement supplémentaires
que si vous définissez optedInSubscriptionNotifications à true.
Badges
Vous pouvez attribuer des badges aux utilisateurs SSO en utilisant la propriété badgeConfig. Les badges sont des indicateurs visuels qui apparaissent à côté du nom d'un utilisateur dans les commentaires.
badgeIds- Un tableau d'IDs de badges à attribuer à l'utilisateur. Ceux-ci doivent être des IDs de badges valides créés dans votre compte FastComments. Limité à 30 badges.override- Si vrai, tous les badges existants affichés sur les commentaires seront remplacés par ceux fournis. Si faux ou omis, les badges fournis seront ajoutés aux badges existants.update- Si vrai, les propriétés d'affichage des badges seront mises à jour depuis la configuration du locataire chaque fois que l'utilisateur se connecte.
GET /api/v1/sso-users 
Cette route retourne les utilisateurs SSO par pages de 100. La pagination est fournie par le paramètre skip. Les utilisateurs sont triés par leur signUpDate et id.



GET /api/v1/sso-users/by-id/:id 
Cette route retourne un seul utilisateur SSO par son id.



GET /api/v1/sso-users/by-email/:email 
Cette route retourne un seul utilisateur SSO par son email.



PATCH /api/v1/sso-users/:id 
Cette route fournit la capacité de mettre à jour un seul utilisateur SSO.



POST /api/v1/sso-users 
Cette route permet la création d'un seul utilisateur SSO.
Essayer de créer deux utilisateurs avec le même ID résultera en une erreur.

Dans cet exemple, nous spécifions groupIds pour le contrôle d'accès, mais c'est optionnel.


Note d'Intégration
Les données passées par l'API peuvent être remplacées simplement en passant un payload HMAC d'utilisateur SSO différent. Par exemple, si vous définissez un nom d'utilisateur via l'API, mais passez ensuite un différent via le flux SSO au chargement de la page, nous mettrons automatiquement à jour leur nom d'utilisateur.
Nous ne mettrons pas à jour les paramètres utilisateur dans ce flux à moins que vous ne les spécifiez explicitement ou ne les définissiez à null (pas undefined).
PUT /api/v1/sso-users/:id 
Cette route fournit la capacité de mettre à jour un seul utilisateur SSO.

Dans cet exemple, nous spécifions groupIds pour le contrôle d'accès, mais c'est optionnel.


DELETE /api/v1/sso-users/:id 
Cette route permet la suppression d'un seul utilisateur SSO par son id.
Notez que charger à nouveau le widget de commentaires avec un payload pour cet utilisateur recréera simplement l'utilisateur de manière transparente.
La suppression des commentaires de l'utilisateur est possible via le paramètre de requête deleteComments. Notez que si cela est vrai :
- Tous les commentaires de l'utilisateur seront supprimés en direct.
- Tous les commentaires enfants (maintenant orphelins) seront supprimés ou anonymisés selon la configuration de page associée à chaque commentaire. Par exemple, si le mode de suppression de fil est "anonymiser", alors les réponses resteront, et les commentaires de l'utilisateur seront anonymisés. Cela s'applique uniquement lorsque
commentDeleteModeestRemove(la valeur par défaut). - Le
creditsCostdevient2.
Commentaires Anonymisés
Vous pouvez conserver les commentaires de l'utilisateur mais simplement les anonymiser en définissant commentDeleteMode=1.
Si les commentaires de l'utilisateur sont anonymisés, les valeurs suivantes sont définies à null :
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badgesisDeleted et isDeletedUser sont définis à true.
Lors du rendu, le widget de commentaires utilisera DELETED_USER_PLACEHOLDER (par défaut : "[deleted]") pour le nom de l'utilisateur et DELETED_CONTENT_PLACEHOLDER pour le commentaire. Ceux-ci peuvent être personnalisés via l'interface de personnalisation du widget.
Exemples



Structure de l'abonnement 
Un objet Subscription représente un abonnement pour un utilisateur.
Les objets Subscription sont créés lorsqu'un utilisateur clique sur la cloche de notification dans le widget de commentaires et clique sur "S'abonner à cette page".
Les abonnements peuvent également être créés via l'API.
Avoir un objet Subscription provoque la génération d'objets Notification, et l'envoi d'emails, lorsque de nouveaux commentaires sont laissés à la racine de la page associée
à laquelle le Subscription est destiné. L'envoi d'emails dépend du type d'utilisateur. Pour les utilisateurs réguliers, cela dépend de optedInNotifications. Pour les utilisateurs SSO, cela dépend de optedInSubscriptionNotifications. Notez que certaines applications peuvent ne pas avoir le concept de page accessible sur le web, auquel cas définissez simplement urlId sur
l'id de l'élément auquel vous vous abonnez (même valeur pour urlId que vous passeriez au widget de commentaires).
La structure de l'objet Subscription est la suivante :

GET /api/v1/subscriptions/:id 
Cette route retourne jusqu'à 30 objets Subscription triés par createdAt, les plus récents en premier.
Vous pouvez filtrer par userId. Avec SSO, l'id utilisateur est au format <tenant id>:<user id>.



POST /api/v1/subscriptions 
Ce endpoint API fournit la capacité de créer une Subscription. Notez qu'un utilisateur ne peut avoir qu'un seul abonnement par page, car plus est redondant, et essayer
de créer plus d'un abonnement pour le même utilisateur pour la même page résultera en une erreur.
Créer un abonnement résultera en la création d'objets Notification lorsqu'un nouveau commentaire est laissé à la racine du urlId abonné (lorsque le parentId du commentaire est null).



DELETE /api/v1/subscriptions/:id 
Cette route supprime un seul objet Subscription par id.



Structure de l'utilisation quotidienne du locataire 
Un objet TenantDailyUsage représente l'utilisation pour un locataire sur un jour donné. S'il n'y a eu aucune activité pour un locataire donné sur un jour
donné, ce jour n'aura pas d'objet TenantDailyUsage.
L'objet TenantDailyUsage n'est pas en temps réel et peut être en retard de quelques minutes par rapport à l'utilisation réelle.
La structure pour l'objet TenantDailyUsage est la suivante:

GET /api/v1/tenant-daily-usage 
Cette route permet de rechercher l'utilisation d'un locataire par année, mois et jour. Jusqu'à 365 objets peuvent être retournés, et le coût est de 1 crédit API par 10 objets.
Les objets de réponse sont triés par la date de création (les plus anciens en premier).



Structure du locataire 
Le Tenant définit un client FastComments.com. Ils peuvent être créés via l'API par des locataires ayant accès au white labeling. Les locataires en white label
ne peuvent pas créer d'autres locataires en white label (un seul niveau d'imbrication est autorisé).
La structure de l'objet Tenant est la suivante :

GET /api/v1/tenants/:id 
Cette route retourne un seul Tenant par id.



GET /api/v1/tenants 
Cette API retourne les locataires qui sont gérés par votre locataire.
La pagination est fournie par le paramètre de requête skip. Les locataires sont retournés par pages de 100, triés par signUpDate et id.
Le coût est basé sur le nombre de locataires retournés, coûtant 1 crédit par 10 locataires retournés.

Vous pouvez définir des paramètres meta sur les objets Tenant et rechercher des locataires correspondants. Par exemple, pour la clé someKey et la valeur meta some-value, nous pouvons
construire un objet JSON avec cette paire clé/valeur puis l'encoder en URI comme paramètre de requête pour filtrer :



POST /api/v1/tenants 
Cette route fournit la capacité d'ajouter un seul Tenant.
La création d'un Tenant a les restrictions suivantes :
- Un
nameest requis. domainConfigurationest requis.- Les valeurs suivantes ne peuvent pas être fournies lors de la création d'un
Tenant:hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmount
- Le
signUpDatene peut pas être dans le futur. - Le
namene peut pas dépasser200 caractères. - L'
emailne peut pas dépasser300 caractères. - L'
emaildoit être unique parmi tous les locataires de FastComments.com. - Vous ne pouvez pas créer de locataires si le locataire parent n'a pas de
TenantPackagevalide défini.- Si votre locataire a été créé via FastComments.com, cela ne devrait pas être un problème.
- Vous ne pouvez pas créer plus de locataires que défini sous
maxWhiteLabeledTenantsdans votre forfait. - Vous devez spécifier le paramètre de requête
tenantIdqui est l'id de votrelocataire parentavec le white labeling activé.
Nous pouvons créer un Tenant avec seulement quelques paramètres :



PATCH /api/v1/tenants/:id 
Ce endpoint API fournit la capacité de mettre à jour un Tenant par id.
La mise à jour d'un Tenant a les restrictions suivantes :
- Les valeurs suivantes ne peuvent pas être mises à jour :
hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmountmanagedByTenantId
- Le
signUpDatene peut pas être dans le futur. - Le
namene peut pas dépasser200 caractères. - L'
emailne peut pas dépasser300 caractères. - L'
emaildoit être unique parmi tous les locataires de FastComments.com. - Lors de la définition de
billingInfoValidàtrue,billingInfodoit être fourni dans la même requête. - Vous ne pouvez pas mettre à jour le
packageIdassocié à votre propre locataire. - Vous ne pouvez pas mettre à jour le
paymentFrequencyassocié à votre propre locataire.



DELETE /api/v1/tenants/:id 
Cette route fournit la suppression d'un Tenant et toutes les données associées (utilisateurs, commentaires, etc) par id.
Les restrictions suivantes existent concernant la suppression de locataires:
- Le locataire doit être le vôtre, ou un locataire en marque blanche que vous gérez.
- Le paramètre de requête
suredoit être défini àtrue.



Structure du forfait du locataire 
Le TenantPackage définit les informations de forfait disponibles pour un Tenant. Un locataire peut avoir plusieurs forfaits disponibles, mais un seul
en utilisation à un moment donné.
Un Tenant ne peut être utilisé pour aucun produit tant que son packageId ne pointe pas vers un TenantPackage valide.
Il existe deux types d'objets TenantPackage :
- Forfaits à prix fixe - où
hasFlexPricingest faux. - Tarification flexible - où
hasFlexPricingest vrai.
Dans les deux cas, des limites sont définies sur le compte utilisant le forfait, cependant avec Flex, le locataire est facturé un prix de base plus
ce qu'il a utilisé, défini par les paramètres flex*.
Un locataire peut avoir plusieurs forfaits de locataire et avoir la possibilité de changer le forfait lui-même depuis la Page d'Information de Facturation.
Si vous gérerez la facturation pour les locataires vous-mêmes, vous devrez toujours définir un forfait pour chaque locataire pour définir leurs limites. Définissez simplement billingHandledExternally à true sur le Tenant et ils
ne pourront pas changer leurs informations de facturation, ou forfait actif, eux-mêmes.
Vous ne pouvez pas créer de forfaits avec des limites plus élevées que le locataire parent.
La structure de l'objet TenantPackage est la suivante :

GET /api/v1/tenant-packages/:id 
Cette route retourne un seul Tenant Package par id.



GET /api/v1/tenant-packages 
Cette API utilise la pagination, fournie par le paramètre de requête skip. Les TenantPackages sont retournés par pages de 100, triés par createdAt et id.
Le coût est basé sur le nombre de forfaits de locataire retournés, coûtant 1 crédit par 10 forfaits de locataire retournés.



POST /api/v1/tenant-packages 
Cette route fournit la capacité d'ajouter un seul TenantPackage.
La création d'un TenantPackage a les restrictions suivantes:
- Les paramètres suivants sont requis:
nametenantIdmonthlyCostUSD- Peut être null.yearlyCostUSD- Peut être null.maxMonthlyPageLoadsmaxMonthlyAPICreditsmaxMonthlyCommentsmaxConcurrentUsersmaxTenantUsersmaxSSOUsersmaxModeratorsmaxDomainshasDebrandingforWhoTextfeatureTaglineshasFlexPricing- Si true, alors tous les paramètresflex*sont requis.
- Le
namene peut pas dépasser50 caractères. - Chaque élément
forWhoTextne peut pas dépasser200 caractères. - Chaque élément
featureTaglinesne peut pas dépasser100 caractères. - Le
TenantPackagedoit être "plus petit" que le locataire parent. Par exemple, tous les paramètresmax*doivent avoir des valeurs inférieures à celles du locataire parent. - Un locataire en marque blanche peut avoir un maximum de cinq packages.
- Seuls les locataires avec accès à la marque blanche peuvent créer un
TenantPackage. - Vous ne pouvez pas ajouter de packages à votre propre locataire. :)
Nous pouvons créer un TenantPackage comme suit:



PATCH /api/v1/tenant-packages/:id 
Ce endpoint API fournit la capacité de mettre à jour un TenantPackage par id.
La mise à jour d'un TenantPackage a les restrictions suivantes:
- Si vous définissez
hasFlexPricingà true, alors tous les paramètresflex*sont requis dans cette même requête. - Le
namene peut pas dépasser50 caractères. - Chaque élément
forWhoTextne peut pas dépasser200 caractères. - Chaque élément
featureTaglinesne peut pas dépasser100 caractères. - Le
TenantPackagedoit être "plus petit" que le locataire parent. Par exemple, tous les paramètresmax*doivent avoir des valeurs inférieures à celles du locataire parent. - Vous ne pouvez pas changer le
tenantIdassocié à unTenantPackage.



DELETE /api/v1/tenant-packages/:id 
Cette route fournit la suppression d'un TenantPackage par id.
Vous ne pouvez pas supprimer un TenantPackage qui est en cours d'utilisation (le packageId d'un locataire pointe vers le package). Mettez à jour le Tenant d'abord.



Structure de l'utilisateur du locataire 
Le TenantUser définit un User qui est géré par un locataire spécifique. Leur compte est sous le contrôle complet du locataire
auquel ils sont associés, et leur compte peut être mis à jour ou supprimé via l'interface utilisateur ou l'API.
Les utilisateurs locataires peuvent être des administrateurs avec toutes les permissions et accès au Tenant, ou ils peuvent être limités à des permissions spécifiques pour
modérer les commentaires, accéder aux clés API, etc.
La structure de l'objet TenantUser est la suivante :

GET /api/v1/tenant-users/:id 
Cette route retourne un seul TenantUser par id.



GET /api/v1/tenant-users 
Cette API utilise la pagination, fournie par le paramètre de requête skip. Les TenantUsers sont retournés par pages de 100, triés par signUpDate, username et id.
Le coût est basé sur le nombre d'utilisateurs locataires retournés, coûtant 1 crédit par 10 utilisateurs locataires retournés.



POST /api/v1/tenant-users 
Cette route fournit la capacité d'ajouter un seul TenantUser.
La création d'un TenantUser a les restrictions suivantes :
- Un
usernameest requis. - Un
emailest requis. - Le
signUpDatene peut pas être dans le futur. - Le
localedoit être dans la liste des Locales Supportées. - Le
usernamedoit être unique parmi tous les FastComments.com. Si c'est un problème, nous suggérons d'utiliser SSO à la place. - L'
emaildoit être unique parmi tous les FastComments.com. Si c'est un problème, nous suggérons d'utiliser SSO à la place. - Vous ne pouvez pas créer plus d'utilisateurs locataires que défini sous
maxTenantUsersdans votre forfait.
Nous pouvons créer un TenantUser comme suit



POST /api/v1/tenant-users/:id/send-login-link 
Cette route fournit la capacité d'envoyer un lien de connexion à un seul TenantUser.
Utile lors de la création en masse d'utilisateurs sans avoir à leur expliquer comment se connecter à FastComments.com. Cela leur enverra simplement un "lien magique" de connexion qui
expire après 30 jours.
Les restrictions suivantes existent pour envoyer un lien de connexion à un TenantUser :
- Le
TenantUserdoit déjà exister. - Vous devez avoir accès pour gérer le
Tenantauquel leTenantUserappartient.
Nous pouvons envoyer un lien de connexion à un TenantUser comme suit :

Cela enverra un email comme Bob de TenantName vous invite à être modérateur...


PATCH /api/v1/tenant-users/:id 
Cette route fournit la capacité de mettre à jour un seul TenantUser.
La mise à jour d'un TenantUser a les restrictions suivantes :
- Le
signUpDatene peut pas être dans le futur. - Le
localedoit être dans la liste des Locales Supportées. - Le
usernamedoit être unique parmi tous les FastComments.com. Si c'est un problème, nous suggérons d'utiliser SSO à la place. - L'
emaildoit être unique parmi tous les FastComments.com. Si c'est un problème, nous suggérons d'utiliser SSO à la place. - Vous ne pouvez pas mettre à jour le
tenantIdd'un utilisateur.
Nous pouvons créer un TenantUser comme suit



DELETE /api/v1/tenant-users/:id 
Cette route permet la suppression d'un TenantUser par id.
La suppression des commentaires de l'utilisateur est possible via le paramètre de requête deleteComments. Notez que si cela est vrai :
- Tous les commentaires de l'utilisateur seront supprimés en direct.
- Tous les commentaires enfants (maintenant orphelins) seront supprimés ou anonymisés selon la configuration de page associée à chaque commentaire. Par exemple, si le mode de suppression de fil est "anonymiser", alors les réponses resteront, et les commentaires de l'utilisateur seront anonymisés. Cela s'applique uniquement lorsque
commentDeleteModeestRemove(la valeur par défaut). - Le
creditsCostdevient2.
Commentaires Anonymisés
Vous pouvez conserver les commentaires de l'utilisateur mais simplement les anonymiser en définissant commentDeleteMode=1.
Si les commentaires de l'utilisateur sont anonymisés, les valeurs suivantes sont définies à null :
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badgesisDeleted et isDeletedUser sont définis à true.
Lors du rendu, le widget de commentaires utilisera DELETED_USER_PLACEHOLDER (par défaut : "[deleted]") pour le nom de l'utilisateur et DELETED_CONTENT_PLACEHOLDER pour le commentaire. Ceux-ci peuvent être personnalisés via l'interface de personnalisation du widget.
Exemples



Structure de l'utilisateur 
User est un objet qui représente un dénominateur commun de tous les utilisateurs.
Gardez à l'esprit qu'à FastComments nous avons un tas de cas d'utilisation différents pour les utilisateurs :
- SSO Sécurisé
- SSO Simple
- Utilisateurs Locataires (Par exemple : Administrateurs)
- Commentateurs
Cette API est pour les Commentateurs et les utilisateurs créés via SSO Simple. En gros, tout utilisateur créé
via votre site peut être accédé via cette API. Les utilisateurs locataires peuvent également être récupérés de cette façon, mais vous obtiendrez plus d'informations en interagissant avec l'API /tenant-users/.
Pour le SSO Sécurisé veuillez utiliser l'API /sso-users/.
Vous ne pouvez pas mettre à jour ces types d'utilisateurs. Ils ont créé leur compte via votre site, donc nous fournissons un accès en lecture seule basique, mais
vous ne pouvez pas faire de modifications. Si vous voulez avoir ce type de flux - vous devez configurer le SSO Sécurisé.
La structure de l'objet User est la suivante :

GET /api/v1/users/:id 
Cette route retourne un seul User par id.



Structure du vote 
Un objet Vote représente un vote laissé par un utilisateur.
La relation entre les commentaires et le vote est définie via commentId.
La structure de l'objet Vote est la suivante :

GET /api/v1/votes 
Les votes doivent être récupérés par urlId.
Types de Votes
Il existe trois types de votes :
- Votes authentifiés, qui sont appliqués au commentaire correspondant. Vous pouvez les créer via cette API.
- Votes authentifiés, qui sont en attente de vérification, et donc ne sont pas encore appliqués au commentaire. Ceux-ci sont créés lorsqu'un utilisateur utilise le mécanisme connexion pour voter de FastComments.com.
- Votes anonymes, qui sont appliqués au commentaire correspondant. Ceux-ci sont créés avec les commentaires anonymes.
Ceux-ci sont retournés dans des listes séparées dans l'API pour réduire la confusion.



Notes sur les Votes Anonymes
Notez que les votes anonymes créés via cette API apparaîtront dans la liste appliedAuthorizedVotes. Ils sont considérés comme autorisés puisqu'ils ont été créés via l'API avec une clé API.
La structure appliedAnonymousVotes est pour les votes créés sans email, clé API, etc.
GET /api/v1/votes/for-user 
Permet de récupérer les votes laissés par un utilisateur sur un urlId donné. Prend un userId qui peut être n'importe quel utilisateur FastComments.com ou SSO User.
Ceci est utile si vous voulez montrer si un utilisateur a voté sur un commentaire. Lors de la récupération des commentaires, appelez simplement cette API en même temps pour l'utilisateur avec le
même urlId.
Si vous utilisez le vote anonyme, vous voudrez passer anonUserId à la place.


Notez que les votes anonymes apparaîtront dans la liste appliedAuthorizedVotes. Ils sont considérés comme autorisés puisqu'ils ont été créés via l'API avec une clé API.


POST /api/v1/votes 
Cette route fournit la capacité d'ajouter un seul Vote autorisé. Les votes peuvent être up (+1) ou down (-1).




Création de Votes Anonymes
Les votes anonymes peuvent être créés en définissant anonUserId dans les paramètres de requête au lieu de userId.
Cet id n'a pas à correspondre à un objet utilisateur quelque part (d'où anonyme). C'est simplement un identifiant pour la session, afin que vous puissiez récupérer les votes à nouveau dans la même session, pour vérifier si un commentaire a été voté.
Si vous n'avez pas de concept de "sessions anonymes" comme FastComments - vous pouvez simplement définir ceci sur un ID aléatoire, comme un UUID (bien que nous apprécions les identifiants plus petits pour économiser de l'espace).
Autres Notes
- Cette API obéit aux paramètres au niveau du locataire. Par exemple, si vous désactivez le vote pour une page donnée, et que vous tentez de créer un vote via l'API, cela échouera avec le code d'erreur
voting-disabled. - Cette API est en direct par défaut.
- Cette API mettra à jour les
votesduCommentcorrespondant.
DELETE /api/v1/votes/:id 
Cette route fournit la capacité de supprimer un seul Vote.



Notes :
- Cette API obéit aux paramètres au niveau du locataire. Par exemple, si vous désactivez le vote pour une page donnée, et que vous tentez de créer un vote via l'API, cela échouera avec le code d'erreur
voting-disabled. - Cette API est en direct par défaut.
- Cette API mettra à jour les
votesduCommentcorrespondant.
Structure de la configuration de domaine 
Un objet DomainConfig représente la configuration d'un domaine pour un locataire.
La structure de l'objet DomainConfig est la suivante :


Pour l'Authentification
La Configuration de Domaine est utilisée pour déterminer quels sites peuvent héberger le widget FastComments pour votre compte. C'est une forme basique d'authentification, ce qui signifie qu'ajouter ou supprimer des Configurations de Domaine peut impacter la disponibilité de votre installation FastComments en production.
Ne supprimez pas et ne mettez pas à jour la propriété domain d'une Config de Domaine pour un domaine actuellement en cours d'utilisation, sauf si la désactivation de ce domaine est intentionnelle.
Cela a le même comportement que supprimer un domaine de /auth/my-account/configure-domains.
Notez également que supprimer un domaine de l'interface utilisateur Mes Domaines supprimera toute configuration correspondante pour ce domaine qui aurait pu être ajoutée via cette interface.
Pour la Personnalisation des Emails
Le lien de désabonnement dans le pied de page des emails, et la fonctionnalité de désabonnement en un clic offerte par de nombreux clients de messagerie, peuvent être configurés via cette API en définissant footerUnsubscribeURL et emailHeaders, respectivement.
Pour DKIM
Après avoir défini vos enregistrements DNS DKIM, mettez simplement à jour le DomainConfig avec votre configuration DKIM en utilisant la structure définie.
GET /api/v1/domain-configs 
Cette API fournit la capacité de récupérer tous les objets DomainConfig pour un locataire.



GET /api/v1/domain-configs/:domain 
Les DomainConfigs individuels peuvent être récupérés par leur domain correspondant.



POST /api/v1/domain-configs 
Ce endpoint API fournit la capacité de créer des configurations de domaine.
Ajouter une configuration pour un domaine autorise ce domaine pour le compte FastComments.
Les cas d'utilisation courants de cette API sont la configuration initiale, si de nombreux domaines doivent être ajoutés, ou une configuration personnalisée pour l'envoi d'emails.



PATCH /api/v1/domain-configs/:domain 
Ce endpoint API fournit la capacité de mettre à jour une configuration de domaine en ne spécifiant que le domaine et l'attribut à mettre à jour.



PUT /api/v1/domain-configs/:domain 
Ce endpoint API fournit la capacité de remplacer une configuration de domaine.



DELETE /api/v1/domain-configs/:domain 
Cette route fournit la suppression d'un unique DomainConfig par id.
- Note : Supprimer un
DomainConfigdésautorisera ce domaine d'utiliser FastComments. - Note : Réajouter un domaine via l'interface utilisateur recréera l'objet (avec seulement
domainrempli).



Structure de la configuration des questions 
FastComments fournit un moyen de construire des questions et d'agréger leurs résultats. Un exemple de question (ci-après appelée QuestionConfig)
pourrait être une évaluation par étoiles, un curseur, ou une question NPS (déterminé via type).
Les données de question peuvent être agrégées individuellement, ensemble, au fil du temps, globalement, par page, et ainsi de suite.
Le framework a toutes les capacités nécessaires pour construire des widgets côté client (avec votre serveur devant cette API), des tableaux de bord d'administration, et des outils de rapports.
D'abord, nous devons définir un QuestionConfig. La structure est la suivante:

GET /api/v1/question-configs 
Cette route retourne jusqu'à 100 objets QuestionConfig à la fois, paginés. Le coût est de 1 pour chaque 100 objets. Ils sont
triés par texte de question ascendant (champ question).



GET /api/v1/question-configs/:id 
Cette route retourne un seul QuestionConfig par son id.



POST /api/v1/question-configs 
Ce endpoint API fournit la capacité de créer un QuestionConfig.



PATCH /api/v1/question-configs/:id 
Cette route fournit la capacité de mettre à jour un seul QuestionConfig.
La structure suivante représente toutes les valeurs qui peuvent être modifiées:




DELETE /api/v1/question-configs/:id 
Cette route fournit la suppression d'un QuestionConfig par id.
Cela supprimera tous les résultats de question correspondants (mais pas les commentaires). Cela fait partie du coût élevé en crédits.



Structure du résultat de la question 
Afin de sauvegarder les résultats des questions, vous créez un QuestionResult. Vous pouvez ensuite agréger les résultats de questions, et aussi
les lier aux commentaires à des fins de rapports.

GET /api/v1/question-results 
Cette route retourne jusqu'à 1000 objets QuestionResults à la fois, paginés. Le coût est de 1 pour chaque 100 objets. Ils sont
triés par createdAt, ascendant. Vous pouvez filtrer par divers paramètres.



GET /api/v1/question-results/:id 
Cette route retourne un seul QuestionResult par son id.



POST /api/v1/question-results 
Ce endpoint API fournit la capacité de créer un QuestionResult.



PATCH /api/v1/question-results/:id 
Cette route fournit la capacité de mettre à jour un seul QuestionResult.
La structure suivante représente toutes les valeurs qui peuvent être modifiées:




DELETE /api/v1/question-results/:id 
Cette route fournit la suppression d'un QuestionResult par id.



GET /api/v1/question-results-aggregate 
C'est ici que l'agrégation des résultats se produit.
La structure de réponse d'agrégation est la suivante:

Voici les paramètres de requête disponibles pour l'agrégation:

Voici un exemple de requête:

Exemple de réponse:


Notes de Performance
- Pour un échec de cache, les agrégations prennent généralement cinq secondes par million de résultats.
- Sinon, les requêtes sont en temps constant.
Notes sur le Cache et les Coûts
- Lorsque
forceRecalculateest spécifié, le coût est toujours10, au lieu du2normal. - Si le cache expire et que les données sont recalculées, le coût reste un constant
2siforceRecalculaten'est pas spécifié. Le cache expire en fonction de la taille de l'ensemble de données agrégé (peut varier entre 30 secondes et 5 minutes). - Ceci est pour encourager l'utilisation du cache.
GET /api/v1/question-results-aggregate/combine/comments 
C'est ici que la combinaison des résultats avec les commentaires se produit. Utile pour créer un graphique de "commentaires positifs et négatifs récents" pour un produit, par exemple.
Vous pouvez rechercher via une plage de valeurs (inclusive), une ou plusieurs questions, et par une date de début (inclusive).
La structure de réponse est la suivante:

Voici les paramètres de requête disponibles pour l'agrégation:

Voici un exemple de requête:

Exemple de réponse:


Notes sur le Cache et les Coûts
- Lorsque
forceRecalculateest spécifié, le coût est toujours10, au lieu du2normal. - Si le cache expire et que les données sont recalculées, le coût reste un constant
2siforceRecalculaten'est pas spécifié. - Ceci est pour encourager l'utilisation du cache.
Structure du badge utilisateur 
UserBadge est un objet qui représente un badge attribué à un utilisateur dans le système FastComments.
Les badges peuvent être attribués aux utilisateurs automatiquement en fonction de leur activité (comme le nombre de commentaires, le temps de réponse, le statut de vétéran) ou manuellement par les administrateurs du site.
La structure de l'objet UserBadge est la suivante :

GET /api/v1/user-badges 
Ce endpoint vous permet de récupérer les badges utilisateur selon divers critères.
Exemple de Requête :
Run 
Vous pouvez ajouter divers paramètres de requête pour filtrer les résultats :
userId- Obtenir les badges pour un utilisateur spécifiquebadgeId- Obtenir les instances d'un badge spécifiquetype- Filtrer par type de badge (0=CommentCount, 1=CommentUpVotes, 2=CommentReplies, etc. Voir la structure UserBadge pour la liste complète)displayedOnComments- Filtrer par l'affichage du badge sur les commentaires (true/false)limit- Nombre maximum de badges à retourner (par défaut 30, max 200)skip- Nombre de badges à ignorer (pour la pagination)
Exemple de Réponse :

Réponses d'Erreur Possibles :


GET /api/v1/user-badges/:id 
Ce endpoint vous permet de récupérer un badge utilisateur spécifique par son ID unique.
Exemple de Requête :
Run 
Exemple de Réponse :

Réponses d'Erreur Possibles :


POST /api/v1/user-badges 
Ce endpoint vous permet de créer une nouvelle attribution de badge utilisateur.
Exemple de Requête :
Run 
Le corps de la requête doit contenir les paramètres suivants :
userId(requis) - L'ID de l'utilisateur auquel attribuer le badgebadgeId(requis) - L'ID du badge à attribuerdisplayedOnComments(optionnel) - Si le badge doit être affiché sur les commentaires de l'utilisateur (par défaut à true)
Notes Importantes :
- Le badge doit exister et être activé dans le catalogue de badges de votre locataire
- Vous ne pouvez attribuer des badges qu'aux utilisateurs qui appartiennent à votre locataire ou qui ont commenté sur votre site
Exemple de Réponse :

Réponses d'Erreur Possibles :





PUT /api/v1/user-badges/:id 
Ce endpoint vous permet de mettre à jour une attribution de badge utilisateur.
Actuellement, la seule propriété qui peut être mise à jour est displayedOnComments, qui contrôle si le badge est affiché sur les commentaires de l'utilisateur.
Exemple de Requête :
Run 
Exemple de Réponse :

Réponses d'Erreur Possibles :



DELETE /api/v1/user-badges/:id 
Ce endpoint vous permet de supprimer une attribution de badge utilisateur.
Exemple de Requête :
Run 
Exemple de Réponse :

Réponses d'Erreur Possibles :



Structure de la progression du badge utilisateur 
UserBadgeProgress est un objet qui représente la progression d'un utilisateur vers l'obtention de divers badges dans le système FastComments.
Ce suivi aide à déterminer quand les utilisateurs devraient recevoir des badges automatiques en fonction de leur activité et participation dans votre communauté.
La structure de l'objet UserBadgeProgress est la suivante :

GET /api/v1/user-badge-progress 
Ce endpoint vous permet de récupérer les enregistrements de progression de badge utilisateur selon divers critères.
Exemple de Requête :
Run 
Vous pouvez ajouter divers paramètres de requête pour filtrer les résultats :
userId- Obtenir la progression pour un utilisateur spécifiquelimit- Nombre maximum d'enregistrements à retourner (par défaut 30, max 200)skip- Nombre d'enregistrements à ignorer (pour la pagination)
Exemple de Réponse :

Réponses d'Erreur Possibles :


GET /api/v1/user-badge-progress/:id 
Ce endpoint vous permet de récupérer un enregistrement de progression de badge utilisateur spécifique par son ID unique.
Exemple de Requête :
Run 
Exemple de Réponse :

Réponses d'Erreur Possibles :


GET /api/v1/user-badge-progress/user/:userId 
Ce endpoint vous permet de récupérer l'enregistrement de progression de badge d'un utilisateur par son ID utilisateur.
Exemple de Requête :
Run 
Exemple de Réponse :

Réponses d'Erreur Possibles :



En conclusion
Nous espérons que vous avez trouvé la documentation de notre API complète et facile à comprendre. Si vous constatez des lacunes, faites-le nous savoir ci-dessous.