
Lingua 🇮🇹 Italiano
Risorse API
Autenticazione
Aggregazioni
Log di audit
Job batch
Commenti
Modelli email
Post del feed
HashTag
Io
Moderatori
Conteggio notifiche
Notifiche
Reazioni pagina
Pagine
Sondaggi
Voti sondaggio
Eventi webhook in sospeso
Utenti SSO
Abbonamenti
Utilizzo giornaliero tenant
Tenant
Pacchetti tenant
Utenti tenant
Utenti
Voti
Configurazioni dominio
Configurazioni domanda
Risultati domanda
Aggregazione risultati domanda
Badge utente
Progresso badge utente
API di commenti in tempo reale
L'API FastComments
FastComments fornisce un'API per interagire con molte risorse. Crea integrazioni con la nostra piattaforma, o anche i tuoi propri client!
In questa documentazione, troverai tutte le risorse supportate dall'API documentate con i loro tipi di richiesta e risposta.
Per i clienti Enterprise, tutti gli accessi all'API sono registrati nel Registro di Audit.
SDK Generati
FastComments ora genera una Specificazione API dal nostro codice (non è ancora completa, ma include molte API).
Abbiamo anche ora SDK per i linguaggi più popolari:
- fastcomments-cpp
- fastcomments-go
- fastcomments-java
- fastcomments-sdk-js
- fastcomments-nim
- fastcomments-php
- fastcomments-php-sso
- fastcomments-python
- fastcomments-ruby
- fastcomments-rust
- fastcomments-swift
Autenticazione
L'API è autenticata passando la tua chiave API come header X-API-KEY o come parametro di query API_KEY. Avrai anche bisogno del tuo tenantId per effettuare chiamate API. Questo può essere recuperato dalla stessa pagina della tua chiave API.
Nota di Sicurezza
Queste rotte sono destinate a essere chiamate da un server. NON chiamarle da un browser. Farlo esporrà la tua chiave API - questo fornirà pieno accesso al tuo account a chiunque possa visualizzare il codice sorgente di una pagina!
Opzione di Autenticazione Uno - Header
- Header:
X-API-KEY - Header:
X-TENANT-ID
Opzione di Autenticazione Due - Parametri di Query
- Query Param:
API_KEY - Query Param:
tenantId
Opzione di Autenticazione Tre - Token OAuth Bearer
- Header:
Authorization: Bearer fcat_...
Le applicazioni di terze parti come Zapier e i client del server MCP ottengono un token tramite OAuth invece di una chiave API. Quel token funziona su tutti gli endpoint qui. Il tenant è implicito nel token, quindi tenantId è opzionale, ma deve corrispondere al token se fornito. Le richieste GET richiedono lo scope read e ogni altro metodo richiede lo scope write. Il flusso completo, inclusa la registrazione del client, PKCE, refresh e revoca, è documentato sotto OAuth Authorization. La scoperta inizia a https://fastcomments.com/.well-known/oauth-authorization-server.
Leggere le proprie scritture
FastComments fornisce disponibilità Active-Active. Le richieste dal tuo datacenter sono instradate al punto di presenza più vicino al tuo. Questo è automatico, e normalmente puoi osservare la semantica di lettura-scrittura. Se vuoi essere sicuro di leggere le tue proprie scritture, puoi fissare le tue richieste a una certa regione usando quella regione come host API (tuttavia ciò di solito non è necessario per la maggior parte delle integrazioni):
- gdc-oregon.fastcomments.com
- gdc-virginia.fastcomments.com
- gdc-singapore.fastcomments.com
- gdc-falkenstein2.fastcomments.com
- gdc-sao-paulo.fastcomments.com
- eudc-helsinki2.fastcomments.com
- eudc-limburg.fastcomments.com
- eudc-france.fastcomments.com
Nota che se fai così potresti voler definire un fallback, poiché in passato abbiamo deprecato i nodi di ingresso e utilizziamo nuovi nomi per il passaggio.
Risorse API 
Utilizzo delle risorse
Va notato che il recupero dei dati dall'API viene conteggiato come utilizzo sul tuo account.
Ogni risorsa elencherà quale sia quell'utilizzo nella sua sezione.
Alcune risorse costano di più da servire rispetto ad altre. Ogni endpoint ha un costo fisso di crediti per chiamata API. Per alcuni endpoint, il numero di crediti varia in base alle opzioni e alle dimensioni delle risposte.
L'utilizzo dell'API può essere verificato nella pagina Billing Analytics ed è aggiornato ogni pochi minuti.
Nota!
Consigliamo di leggere prima la documentazione delle Pagine, per aiutare a limitare la confusione nella determinazione dei valori da passare per urlId nell'API dei Commenti.
Webhook
Le sottoscrizioni ai webhook hanno la propria guida. POST, GET e DELETE /api/v1/webhooks, e GET /api/v1/webhooks/sample-payloads, sono documentati in Managing Subscriptions via API, e i payload degli eventi in Webhook Structures.
Autorizzazione OAuth 
FastComments è un server di autorizzazione OAuth 2.1. Un'applicazione può ottenere un token associato a un account FastComments e usarlo su ogni endpoint in questa guida al posto di una chiave API. È così che l'app Zapier, il server MCP e altre integrazioni di terze parti si connettono.
I token vengono emessi tramite il flusso di codice di autorizzazione con PKCE. Non esistono grant di credenziali client né grant impliciti.
Scoperta
Le posizioni degli endpoint, i grant supportati e i metodi di autenticazione sono pubblicati all'URL standard dei metadati:

Gli endpoint che descrive:

Gli account nella regione EU usano https://eu.fastcomments.com come emittente, con gli stessi percorsi.
Registrazione di un client
Un client ha bisogno di un client_id e di un redirect_uri registrato prima di poter avviare il flusso. Ci sono due modi per ottenerne uno:
- Registrazione dinamica del client.
POST /oauth/registercon un corpo JSON secondo RFC 7591 (redirect_uris,client_name,client_uri,logo_uri,token_endpoint_auth_method). La risposta contiene ilclient_ide, per i client confidenziali, ilclient_secret. La registrazione è non autenticata e limitata per IP. - Documento di metadati del client ID. Il client utilizza un URL
httpsche controlla come suoclient_id. FastComments recupera quell'URL e legge gli stessi campi di metadati. Non è necessaria alcuna chiamata di registrazione.
Le applicazioni partner elencate nella dashboard di FastComments, come Zapier, sono registrate direttamente da FastComments. Contatta il supporto se stai creando un'inserzione di marketplace e hai bisogno di un client di prima parte.
Scope

Una richiesta che non specifica alcuno scope ottiene entrambi. L'utente vede gli scope richiesti nella pagina di consenso. Una richiesta per uno scope diverso da questi due fallisce con invalid_scope.
Passo 1 - Richiesta di autorizzazione
Invia il browser dell'utente all'endpoint di autorizzazione. PKCE con il metodo S256 è obbligatorio per ogni client.


L'utente accede a FastComments se necessario e vede una pagina di consenso che indica la tua applicazione, l'account a cui sarà collegata e gli scope richiesti. L'utente deve possedere il permesso API Admin su quell'account; chiunque altro vede un errore di permesso invece del modulo di consenso. L'approvazione reindirizza il browser al tuo redirect_uri con code e state. Il rifiuto reindirizza con error=access_denied.
Il codice di autorizzazione è valido per 10 minuti e può essere scambiato una sola volta. Un secondo scambio dello stesso codice revoca tutti i token prodotti dal primo scambio.
Passo 2 - Richiesta di token
Scambia il codice per i token. Il corpo è codificato come form. I client confidenziali si autenticano con client_secret_basic (HTTP Basic) o client_secret_post (segreto nel corpo). I client pubblici inviano solo client_id.



Gli errori seguono RFC 6749: un corpo JSON con error e error_description, HTTP 400 per invalid_request, invalid_grant, invalid_scope, invalid_target e unsupported_grant_type, HTTP 401 per invalid_client, HTTP 429 quando limitati per velocità.
Passo 3 - Chiamare l'API
Invia il token di accesso come token bearer. Il tenant è implicito nel token, quindi tenantId è opzionale. Se fornito deve corrispondere al token altrimenti la richiesta fallisce.

GET /api/v1/me restituisce il tenant, l'utente autorizzatore e gli scope concessi, il che lo rende la chiamata giusta per un test di connessione. Una richiesta con un token scaduto o revocato restituisce HTTP 401. Una richiesta il cui metodo richiede uno scope non posseduto dal token restituisce HTTP 403.
Passo 4 - Aggiornamento


La risposta ha la stessa struttura dello scambio del codice. I refresh token ruotano: ogni refresh restituisce un nuovo refresh_token e revoca quello vecchio dopo una finestra di grazia di 30 secondi per richieste concorrenti. Presentare un refresh token ruotato più di 30 secondi fa sì che venga trattato come replay e revoca l'intero grant. Le applicazioni partner registrate da FastComments sono esenti dalla rotazione e ricevono lo stesso refresh token con la scadenza estesa di altri 30 giorni.
Un refresh verifica anche che l'utente autorizzatore mantenga ancora il permesso API Admin sull'account. In caso contrario, il grant è revocato e la risposta è invalid_grant.
Revoca

Revocare un refresh token revoca tutti gli access token emessi dallo stesso grant. Revocare un access token revoca solo quel token. L'endpoint restituisce HTTP 200 con un oggetto JSON vuoto, indipendentemente dal fatto che il token sia stato trovato, secondo RFC 7009.
Gli utenti possono anche revocare una connessione da App connesse nella dashboard di FastComments. Tutti i token per quell'applicazione smettono di funzionare immediatamente.
Aggrega i tuoi dati 
Questa API aggrega documenti raggruppandoli (se viene fornito groupBy) e applicando più operazioni. Sono supportate diverse operazioni (ad es. sum, countDistinct, avg, ecc.).
Il costo è variabile. Ogni 500 oggetti scansionati costa 1 credito API.
La memoria massima consentita per chiamata API di default è 64MB, e per impostazione predefinita puoi avere una sola aggregazione in esecuzione alla volta. Se invii più aggregazioni simultaneamente, verranno messe in coda ed eseguite nell'ordine di invio. Le aggregazioni in attesa rimarranno in coda per un massimo di 60 secondi, dopodiché la richiesta scadrà. Le singole aggregazioni possono essere eseguite per un massimo di 5 minuti.
Se hai tenant gestiti, puoi aggregare tutte le risorse dei tenant figli in una singola chiamata passando il parametro di query parentTenantId.
Esempi
Esempio: Conteggio valori unici


Esempio: Conteggio valori distinti

Risposta:

Esempio: Somma dei valori di più campi

Risposta:

Esempio: Media dei valori di più campi

Risposta:

Esempio: Valori min/max di più campi

Risposta:

Esempio: Conteggio valori unici di più campi

Risposta:

Esempio: Creazione di query

Risposta:

Esempio: Conteggio dei commenti in attesa di revisione

Risposta:

Esempio: Ripartizione dei commenti approvati, revisionati e spam

Risposta:

Strutture


Le seguenti risorse possono essere aggregate:
- 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
Struttura AuditLog 
An AuditLog è un oggetto che rappresenta un evento auditato per i tenant che hanno accesso a questa funzionalità.
La struttura dell'oggetto AuditLog è la seguente:

targetId e targetLabel descrivono su cosa è stato eseguito l'evento; userId e username descrivono chi lo ha eseguito. Per gli aggiornamenti, objectDetails.changes contiene una mappa {field: {from, to}} di ciò che è effettivamente cambiato.
Il registro di audit è immutabile. Non può nemmeno essere scritto manualmente. FastComments.com può decidere solo quando scrivere nel registro di audit. Tuttavia, è possibile leggerlo tramite questa API.
Gli eventi nel registro di audit scadono dopo due anni.
GET /api/v1/audit-logs 
Questa API utilizza la paginazione, fornita dai parametri skip, limit, before e after. Gli AuditLogs vengono restituiti in pagine di 1000 per impostazione predefinita, fino a un limit massimo di 10000, ordinati per when e id. Le pagine sono grandi perché questo endpoint viene in genere utilizzato per esportare la cronologia piuttosto che per sfogliarla interattivamente.
Ogni 100 log restituiti ha un costo di 1 credito.
Per impostazione predefinita, riceverai un elenco con gli elementi più recenti per primi. In questo modo, puoi effettuare il polling partendo da skip=0, paginando fino a trovare l'ultimo record che hai consumato.
In alternativa, puoi ordinare dal più vecchio al più recente, e paginare finché non ci sono più record.
L'ordinamento può essere effettuato impostando order su ASC o DESC. Il valore predefinito è DESC.
L'interrogazione per data è possibile tramite before e after come timestamp con millisecondi. before e after NON sono inclusivi, e ciascuno può essere utilizzato da solo.
Trovare cosa è successo a una persona
Ogni evento registra chi lo ha eseguito (username, userId, ip) e, separatamente, su cosa è stato eseguito. targetLabel è un'etichetta leggibile dall'utente per quell'oggetto, ad esempio jsmith (jsmith@example.com), e targetId è il suo id. Usa target per una corrispondenza di sottostringa senza distinzione tra maiuscole e minuscole sull'etichetta quando conosci il nome o l'email di una persona ma non il suo id.
Le eliminazioni acquisiscono l'etichetta al momento dell'evento, quindi un utente o un moderatore rimosso può ancora essere identificato dopo che il record sottostante è stato eliminato.
Tenant gestiti
Se il tuo tenant gestisce altri tenant, imposta includeManagedTenants=true per restituire gli eventi del tuo tenant e di ogni tenant che gestisce in un'unica risposta. Il tenantId di ogni log restituito ti indica da quale tenant proviene.



Struttura BatchJob 
Un BatchJob è un'attività a lunga esecuzione, come un'importazione, un'esportazione o una migrazione di pagina. I lavori sono accodati, poi prelevati ed eseguiti in background.
processedCount e totalCount mostrano l'avanzamento. La loro unità dipende dal type:
migrate-pages: migrazioni completate, rispetto alle migrazioni richieste.undo-page-migration: record ripristinati. Non c'ètotalCount.import,exporte altri lavori: righe elaborate.
La struttura dell'oggetto BatchJob è la seguente:

Tentativi
Se il server che esegue un lavoro di migrazione di pagina si riavvia, il lavoro viene reinserito nella coda e riprende dopo l'ultima migrazione completata. Un lavoro viene provato fino a 3 volte, dopodiché il suo status è failed.
GET /api/v1/batch-jobs 
Questo endpoint restituisce i batch job del tenant di ogni tipo, dal più recente al più vecchio, 100 per pagina. Usa type e status per restringere l'elenco e skip per paginarlo.



GET /api/v1/batch-jobs/:id 
Questa rotta restituisce lo stato, il progresso e, una volta terminato, il risultato di un batch job. Usala per monitorare un job avviato da POST /api/v1/pages/migrations o POST /api/v1/pages/migrations/:undoId/undo.
Un job è terminato quando il suo status è success o failed. Ogni chiamata costa 1 credito, quindi effettua il polling ogni pochi secondi anziché continuamente.




Struttura commento 
Un oggetto Comment rappresenta un commento lasciato da un utente.
La relazione tra commenti padre e figli è definita tramite parentId.
La struttura dell'oggetto Comment è la seguente:

Alcuni di questi campi sono contrassegnati come READONLY - questi vengono restituiti dall'API ma non possono essere impostati.
Struttura del Testo del Commento
I commenti sono scritti in una variante di markdown di FastComments, che è semplicemente markdown più i tradizionali tag in stile bbcode per le immagini, come [img]path[/img].
Il testo è memorizzato in due campi. Il testo inserito dall'utente è memorizzato non modificato nel campo comment. Questo viene renderizzato e memorizzato nel campo commentHTML.
I tag HTML consentiti sono b, u, i, strike, pre, span, code, img, a, strong, ul, ol, li, and br.
Si raccomanda di renderizzare l'HTML, dato che è un sottoinsieme molto piccolo di HTML, costruire un renderer è piuttosto semplice. Esistono diverse librerie per React Native e Flutter, per esempio, che possono aiutare in questo
Puoi scegliere di renderizzare il valore non normalizzato del campo comment. Un esempio di parser è qui..
L'esempio di parser può anche essere adattato per funzionare con HTML e trasformare i tag HTML negli elementi attesi da renderizzare per la tua piattaforma.
Tagging
Quando gli utenti vengono taggati in un commento, le informazioni vengono memorizzate in una lista chiamata mentions. Ogni oggetto in quella lista
ha la seguente struttura.
Run 
HashTags
Quando gli hashtag vengono usati e analizzati correttamente, le informazioni vengono memorizzate in una lista chiamata hashTags. Ogni oggetto in quella lista
ha la seguente struttura. Gli hashtag possono anche essere aggiunti manualmente all'array hashTags del commento per le query, se retain è impostato.
Run 
GET /api/v1/comments 
Questa API viene utilizzata per ottenere i commenti da mostrare a un utente. Ad esempio, filtra automaticamente i commenti non approvati o contrassegnati come spam.
Paginazione
La paginazione può essere effettuata in uno dei due modi seguenti, a seconda dei requisiti di prestazioni e del caso d'uso:
- Più veloce: Paginazione Precalcolata:
- È così che funziona FastComments quando si utilizzano i nostri widget e client predefiniti.
- Cliccare su "successivo" semplicemente incrementa il numero di pagina.
- Si può pensare a questo come a un recupero da un archivio chiave-valore.
- In questo modo, basta definire un parametro
pagea partire da0e una direzione di ordinamento comedirection. - Le dimensioni della pagina possono essere personalizzate tramite regole di personalizzazione.
- Più flessibile: Paginazione Flessibile:
- In questo modo è possibile definire parametri
limiteskippersonalizzati. Non passarepage. - Anche la
directiondi ordinamento è supportata. limitè il numero totale da restituire dopo l'applicazione diskip.- Esempio: impostare
skip = 200, limit = 100quandopage size = 100epage = 2.
- Esempio: impostare
- I commenti figli contano comunque nella paginazione. È possibile aggirare questo problema utilizzando l'opzione
asTree.- È possibile paginare i figli tramite
limitChildreneskipChildren. - È possibile limitare la profondità dei thread restituiti tramite
maxTreeDepth.
- È possibile paginare i figli tramite
- In questo modo è possibile definire parametri
Thread
- Quando si utilizza la
Paginazione Precalcolata, i commenti sono raggruppati per pagina e i commenti nei thread influiscono sulla pagina complessiva.- In questo modo, i thread possono essere determinati sul client in base a
parentId. - Ad esempio, con una pagina contenente un commento di primo livello e 29 risposte, impostando
page=0nell'API - si otterrà solo il commento di primo livello e i 29 figli.
- In questo modo, i thread possono essere determinati sul client in base a
- Quando si utilizza la
Paginazione Flessibile, è possibile definire un parametroparentId.- Impostarlo su null per ottenere solo i commenti di primo livello.
- Quindi, per visualizzare i thread, chiamare nuovamente l'API passando
parentId. - Una soluzione comune è effettuare una chiamata API per i commenti di primo livello e poi effettuare chiamate API in parallelo per ottenere i commenti dei figli di ciascun commento.
- NOVITÀ Da Febbraio 2023! Recupero come albero utilizzando
&asTree=true.- Si può pensare a questo come a una
Paginazione Flessibile come Albero. - Solo i commenti di primo livello contano nella paginazione.
- Impostare
parentId=nullper iniziare l'albero dalla radice (è necessario impostareparentId). - Impostare
skipelimitper la paginazione. - Impostare
asTreesutrue. - Il costo in crediti aumenta del
2x, poiché il nostro backend deve fare molto più lavoro in questo scenario. - Impostare
maxTreeDepth,limitChildreneskipChildrencome desiderato.
- Si può pensare a questo come a una
Spiegazione degli Alberi
Quando si utilizza asTree, può essere difficile ragionare sulla paginazione. Ecco un grafico utile:
Recupero dei Commenti nel Contesto di un Utente
L'API /comments può essere utilizzata in due contesti, per diversi casi d'uso:
- Per restituire commenti ordinati e etichettati con informazioni per la creazione del proprio client.
- In questo caso, definire un parametro di query
contextUserId.
- In questo caso, definire un parametro di query
- Per recuperare commenti dal proprio backend per integrazioni personalizzate.
- La piattaforma passerà per impostazione predefinita a questa modalità senza
contextUserId.
- La piattaforma passerà per impostazione predefinita a questa modalità senza




Ottenere i Commenti come Albero
È possibile ottenere i commenti restituiti come albero, con la paginazione che conta solo i commenti di primo livello.

Si vogliono ottenere solo i commenti di primo livello e i figli immediati? Ecco un modo:

Tuttavia, nella propria UI potrebbe essere necessario sapere se mostrare un pulsante "mostra risposte" su
ciascun commento. Quando si recuperano i commenti come albero, esiste una proprietà hasChildren aggiunta
ai commenti quando applicabile.
Ottenere i Commenti come Albero, Cercando per Hashtag
È possibile cercare per hashtag utilizzando l'API, su tutto il proprio tenant (non limitato a una pagina o a un urlId).
In questo esempio, omettiamo urlId e cerchiamo per più hashtag. L'API restituirà solo i commenti che hanno tutti gli hashtag richiesti.

Tutti i Parametri della Richiesta

La Risposta

Suggerimenti Utili
URL ID
Probabilmente si desidera utilizzare l'API Comment con il parametro urlId. È possibile chiamare prima l'API Pages, per vedere come sono i valori urlId disponibili.
Azioni Anonime
Per i commenti anonimi probabilmente si desidera passare anonUserId durante il recupero dei commenti e quando si effettuano segnalazioni e blocchi.
(!) Questo è richiesto da molti app store poiché gli utenti devono poter segnalare i contenuti creati dagli utenti che possono vedere, anche se non sono registrati. Non farlo può causare la rimozione della propria app da tale store.
Commenti Non Restituiti
Verificare che i propri commenti siano approvati e non siano spam.
GET /api/v1/comments/:id 
Questa API fornisce la possibilità di recuperare un singolo commento tramite id.



POST /api/v1/comments 
Questo endpoint API consente di creare commenti.
Gli usi comuni sono interfacce utente personalizzate, integrazioni o importazioni.
Note:
- Questa API può aggiornare il widget dei commenti in "live" se desiderato (questo aumenta
creditsCostda1a2). - Questa API creerà automaticamente oggetti utente nel nostro sistema se viene fornita un'email.
- Tentare di salvare due commenti con email diverse, ma lo stesso username, risulterà in un errore per il secondo commento.
- Se specifichi
parentId, e un commento figlio hanotificationSentForParentimpostato su false, invieremo notifiche per il commento genitore. Questo viene fatto ogni ora (raggruppiamo le notifiche insieme per diminuire il numero di email inviate). - Se vuoi inviare email di benvenuto quando crei utenti, o email di verifica del commento, imposta
sendEmailssutruenei parametri di query. - I commenti creati tramite questa API appariranno nelle pagine Analytics e Moderation dell'app di amministrazione.
- Le "bad words" sono ancora mascherate nei nomi dei commentatori e nel testo del commento se l'impostazione è attivata.
- I commenti creati tramite questa API possono comunque essere controllati per spam, se desiderato.
- La configurazione come la lunghezza massima del commento, se configurata tramite la pagina admin Customization Rule, si applicherà qui.
I dati minimi richiesti per l'invio che verranno visualizzati nel widget dei commenti, sono i seguenti:

Una richiesta più realistica potrebbe apparire così:



PATCH /api/v1/comments/:id 
Questo endpoint API fornisce la possibilità di aggiornare un singolo commento.
Note:
- Questa API può aggiornare il widget dei commenti "live" se desiderato (questo aumenta il
creditsCostbase da1a2).- Questo può rendere "live" la migrazione dei commenti tra pagine (modificando
urlId). - Le migrazioni costano
2crediti aggiuntivi poiché le pagine vengono precalcolate e questo è intensivo per la CPU.
- Questo può rendere "live" la migrazione dei commenti tra pagine (modificando
- A differenza dell'API di creazione, questa API NON creerà automaticamente oggetti utente nel nostro sistema se viene fornita un'email.
- I commenti aggiornati tramite questa API possono comunque essere controllati per spam, se desiderato.
- Configurazioni come la lunghezza massima del commento, se configurate tramite la pagina admin Customization Rule, si applicheranno qui.
- Per consentire agli utenti di aggiornare il testo del loro commento, puoi semplicemente specificare
commentnel corpo della richiesta. Genereremo il relativocommentHTML.- Se definisci sia
commentchecommentHTMLnon genereremo automaticamente l'HTML. - Se l'utente aggiunge menzioni o hashtag nel nuovo testo, verranno comunque elaborati come nell'API
POST.
- Se definisci sia
- Quando si aggiorna
commenterEmailsu un commento, è consigliabile specificare ancheuserId. Altrimenti, devi assicurarti che l'utente con questa email appartenga al tuo tenant, altrimenti la richiesta fallirà. - Se il commento target è bloccato (
isLocked: true), la richiesta viene rifiutata concode: 'locked'. Sblocca prima il commento, aggiornalo, poi richiudilo se desiderato.



DELETE /api/v1/comments/:id 
Questo endpoint API consente di eliminare un commento.
Note:
- Questa API può aggiornare il comment widget "live" se desiderato (questo aumenta
creditsCostda1a2). - Questa API eliminerà tutti i commenti figli.
- Se il commento target è bloccato (
isLocked: true), la richiesta viene rifiutata concode: 'locked'. Sbloccare prima il commento, poi eliminarlo.



POST /api/v1/comments/:id/flag 
Questo endpoint API fornisce la possibilità di segnalare (flaggare) un commento per un utente specifico.
Note:
- Questa chiamata deve sempre essere effettuata nel contesto di un utente. L'utente può essere un Utente FastComments.com, un Utente SSO o un Utente Tenant.
- Se è impostata una soglia di flag-per-nascondere, il commento verrà nascosto automaticamente in tempo reale dopo essere stato segnalato il numero definito di volte.
- Dopo che è stato automaticamente disapprovato (nascosto), il commento può essere riapprovato solo da un amministratore o un moderatore. La rimozione della segnalazione non riapproverà il commento.

Per la segnalazione anonima, dobbiamo specificare un anonUserId. Questo può essere un ID che rappresenta la sessione anonima, oppure un UUID casuale.
Questo ci permette di supportare la segnalazione e la rimozione della segnalazione dei commenti anche se un utente non ha effettuato l'accesso. In questo modo, il commento può essere
contrassegnato come segnalato quando i commenti vengono recuperati con lo stesso anonUserId.



POST /api/v1/comments/:id/un-flag 
Questo endpoint API fornisce la possibilità di rimuovere la segnalazione di un commento per uno specifico utente.
Note:
- Questa chiamata deve sempre essere effettuata nel contesto di un utente. L'utente può essere un FastComments.com User, SSO User, o Tenant User.
- Dopo che un commento è stato automaticamente non approvato (nascosto) - il commento può essere ri-approvato solo da un amministratore o moderatore. La rimozione della segnalazione (un-flag) non ri-approverà il commento.

Per la segnalazione anonima, dobbiamo specificare un anonUserId. Questo può essere un ID che rappresenta la sessione anonima, o un UUID casuale.



POST /api/v1/comments/:id/block 
Questo endpoint API consente di bloccare l'utente che ha scritto un determinato commento. Supporta il blocco per commenti scritti da FastComments.com Users, SSO Users, and Tenant Users.
Supporta un parametro nel body commentIdsToCheck per verificare se altri commenti potenzialmente visibili nel client debbano essere bloccati/sbloccati dopo l'esecuzione di questa azione.
Notes:
- Questa chiamata deve sempre essere effettuata nel contesto di un utente. L'utente può essere un FastComments.com User, SSO User, o Tenant User.
- Il
userIdnella richiesta è l'utente che sta eseguendo il blocco. Per esempio:User Avuole bloccareUser B. PassauserId=User Ae l'id del commento cheUser Bha scritto. - Commenti completamente anonimi (no user id, no email) non possono essere bloccati e verrà restituito un errore.

Per il blocco anonimo, dobbiamo specificare un anonUserId. Questo può essere un ID che rappresenta la sessione anonima, o un UUID casuale.
Questo ci permette di supportare il blocco dei commenti anche se un utente non è autenticato recuperando i commenti con lo stesso anonUserId.



POST /api/v1/comments/:id/un-block 
Questo endpoint API fornisce la possibilità di sbloccare un utente che ha scritto un determinato commento. Supporta lo sblocco di commenti scritti da FastComments.com Users, SSO Users, e Tenant Users.
Supporta un parametro body commentIdsToCheck per verificare se altri commenti potenzialmente visibili sul client dovrebbero essere bloccati/sbloccati dopo che questa azione è stata eseguita.
Note:
- Questa chiamata deve essere sempre effettuata nel contesto di un utente. L'utente può essere un FastComments.com User, SSO User, o Tenant User.
- Il
userIdnella richiesta è l'utente che sta effettuando lo sblocco. Per esempio:User Avuole sbloccareUser B. PassauserId=User Ae l'id del commento cheUser Bha scritto. - I commenti completamente anonimi (nessun user id, nessuna email) non possono essere bloccati e verrà restituito un errore.




Struttura modello email 
Un oggetto EmailTemplate rappresenta la configurazione per un modello di posta elettronica personalizzato, per un tenant.
Il sistema selezionerà il modello di posta elettronica da utilizzare tramite:
- Il suo identificatore di tipo, che chiamiamo
emailTemplateId. Sono costanti. - The
domain. Cercheremo prima di trovare un template per il dominio a cui è legato l'oggetto correlato (come unComment), e se non viene trovata una corrispondenza proveremo a trovare un template in cui domain è null o*.
La struttura per l'oggetto EmailTemplate è la seguente:

Note
- Puoi ottenere i valori validi di
emailTemplateIddall'endpoint/definitions. - L'endpoint
/definitionsinclude anche le traduzioni predefinite e i dati di test. - I template non verranno salvati se la struttura o i dati di test non sono validi.
GET /api/v1/email-templates/:id 
I singoli EmailTemplate possono essere recuperati tramite il loro corrispondente id (NON emailTemplateId).



GET /api/v1/email-templates 
Questa API utilizza la paginazione, fornita dal parametro di query page. Gli EmailTemplates vengono restituiti in pagine da 100, ordinati per createdAt e poi per id.



PATCH /api/v1/email-templates/:id 
Questo endpoint API fornisce la possibilità di aggiornare un template email specificando solo l'id e gli attributi da aggiornare.
Nota che tutte le stesse validazioni per la creazione di un template si applicano anche qui, per esempio:
- Il template deve poter essere renderizzato. Questo viene controllato ad ogni aggiornamento.
- Non puoi avere template duplicati per lo stesso dominio (altrimenti uno verrebbe ignorato silenziosamente).



POST /api/v1/email-templates 
Questo endpoint API consente di creare modelli email.
Note:
- Non puoi avere più template con lo stesso
emailTemplateIdnello stesso dominio. - Tuttavia puoi avere un template wildcard (
domain=*) e un template specifico per dominio per lo stessoemailTemplateId. - Specificare
domainè rilevante solo se hai domini diversi, o vuoi usare template specifici per i test (domainimpostato sulocalhostecc). - Se specifichi
domaindeve corrispondere a unaDomainConfig. In caso di errore viene fornito un elenco di domini validi. - La sintassi del template è EJS e viene renderizzata con un timeout di 500ms. Il P99 per il rendering è <5ms, quindi se raggiungi i 500ms qualcosa non va.
- Il tuo template deve essere renderizzato con i
testDataforniti per poter essere salvato. Gli errori di rendering vengono aggregati e riportati nella dashboard (presto disponibile via API).
I dati minimi richiesti per aggiungere un template sono i seguenti:

Potresti voler avere template per sito, nel qual caso definisci domain:



POST /api/v1/email-templates/render 
Questo endpoint API fornisce la possibilità di visualizzare in anteprima i modelli di email.



DELETE /api/v1/email-templates/:id 
Questa route consente la rimozione di un singolo EmailTemplate tramite id.



Struttura FeedPost 
Un oggetto FeedPost rappresenta un post in un feed di FastComments. Un feed è un flusso di post con i propri thread di commenti, renderizzato dal widget Feed. Ogni post ha un autore, contenuto ricco opzionale, media e link, e può essere taggato in modo che un feed possa essere filtrato.
La struttura dell'oggetto FeedPost è la seguente:

Note:
- Alcuni di questi campi sono contrassegnati come
READONLY- vengono restituiti dall'API ma non possono essere impostati. - I commenti su un post sono commenti regolari il cui
urlIdèpost:seguito dall'_iddel post. Usa quel valore con l'API Commenti per leggere o creare commenti su un post.
GET /api/v1/feed-posts 
Recupera i post in un feed, dal più recente. La paginazione è basata su cursore: passa l'_id dell'ultimo post ricevuto come afterId per ottenere la pagina successiva.
Costa un credito per ogni dieci post restituiti, con un minimo di un credito.



POST /api/v1/feed-posts 
Questo endpoint crea un singolo FeedPost. Ogni post ha un autore, quindi fromUserId è obbligatorio e deve essere l'ID di un utente FastComments o SSO esistente nell'account.



PATCH /api/v1/feed-posts/:id 
Questo endpoint aggiorna un singolo FeedPost. Invia solo i campi che desideri modificare.



Struttura HashTag 
Un oggetto HashTag rappresenta un tag che può essere lasciato da un utente. Gli HashTag possono essere usati per collegarsi a un contenuto esterno o per
collegare insieme commenti correlati.
La struttura dell'oggetto HashTag è la seguente:

Note:
- In alcuni endpoint API vedrai che l'hashtag viene usato nell'URL. Ricordati di codificare i valori per URI. Per esempio,
#dovrebbe invece essere rappresentato come%23. - Alcuni di questi campi sono contrassegnati come
READONLY- vengono restituiti dall'API ma non possono essere impostati.
GET /api/v1/hash-tags 
Questa API utilizza la paginazione, fornita dal parametro di query page. Gli HashTag vengono restituiti in pagine di 100, ordinati per tag.



PATCH /api/v1/hash-tags/:tag 
Questa route consente di aggiornare un singolo HashTag.



POST /api/v1/hash-tags 
Questa route consente di aggiungere un singolo HashTag.



POST /api/v1/hash-tags/bulk 
Questa route consente di aggiungere fino a 100 oggetti HashTag alla volta.



DELETE /api/v1/hash-tags/:tag 
Questo endpoint permette la rimozione di un HashTag identificato dal tag fornito.
Nota che, a meno che la creazione automatica dei HashTag non sia disabilitata, gli hashtag possono essere ricreati da un utente che fornisce l'hashtag nel commento.



GET /api/v1/me 
Descrive le credenziali che effettuano la richiesta: il tenant a cui appartengono e, per i token di accesso OAuth, l' utente che ha autorizzato l'applicazione. Le integrazioni lo usano per testare una connessione e etichettarla.
Con una chiave API la risposta identifica solo il tenant. Con un token bearer OAuth trasporta anche l' utente autorizzatore e gli scope concessi.


Struttura moderatore 
Un oggetto Moderator rappresenta la configurazione per un moderatore.
Ci sono tre tipi di moderatori:
- Utenti amministratori che hanno il flag
isCommentModeratorAdmin. - Utenti SSO con il flag
isCommentModeratorAdmin. - Commentatori normali, o utenti FastComments.com, che vengono invitati come Moderatori.
La struttura Moderator viene usata per rappresentare lo stato di moderazione nel caso d'uso 3.
Se vuoi invitare un utente a diventare moderatore tramite l'API, usa l'API Moderator creando un Moderator e inviting them.
Se l'utente non ha un account FastComments.com, l'email di invito li aiuterà a configurarsi. Se hanno già un account, verrà loro concesso l'accesso di moderazione al tuo tenant e il userId dell'oggetto Moderator verrà aggiornato per puntare al loro utente. Non avrai accesso API al loro utente, poiché in questo caso l'account appartiene a loro ed è gestito da FastComments.com.
Se necessiti della gestione completa dell'account dell'utente, raccomandiamo di usare SSO oppure aggiungerli come Utente del tenant e poi aggiungere un oggetto Moderator per tracciare le loro statistiche.
La struttura Moderator può essere usata come meccanismo di tracciamento delle statistiche per i casi d'uso 1 e 2. Dopo aver creato l'utente, aggiungi un oggetto Moderator con il loro userId definito e le loro statistiche verranno tracciate nella Pagina Moderatori dei Commenti.
La struttura dell'oggetto Moderator è la seguente:

GET /api/v1/moderators/:id 
Questa route restituisce un singolo moderatore in base al suo id.



GET /api/v1/moderators 
Questa API utilizza la paginazione, fornita dal parametro di query skip. I moderatori vengono restituiti in pagine da 100, ordinati per createdAt e id.
Il costo si basa sul numero di moderatori restituiti, con un costo di 1 credit per 10 moderatori restituiti.



PATCH /api/v1/moderators/:id 
Questo endpoint API fornisce la possibilità di aggiornare un Moderator tramite id.
L'aggiornamento di un Moderator ha le seguenti restrizioni:
- I seguenti valori non possono essere forniti durante l'aggiornamento di un
Moderator:acceptedInvitemarkReviewedCountdeletedCountmarkedSpamCountapprovedCounteditedCountbannedCountverificationIdcreatedAt
- Quando viene specificato un
userId, l'utente deve esistere. - Quando viene specificato un
userId, questo deve appartenere allo stessotenantIdspecificato nei parametri di query. - Due moderatori nello stesso tenant non possono essere aggiunti con la stessa
email. - Non è possibile modificare il
tenantIdassociato a unModerator.



POST /api/v1/moderators 
Questa route fornisce la possibilità di aggiungere un singolo Moderator.
La creazione di un Moderator presenta le seguenti restrizioni:
- Devono sempre essere forniti
nameeemail.userIdè opzionale. - I seguenti valori non possono essere forniti durante la creazione di un
Moderator:acceptedInvitemarkReviewedCountdeletedCountmarkedSpamCountapprovedCounteditedCountbannedCountverificationIdcreatedAt
- Quando è specificato un
userId, l'utente deve esistere. - Quando è specificato un
userId, questo deve appartenere allo stessotenantIdspecificato nei parametri di query. - Due moderatori nello stesso tenant non possono essere aggiunti con la stessa
email.
Possiamo creare un Moderator per un utente di cui conosciamo solo l'email:

Oppure possiamo creare un Moderator per un utente che appartiene al nostro tenant, per monitorare le sue statistiche di moderazione:



POST /api/v1/moderators/:id/send-invite 
Questa route permette di invitare un singolo Moderator.
Le seguenti restrizioni si applicano per inviare un'email di invito a un Moderator:
- Il
Moderatordeve già esistere. - Il
fromNamenon può superare i100 characters.
Note:
- Se esiste già un utente con l'email fornita, gli verrà inviato un invito a moderare i commenti del tuo tenant.
- Se un utente con l'email fornita non esiste, il link d'invito lo guiderà nella creazione del proprio account.
- L'invito scade dopo
30 days.
Possiamo creare un Moderator per un utente di cui conosciamo solo l'email:

Questo invierà un'email come Bob at TenantName is inviting you to be a moderator...


DELETE /api/v1/moderators/:id 
Questa route consente la rimozione di un Moderator tramite id.



Struttura conteggio notifiche 
Un oggetto NotificationCount rappresenta il conteggio delle notifiche non lette e i metadati per un utente.
Se non ci sono notifiche non lette, non esisterà alcun NotificationCount per l'utente.
Gli oggetti NotificationCount vengono creati automaticamente e non possono essere creati tramite l'API. Scadono inoltre dopo un anno.
Puoi azzerare il conteggio delle notifiche non lette di un utente eliminando il relativo NotificationCount.
La struttura dell'oggetto NotificationCount è la seguente:

GET /api/v1/notification-count/:user_id 
Questa route restituisce un singolo NotificationCount dato l'id utente. Con SSO, l'id utente è nel formato <tenant id>:<user id>.
Se non ci sono notifiche non lette, non ci sarà un NotificationCount - quindi otterrai un 404.
Questo è diverso da notifications/count in quanto è molto più veloce, ma non permette il filtraggio.



DELETE /api/v1/notification-count/:user_id 
Questa route elimina un singolo NotificationCount per ID utente. Con SSO, l'ID utente ha il formato <tenant id>:<user id>.
Questo azzererà il conteggio delle notifiche non lette dell'utente (la campanella rossa nel widget dei commenti svanirà e il conteggio scomparirà).



Struttura notifica 
Un oggetto Notification rappresenta una notifica per un utente.
Gli oggetti Notification vengono creati automaticamente e non possono essere creati tramite l'API. Scadono inoltre dopo un anno.
Le notifiche non possono essere eliminate. Possono comunque essere aggiornate impostando viewed su false, e puoi interrogarle tramite viewed.
Un utente può anche rinunciare alle notifiche per un commento specifico impostando optedOut nella notifica su true. Puoi riattivare le notifiche impostandolo su false.
Esistono diversi tipi di notifiche - controlla relatedObjectType e type.
I metodi con cui vengono create le notifiche sono piuttosto flessibili e possono essere attivati da molti scenari (vedi NotificationType).
Al momento, l'esistenza di una Notification non implica necessariamente che una email sia stata o debba essere inviata. Piuttosto, le notifiche
sono utilizzate per il feed delle notifiche e le integrazioni correlate.
La struttura dell'oggetto Notification è la seguente:

GET /api/v1/notifications 
Questa route restituisce fino a 30 oggetti Notification ordinati per createdAt, dal più recente al più vecchio.
Puoi filtrare per userId. Con SSO, l'id utente è nel formato <tenant id>:<user id>.



GET /api/v1/notifications/count 
Questa route restituisce un oggetto contenente il numero di notifiche sotto il parametro count.
È più lenta di /notification-count/ e costa il doppio in crediti, ma permette di filtrare su più dimensioni.
Puoi filtrare con gli stessi parametri dell'endpoint /notifications come userId. Con SSO, l'id utente è nel formato <tenant id>:<user id>.




PATCH /api/v1/notifications/:id 
Questo endpoint API consente di aggiornare una Notification tramite id.
L'aggiornamento di una Notification presenta le seguenti restrizioni:
- È possibile aggiornare solo i seguenti campi:
viewedoptedOut



API pubblico di reazioni alla pagina 
I Page Reacts permettono ai tuoi utenti di mettere "mi piace" a una pagina, o di reagire ad essa con il tuo set di immagini di reazione. Il widget Page Reacts e il widget Floating Likes sono costruiti su questi endpoint, e puoi chiamarli tu stesso per creare il tuo pulsante "mi piace".
A differenza del resto di questa guida, gli endpoint Page Reacts sono pubblici. Vengono chiamati dai browser dei tuoi utenti, non richiedono una chiave API e non consumano crediti API. Ogni reazione appartiene all'utente che effettua la richiesta, quindi un utente può solo aggiungere o rimuovere le proprie.
Esistono due set di endpoint:
/page-reacts/v1/likes/:tenantId- un singolo "mi piace" per utente per pagina. Usali per un pulsante "mi piace"./page-reacts/v2/:tenantId- più reazioni per pagina, ognuna identificata da un breveidche scegli tu (ad esempioheartolaugh).
Entrambi sono disponibili anche nei nostri SDK come parte di PublicApi, ad esempio getV1PageLikes, createV1PageReact e deleteV1PageReact nello SDK JavaScript.
Mostrare Chi Ha Reagito
Passa includeUserInfo=public agli endpoint GET per ottenere anche gli utenti che hanno messo "mi piace" o reagito, con i loro nomi utente e avatar, i più recenti per primi. Gli utenti che hanno reso privata l'attività del proprio profilo sono esclusi, così come gli utenti anonimi. Vengono restituite fino a 100 reazioni.
Gli utenti SSO vengono creati con attività del profilo privata a meno che il tuo payload SSO non imposti isProfileActivityPrivate su false, quindi impostalo per gli utenti che vuoi far comparire in questi elenchi.
Sulle pagine che richiedono SSO, solo gli utenti SSO che possono visualizzare la pagina possono vedere chi ha reagito. Gli altri ricevono un 403 con il codice sso-required o page-forbidden.
Dal tuo server, GET /api/v1/pages/likes e GET /api/v1/pages/reacts restituiscono gli stessi elenchi con una chiave API, e accettano anche includeUserInfo=include-private per includere gli utenti con profili privati.
Identificare l'Utente
Le reazioni sono legate all'utente che effettua la richiesta:
- Utenti SSO: passa il parametro di query
sso, impostato sul JSON URI encoded dello stesso oggetto SSO che dai al widget dei commenti. Vedi SSO. - Utenti anonimi: quando non c'è un parametro
ssoe nessun login FastComments, il server assegna al browser un id anonimo memorizzato nel cookie di sessione FastComments. Invia le richieste concredentials: 'include'così il cookie viene mantenuto tra le richieste. I browser che bloccano i cookie di terze parti non manterranno l'id anonimo, quindi usa SSO quando ogni utente deve essere riconosciuto in modo affidabile.
Il urlId
urlId identifica la pagina, allo stesso modo in cui lo fa per i commenti. Usa lo stesso urlId che dai al widget dei commenti così che i "mi piace" e i commenti siano conteggiati sulla stessa pagina. Ricorda di fare l'URI encoding.

GET /page-reacts/v1/likes/:tenantId 
Restituisce il numero di like su una pagina e se l'utente corrente ha messo like. Le pagine che non esistono ancora restituiscono un likeCount di 0.
Passa includeUserInfo=public per ottenere anche gli utenti che hanno messo like alla pagina, dal più recente al più vecchio. Gli utenti con attività di profilo privata e gli utenti anonimi sono esclusi, e vengono cercati fino a 100 like. Solo public è accettato qui; include-private restituisce un 422 ed è disponibile da GET /api/v1/pages/likes con una chiave API. Sulle pagine che richiedono SSO, includeUserInfo restituisce un 403 per gli utenti che non possono visualizzare la pagina.



POST /page-reacts/v1/likes/:tenantId 
Metti mi piace a una pagina come utente corrente. Ogni utente può mettere mi piace a una pagina una sola volta: mettere nuovamente mi piace ha successo con il codice already-liked e non cambia il conteggio.
La pagina viene creata se non esiste ancora. Passa title per impostare o aggiornare il titolo della pagina.



DELETE /page-reacts/v1/likes/:tenantId 
Rimuove il like dell'utente corrente da una pagina. Se l'utente non ha messo like alla pagina, la richiesta ha successo con il codice not-liked e non modifica il conteggio.



GET /page-reacts/v2/:tenantId 
Restituisce il conteggio per ogni reazione su una pagina e le reazioni che l'utente corrente ha aggiunto.
Passa includeUserInfo=public per ottenere anche gli utenti che hanno reagito, come una voce per reazione con il suo ID, dalla più recente alla più vecchia. Gli utenti con attività di profilo privata e gli utenti anonimi sono esclusi, e vengono cercate fino a 100 reazioni. Solo public è accettato qui; include-private restituisce un 422 ed è disponibile da GET /api/v1/pages/reacts con una chiave API. Sulle pagine che richiedono SSO, includeUserInfo restituisce un 403 per gli utenti che non possono visualizzare la pagina.



GET /page-reacts/v2/:tenantId/list 
Restituisce i nomi degli utenti che hanno aggiunto una reazione a una pagina, ordinati alfabeticamente. Vengono cercate fino a 100 reazioni, e gli utenti anonimi e gli utenti con attività del profilo privato non sono inclusi. Sulle pagine che richiedono SSO, gli utenti che non possono visualizzare la pagina ricevono un 403 con il codice sso-required o page-forbidden.
Per ottenere anche avatar e ID utente, usa GET /page-reacts/v2/:tenantId con includeUserInfo=public.



POST /page-reacts/v2/:tenantId 
Aggiunge una reazione a una pagina come utente corrente. Un utente può aggiungere ogni ID di reazione una sola volta: aggiungerlo di nuovo ha esito positivo con il codice already-reacted e non modifica il conteggio. Un utente può aggiungere diverse reazioni differenti alla stessa pagina.
Gli ID di reazione sono scelti da te e possono contenere fino a 36 caratteri. La pagina viene creata se non esiste ancora. Passa title per impostare o aggiornare il titolo della pagina.



DELETE /page-reacts/v2/:tenantId 
Rimuove una delle reazioni dell'utente corrente da una pagina. Se l'utente non ha aggiunto quella reazione, la richiesta ha successo con il codice no-react e non modifica il conteggio.



Struttura pagina 
Un oggetto Page rappresenta la pagina a cui possono appartenere molti commenti. Questa relazione è definita da
urlId.
Un oggetto Page memorizza informazioni come il titolo della pagina, il numero di commenti e urlId.
La struttura per l'oggetto Page è la seguente:

GET /api/v1/pages 
Al momento puoi recuperare solo tutte le pagine (o una singola pagina tramite /by-url-id) associate al tuo account. Se desideri ricerche più dettagliate, contattaci.



Suggerimento utile
L'API Comment richiede un urlId. Puoi chiamare prima l'API Pages, per vedere quali valori urlId sono disponibili per te
e come appaiono.
GET /api/v1/pages/by-url-id 
Le singole pagine possono essere recuperate tramite il corrispondente urlId. Questo può essere utile per cercare i titoli delle pagine o il numero di commenti.



Suggerimento utile
Ricorda di codificare in URI valori come il urlId.
GET /api/v1/pages/likes 
Restituisce il numero di like su una pagina e, facoltativamente, gli utenti che l'hanno messa like, dal più recente al più vecchio. Questa è la versione server‑side di GET /page-reacts/v1/likes/:tenantId.
includeUserInfo controlla quali utenti vengono restituiti:
publicesclude gli utenti che hanno impostato la loro attività del profilo come privata.include-privateli include. Usalo solo quando l'elenco non viene mostrato al pubblico.
Gli utenti anonimi non sono mai inclusi e vengono cercati fino a 100 like. Le pagine che non esistono restituiscono un likeCount di 0 e una lista users vuota.



Suggerimento utile
Ricorda di codificare in URI i valori come urlId.
GET /api/v1/pages/reacts 
Restituisce il conteggio di ogni reazione su una pagina e, facoltativamente, gli utenti che hanno reagito, con una voce per ogni reazione con il relativo id di reazione, dalla più recente. Questa è la versione server-side di GET /page-reacts/v2/:tenantId.
includeUserInfo controlla quali utenti vengono restituiti:
publicesclude gli utenti che hanno reso privata l'attività del proprio profilo.include-privateli include. Usare questa opzione solo quando l'elenco non viene mostrato al pubblico.
Gli utenti anonimi non vengono mai inclusi e vengono cercate fino a 100 reazioni. Le pagine che non esistono non restituiscono alcun counts e un elenco users vuoto.



Suggerimento utile
Ricordarsi di eseguire l'URI Encoding di valori come urlId.
PATCH /api/v1/pages/:id 
Questa route fornisce la possibilità di aggiornare una singola Page. I commenti corrispondenti verranno aggiornati.



Nota
Alcuni parametri nell'oggetto Page vengono aggiornati automaticamente. Questi sono i conteggi e gli attributi del titolo. I conteggi non possono essere aggiornati tramite l'API poiché sono valori calcolati. Il title della pagina può essere impostato tramite l'API, ma verrebbe sovrascritto se il widget dei commenti viene utilizzato su una pagina con lo stesso urlId e un titolo di pagina diverso.
POST /api/v1/pages 
Questo endpoint API permette di creare pagine.
Un caso d'uso comune è il controllo degli accessi.
Note:
- Se hai commentato in un thread di commenti, o hai chiamato l'API per creare un
Comment, hai già creato un oggettoPage! Puoi provare a recuperarlo tramite la routePage/by-url-id, passando lo stessourlIdfornito al widget dei commenti. - La struttura
Pagecontiene alcuni valori calcolati. Attualmente, questi sonocommentCounterootCommentCount. Vengono popolati automaticamente e non possono essere impostati tramite l'API. Tentare di farlo farà sì che l'API restituisca un errore.



DELETE /api/v1/pages/:id 
Questa route consente la rimozione di una singola pagina tramite id.
Nota che interagire con il widget dei commenti per una pagina con lo stesso urlId ricreerà semplicemente la Page senza soluzione di continuità.



POST /api/v1/pages/migrations 
Questo endpoint sposta commenti e pagine da un urlId o dominio a un altro, allo stesso modo dello Domain Migration tool nella dashboard. È possibile inviare fino a 100 migrazioni per richiesta. Vengono eseguite nell'ordine fornito, quindi a a b seguito da b a c funziona.
Ogni migrazione ha un type:
urlIdsposta la pagina il cuiurlIdè esattamentefrom.post-1non corrisponde apost-10.domaintrova/sostituiscefromall'interno di ogniurlIdeurl, e aggiorna ildomaindi ogni commento. Entrambi i valori devono essere un dominio, ad esempioold.example.com.
Commenti, la pagina, le reazioni alla pagina, i voti, le notifiche e le sottoscrizioni vengono tutti spostati. Se una pagina esiste già su to, le due pagine vengono unite.
La migrazione viene eseguita come un batch job. La risposta contiene un batchJobId. Esegui il polling di GET /api/v1/batch-jobs/:id per seguirne l'avanzamento. Una volta completato il job, contiene un risultato per migrazione e un undoId che puoi passare a POST /api/v1/pages/migrations/:undoId/undo entro 90 giorni.
La richiesta viene convalidata prima che venga accodata. Se una migrazione è invalida, l'intera richiesta fallisce con un 422 e nulla viene eseguito.
Accodare una migrazione non costa nulla. Quando il job termina, costa 1 credito per 1000 commenti migrati, con un minimo di 1.



Note
- I job per un tenant vengono eseguiti uno alla volta, dal più vecchio al più recente. Una seconda migrazione attende che la prima termini.
PATCH /api/v1/pages/:idcon un nuovourlIdcambia solo la pagina, non i suoi commenti. Usa questo endpoint per spostare i commenti di una pagina.
POST /api/v1/pages/migrations/:undoId/undo 
Questa route annulla ogni migrazione da un lavoro POST /api/v1/pages/migrations. Ottieni l'undoId dal lavoro di migrazione completato con GET /api/v1/batch-jobs/:id. Un undoId può essere usato per 90 giorni, e solo una volta.
L'annullamento viene eseguito come un batch job, allo stesso modo della migrazione, e la risposta contiene il suo batchJobId. Una volta completato il lavoro, il suo pageMigrationUndoResult riporta:
restored: record riportati ai loro valori precedenti alla migrazione.skipped: record lasciati invariati perché sono cambiati dopo la migrazione, o non esistono più. Una modifica successiva non viene mai sovrascritta.notRestorable: record che la migrazione ha eliminato durante l'unione di due pagine, o rimuovendo reazioni duplicate di pagina. Questi non possono essere ripristinati.
Le migrazioni vengono annullate dall'ultima alla prima, quindi una catena come a a b seguita da b a c viene srotolata indietro fino a a. Un lavoro di migrazione che è fallito a metà può comunque essere annullato, il che inverte le modifiche apportate prima del fallimento.
Mettere in coda un annullamento non costa nulla. Quando il lavoro termina, costa 1 credito per 1000 record ripristinati, con un minimo di 1.



Struttura sondaggio 
Un Poll è collegato a un commento, anziché essere un oggetto a sé stante. Viene creato insieme al commento
(vedi POST /api/v1/comments), oppure aggiunto successivamente a un commento esistente con PUT /api/v1/polls/:commentId.
I conteggi dei voti sono conservati direttamente sul sondaggio, quindi la lettura di un sondaggio fornisce i risultati
senza dover sommare nulla. I singoli voti alla base di quei conteggi sono oggetti PollVote.
Ogni opzione ha un id generato quando il sondaggio viene creato. Quell'id è ciò che usi per esprimere un voto,
per rinominare un'opzione e per mantenere un'opzione (e i suoi voti) quando esegui un PUT del sondaggio con opzioni
aggiunte o rimosse. È l'unico modo sicuro per riferirsi a un'opzione - mai alla sua posizione nell'elenco.

Limiti
- Una domanda è obbligatoria e ha al massimo 200 caratteri.
- Un sondaggio ha tra 2 e 10 opzioni.
- L'etichetta di un'opzione è obbligatoria, ha al massimo 100 caratteri e deve essere unica all'interno del sondaggio (ignorando maiuscole/minuscole).
closesAtdeve essere nel futuro quando il sondaggio viene creato. Per chiudere immediatamente un sondaggio, esegui unPATCHcon una data nel passato.
Impostazioni del Sito
I sondaggi rispettano la configurazione del tuo sito, che puoi modificare sotto Customize Widget:
- I sondaggi devono essere abilitati prima che sia possibile crearne uno, altrimenti l'API risponde con
polls-disabled. - Il voto può essere limitato agli utenti registrati, nel qual caso un voto inviato con solo un
anonUserIdviene rifiutato conpoll-login-required.
GET /api/v1/polls/:commentId 
Legge il sondaggio allegato a un commento, con i conteggi dei voti attuali.
I sondaggi sono restituiti anche sul commento stesso dalle API dei commenti, quindi usa questo quando vuoi solo i risultati e non l'intero commento.



Un commento che non ha sondaggio, un commento che è stato eliminato e un ID commento che non esiste rispondono
allo stesso modo, con poll-not-found.
PUT /api/v1/polls/:commentId 
Collega un sondaggio a un commento esistente, oppure imposta lo stato completo del sondaggio che ha già.
Il body è il sondaggio completo, e le opzioni che invii diventano le opzioni del sondaggio, in quell'ordine. Ogni opzione
viene confrontata tramite il suo id:
- Un'opzione inviata con l'
iddi un'opzione esistente mantiene quell'opzione e i suoi voti. La sua etichetta e la sua posizione vengono aggiornate con quanto inviato. - Un'opzione inviata senza
idviene aggiunta, senza voti. - Un'opzione esistente che ometti viene rimossa, insieme ai voti espressi su di essa.
totalVotesdiminuisce della stessa quantità.
Quindi, per aggiungere un'opzione, invia le opzioni correnti con i loro id più quella nuova senza id. Per rimuoverne una,
invia l'elenco senza di essa. Gli id delle opzioni si trovano nel sondaggio restituito da GET /api/v1/polls/:commentId.
Non inviare alcun id sostituisce ogni opzione ed elimina tutti i voti già espressi sul sondaggio. Se il sondaggio ha
voti, questo richiede replaceVotes=true, e senza di essa l'API risponde con replace-votes-required.
Anche gli altri campi vengono sostituiti: omettere closesAt, privacy o requireVoteToSeeResults li ripristina al
loro valore predefinito. Per modificare un singolo campo lasciando invariato il resto, usa PATCH /api/v1/polls/:commentId.



Altre note
- Un
idche non è presente nel sondaggio, o lo stessoidfornito due volte, causa un errore conpoll-invalid. Un commento senza sondaggio non ha ancora id di opzioni, quindi ogni opzione inviata ad esso deve omettereid. - La privacy del sondaggio può essere ristretta ma non ampliata una volta che ha voti.
- Questa API rispetta le impostazioni del tuo sito. Se i sondaggi non sono abilitati per il sito o la pagina, fallisce con
polls-disabled. - Un commento bloccato non può avere il suo sondaggio modificato, e fallisce con
locked. - I widget collegati vengono aggiornati in tempo reale, quindi gli spettatori vedono il nuovo sondaggio senza ricaricare.
PATCH /api/v1/polls/:commentId 
Modifica un sondaggio senza alterare i suoi voti. Usa questa operazione per correggere un errore di battitura nella domanda o in un'opzione, per chiudere o riaprire il sondaggio, o per cambiare chi può vedere chi ha votato.
Le opzioni sono identificate dal loro id, e un PATCH rinomina quelle che specifichi. Per aggiungere, rimuovere o riordinare le opzioni, invia l'elenco completo delle opzioni a PUT /api/v1/polls/:commentId: le opzioni che invii con i loro id mantengono anche i loro voti.
Ogni campo è opzionale, ma ne deve essere fornito almeno uno.




Altre Note
- Assegnare un id di opzione che non è presente nel sondaggio fallisce con
poll-invalidinvece di non fare nulla silenziosamente. - Le etichette devono rimanere uniche all'interno del sondaggio, contando anche le opzioni che non stai modificando.
- A differenza della creazione di un sondaggio,
closesAtpuò essere nel passato qui - è così che si chiude un sondaggio immediatamente. - La privacy del sondaggio può essere ridotta ma non ampliata una volta che ha dei voti.
- Un commento bloccato non può avere il suo sondaggio modificato, e fallisce con
locked.
DELETE /api/v1/polls/:commentId 
Rimuove un sondaggio dal suo commento, insieme a tutti i voti espressi su di esso. Il commento stesso rimane intatto.
Eliminare il commento rimuove anche il suo sondaggio e i voti, quindi questo è necessario solo quando si desidera mantenere il commento.



Struttura voto sondaggio 
Un PollVote è la risposta di una persona a un sondaggio. I conteggi mostrati sul sondaggio stesso sono tenuti aggiornati con questi, quindi li servono solo quando vuoi sapere chi ha votato per cosa, piuttosto che i totali.
Un elettore può avere al massimo un voto per sondaggio. Votare di nuovo sposta il voto esistente verso la nuova opzione invece di aggiungerne un secondo, e updatedAt registra quando ciò è avvenuto.
voterId è il userId quando l'elettore era connesso, altrimenti è l'anonUserId.

Privacy
L'impostazione privacy del sondaggio si applica a questa API nello stesso modo in cui si applica nel widget dei commenti:
- Anonymous (il valore predefinito): nessuno può vedere come qualcuno ha votato, quindi i voti non possono essere letti.
GET /api/v1/poll-voteseGET /api/v1/poll-votes/:idrispondono conpoll-anonymous. I conteggi del sondaggio sono ancora disponibili daGET /api/v1/polls/:commentId. - Admins and moderators: la tua chiave API appartiene all'amministratore del tuo sito, quindi può leggere i voti.
- Everyone: i voti possono essere letti.
La privacy del sondaggio può essere ridotta ma non ampliata una volta che ha dei voti.
GET /api/v1/poll-votes 
Elenca i voti individuali dietro i conteggi di un sondaggio, dal più vecchio al più recente. Un credito per ogni 100 voti restituiti.
Un sondaggio appartiene a un commento, quindi i voti vengono letti un sondaggio alla volta e commentId è obbligatorio. Restringi ulteriormente con voterId per verificare come ha votato una persona, o con optionId per elencare tutti coloro che hanno scelto una determinata opzione.
Al massimo vengono restituiti 1000 voti per chiamata. Usa skip per scorrere le pagine successive.
L'impostazione privacy del sondaggio è rispettata: i voti su un sondaggio anonimo non possono essere letti e la richiesta fallisce con poll-anonymous. Consulta la struttura PollVote per i dettagli.



Conteggio dei Voti per Opzione
Non è necessario sommare questi valori per ottenere i risultati – il sondaggio contiene i propri conteggi. Leggi il sondaggio con GET /api/v1/polls/:commentId invece, e utilizza questa API quando hai bisogno di sapere chi ha votato.
Ogni Sondaggio su una Pagina
Non esiste un elenco di voti a livello di pagina. Per fare un report su un'intera pagina, recupera i suoi commenti con GET /api/v1/comments, che restituisce il sondaggio di ogni commento e i relativi conteggi, quindi leggi i voti per i sondaggi di tuo interesse.
GET /api/v1/poll-votes/:id 
Legge un singolo voto del sondaggio per il suo ID.
Un voto su un sondaggio anonimo non può essere letto, e la richiesta fallisce con poll-anonymous. Vedi la struttura PollVote per capire come si applica l'impostazione privacy del sondaggio.



POST /api/v1/poll-votes 
Registra un voto su un sondaggio.
Un elettore può avere al massimo un voto per sondaggio. Richiamare nuovamente questo endpoint per lo stesso elettore sposta il suo voto alla nuova opzione invece di aggiungerne un secondo, e votare per l'opzione che ha già scelto non ha alcun effetto.
La risposta include il sondaggio, così ottieni i conteggi aggiornati senza una seconda richiesta.




Voti Anonimi
Imposta anonUserId invece di userId per registrare un voto per qualcuno che non è connesso. quell'ID non deve corrispondere a un utente da nessuna parte – identifica semplicemente la sessione, così la stessa persona non viene contata due volte.
Il voto anonimo deve essere abilitato per il tuo sito. Se il voto è limitato agli utenti connessi, un voto con solo un anonUserId fallisce con poll-login-required.
I voti anonimi sono anche limitati per frequenza per IP per sondaggio, per impedire a una persona di riempire un sondaggio cancellando la propria sessione. Invia l'ip dell'utente finale in modo che il limite si applichi a lui anziché al tuo server.
Altre Note
- Un
userIddeve corrispondere a un utente che esiste sul tuo sito. I voti per un utente appartenente a un altro sito vengono rifiutati. - Votare su un sondaggio chiuso fallisce con
poll-closed. - Questa API aggiorna i conteggi del sondaggio e li invia in tempo reale ai widget collegati.
DELETE /api/v1/poll-votes/:id 
Revoca un voto. L'opzione su cui è stato espresso restituisce il suo conteggio, e l'elettore è libero di votare nuovamente.



Altre note
- Eliminare lo stesso voto due volte risponde con
not-foundla seconda volta, e i conteggi rimangono invariati. - Se il sondaggio è stato sostituito da quando è stato espresso il voto, il voto viene rimosso ma i conteggi non cambiano, poiché la sostituzione è iniziata da zero.
Struttura evento webhook in sospeso 
Un oggetto PendingWebhookEvent rappresenta un evento webhook in coda che è in attesa di elaborazione.
Gli oggetti PendingWebhookEvent vengono creati automaticamente e non possono essere creati manualmente tramite l'API. Inoltre scadono dopo un anno.
Possono essere eliminati, il che rimuove l'attività dalla coda.
Esistono diversi tipi di evento - controllare eventType (OutboundSyncEventType) e type (OutboundSyncType).
Un caso d'uso comune per questa API è l'implementazione di un monitoraggio personalizzato. Potrebbe essere necessario chiamare periodicamente l'endpoint /count
per interrogare il numero di eventi in sospeso in base ai filtri specificati.
La struttura dell'oggetto PendingWebhookEvent è la seguente:

GET /api/v1/pending-webhook-events 
Questa route restituisce un elenco di eventi webhook in sospeso sotto il parametro pendingWebhookEvents.
Questa API utilizza la paginazione, fornita dal parametro skip. PendingWebhookEvents vengono restituiti in pagine da 100, ordinati per createdAt dal più recente al più vecchio.



GET /api/v1/pending-webhook-events/count 
Questa route restituisce un oggetto contenente il numero di eventi webhook in sospeso sotto il parametro count.
Puoi filtrare con gli stessi parametri dell'endpoint /pending-webhook-events



DELETE /api/v1/pending-webhook-events/:id 
Questa route consente l'eliminazione di un singolo PendingWebhookEvent.
Se devi eliminare più elementi in blocco, chiama l'API GET con paginazione e poi richiama questa API in sequenza.



Struttura utente SSO 
FastComments fornisce una soluzione SSO facile da usare. Aggiornare le informazioni di un utente con l'integrazione basata su HMAC è semplice come far caricare all'utente la pagina con un payload aggiornato.
Tuttavia, può essere desiderabile gestire un utente al di fuori di quel flusso, per migliorare la coerenza della tua applicazione.
La SSO User API fornisce un modo per eseguire operazioni CRUD su oggetti che chiamiamo SSOUsers. Questi oggetti sono diversi dagli Users regolari e vengono mantenuti separati per type safety.
La struttura dell'oggetto SSOUser è la seguente:

Fatturazione degli SSO Users
Gli SSO users vengono fatturati in modo diverso in base ai loro flag di permessi:
- SSO Users regolari: gli utenti senza permessi di amministratore o moderatore vengono fatturati come SSO users regolari
- SSO Admins: gli utenti con i flag
isAccountOwneroisAdminAdminvengono fatturati separatamente come SSO Admins (stessa tariffa degli amministratori regolari del tenant) - SSO Moderators: gli utenti con il flag
isCommentModeratorAdminvengono fatturati separatamente come SSO Moderators (stessa tariffa dei moderatori regolari)
Importante: per prevenire una doppia fatturazione, il sistema deduplica automaticamente gli SSO users rispetto agli utenti e moderatori regolari del tenant tramite l'indirizzo email. Se un SSO user ha la stessa email di un utente o moderatore regolare del tenant, non verrà fatturato due volte.
Access Control
Gli utenti possono essere suddivisi in gruppi. È a questo che serve il campo groupIds, ed è opzionale.
@Mentions
Per impostazione predefinita, gli @mentions utilizzeranno username per cercare altri sso users quando viene digitato il carattere @. Se viene usato displayName, i risultati corrispondenti a username verranno ignorati quando c'è una corrispondenza per displayName, e i risultati della ricerca @mention utilizzeranno displayName.
Sottoscrizioni
Con FastComments, gli utenti possono sottoscrivere una pagina cliccando l'icona a forma di campanella nel widget dei commenti e poi cliccando Subscribe.
Con un utente regolare, inviamo email di notifica in base alle impostazioni di notifica dell'utente.
Con gli SSO Users, separiamo questo comportamento per compatibilità con le versioni precedenti. Gli utenti riceveranno queste email di notifica di sottoscrizione aggiuntive solo se imposti optedInSubscriptionNotifications su true.
Badge
Puoi assegnare badge agli SSO users usando la proprietà badgeConfig. I badge sono indicatori visivi che appaiono accanto al nome di un utente nei commenti.
badgeIds- Un array di ID badge da assegnare all'utente. Questi sono badge globali visibili su tutte le pagine. Devono essere ID badge validi creati nel tuo account FastComments. Limitato a 30 badge.pageBadgeIds- Un array opzionale di ID badge con ambito limitato alla pagina corrente (urlId). Questi badge vengono mostrati solo sulla pagina a cui sono stati assegnati. Pagine diverse possono avere badge di pagina diversi per lo stesso utente.override- Se true, tutti i badge attualmente visualizzati verranno sostituiti con quelli forniti. I badge globali e quelli con ambito di pagina vengono sovrascritti indipendentemente — sovrascrivere i badge globali non influisce sui badge con ambito di pagina, e viceversa. Se false o omesso, i badge forniti verranno aggiunti ai badge esistenti.update- Se true, le proprietà di visualizzazione dei badge verranno aggiornate dalla configurazione del tenant ogni volta che l'utente effettua il login.
GET /api/v1/sso-users 
Questa route restituisce gli utenti SSO in pagine da 100. La paginazione è fornita dal parametro skip. Gli utenti sono ordinati per il loro signUpDate e id.



GET /api/v1/sso-users/by-id/:id 
Questa route restituisce un singolo utente SSO in base al suo id.



GET /api/v1/sso-users/by-email/:email 
Questa route restituisce un singolo utente SSO in base alla sua email.



PATCH /api/v1/sso-users/:id 
Questa route consente di aggiornare un singolo utente SSO.



POST /api/v1/sso-users 
Questa route fornisce la creazione di un singolo utente SSO.
Tentare di creare due utenti con lo stesso ID genererà un errore.

In questo esempio specifichiamo groupIds per il controllo degli accessi, ma è facoltativo.


Nota sull'integrazione
I dati inviati tramite l'API possono essere sovrascritti semplicemente passando un payload HMAC dell'utente SSO diverso. Ad esempio, se imposti un username tramite l'API, ma poi ne fornisci uno diverso tramite il flusso SSO al caricamento della pagina, aggiorneremo automaticamente il loro username.
Non aggiorneremo i parametri dell'utente in questo flusso a meno che non li specifichi esplicitamente o li imposti a null (non undefined).
PUT /api/v1/sso-users/:id 
Questa route consente di aggiornare un singolo utente SSO.

In questo esempio specifichiamo groupIds per il controllo degli accessi, ma questo è opzionale.


DELETE /api/v1/sso-users/:id 
Questa route fornisce la rimozione di un singolo utente SSO tramite il suo id.
Nota che ricaricando il widget dei commenti con un payload per questo utente verrà semplicemente ricreato l'utente in modo trasparente.
La cancellazione dei commenti dell'utente è possibile tramite il parametro di query deleteComments. Nota che se questo è true:
- Tutti i commenti dell'utente saranno cancellati in tempo reale.
- Tutti i commenti child (ora orfani) saranno cancellati o anonimizzati in base alla configurazione della pagina associata a ciascun commento. Per esempio, se la modalità di cancellazione del thread è "anonymize", allora le risposte rimarranno e i commenti dell'utente verranno anonimizzati. Questo si applica solo quando
commentDeleteModeèRemove(il valore predefinito). - Il
creditsCostdiventa2.
Commenti anonimizzati
Puoi conservare i commenti dell'utente ma semplicemente anonimizzarli impostando commentDeleteMode=1.
Se i commenti dell'utente vengono anonimizzati, i seguenti valori vengono impostati a null:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badges
isDeleted e isDeletedUser vengono impostati a true.
Durante il rendering, il widget dei commenti utilizzerà DELETED_USER_PLACEHOLDER (default: "[deleted]") per il nome dell'utente e DELETED_CONTENT_PLACEHOLDER per il commento. Questi possono essere personalizzati tramite l'interfaccia di personalizzazione del widget.
Esempi



Struttura abbonamento 
Un oggetto Subscription rappresenta una sottoscrizione per un utente.
Gli oggetti Subscription vengono creati quando un utente clicca la campanella delle notifiche nel widget dei commenti e seleziona "Iscriviti a questa pagina".
Le sottoscrizioni possono anche essere create via API.
Avere un oggetto Subscription fa sì che vengano generati oggetti Notification e inviate email quando vengono lasciati nuovi commenti nella radice della pagina associata a cui la Subscription si riferisce. L'invio delle email dipende dal tipo di utente. Per gli utenti normali ciò dipende da optedInNotifications. Per gli utenti SSO ciò dipende da optedInSubscriptionNotifications. Nota che alcune applicazioni potrebbero non avere il concetto di una pagina accessibile via web, nel qual caso impostare semplicemente urlId sull'id dell'elemento a cui si sta sottoscrivendo (stesso valore per urlId che si passerebbe al widget dei commenti).
La struttura dell'oggetto Subscription è la seguente:

GET /api/v1/subscriptions/:id 
Questa route restituisce fino a 30 oggetti Subscription ordinati per createdAt, dal più recente.
Puoi filtrare per userId. Con SSO, l'ID utente ha il formato <tenant id>:<user id>.



POST /api/v1/subscriptions 
Questo endpoint API consente di creare una Subscription. Nota che un utente può avere soltanto una subscription per pagina, poiché più di una sarebbe ridondante, e provare
a creare più di una subscription per lo stesso utente sulla stessa pagina genererà un errore.
La creazione di una subscription farà sì che vengano creati oggetti Notification quando viene lasciato un nuovo commento nella root del urlId sottoscritto (quando il parentId del commento è null).



DELETE /api/v1/subscriptions/:id 
Questa route elimina un singolo oggetto Subscription per id.



Struttura utilizzo giornaliero tenant 
Un oggetto TenantDailyUsage rappresenta l'utilizzo per un tenant in un dato giorno. Se non c'è stata attività per un tenant in un determinato giorno, quel giorno non avrà un oggetto TenantDailyUsage.
L'oggetto TenantDailyUsage non è in tempo reale e può essere indietro di alcuni minuti rispetto all'utilizzo effettivo.
La struttura dell'oggetto TenantDailyUsage è la seguente:

GET /api/v1/tenant-daily-usage 
Questa rotta consente di cercare l'utilizzo di un tenant per anno, mese e giorno. È possibile restituire fino a 365 oggetti e il costo è di 1 credito API ogni 10 oggetti.
Gli oggetti della risposta sono ordinati per data di creazione (dal più vecchio al più recente).



Struttura tenant 
Il Tenant definisce un cliente di FastComments.com. Possono essere creati tramite l'API dai tenant con accesso al white labeling. I tenant white-labeled non possono creare altri tenant white-labeled (è consentito un solo livello di annidamento).
La struttura dell'oggetto Tenant è la seguente:

GET /api/v1/tenants/:id 
Questo endpoint restituisce un singolo Tenant per id.



GET /api/v1/tenants 
Questa API restituisce i tenant che sono gestiti dal tuo tenant.
La paginazione è fornita dal parametro di query skip. I tenant vengono restituiti in pagine di 100, ordinate per signUpDate e id.
Il costo è basato sul numero di tenant restituiti, pari a 1 credit per 10 tenant restituiti.

Puoi definire parametri meta sugli oggetti Tenant e interrogare per trovare i tenant corrispondenti. Ad esempio, per la chiave someKey e il valore meta some-value, possiamo
costruire un oggetto JSON con questa coppia chiave/valore e poi codificarlo URI come parametro di query per filtrare:



POST /api/v1/tenants 
Questa route fornisce la possibilità di aggiungere un singolo Tenant.
La creazione di un Tenant ha le seguenti restrizioni:
- Un
nameè obbligatorio. domainConfigurationè obbligatorio.- I seguenti valori non possono essere forniti durante la creazione di un
Tenant:hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmount
- La
signUpDatenon può essere nel futuro. - Il
namenon può essere più lungo di200 characters. - L'
emailnon può essere più lunga di300 characters. - L'
emaildeve essere unica tra tutti i tenant di FastComments.com. - Non puoi creare tenant se il tenant genitore non ha definito un
TenantPackagevalido.- Se il tuo tenant è stato creato tramite FastComments.com, questo non dovrebbe essere un problema.
- Non puoi creare più tenant di quanti definiti da
maxWhiteLabeledTenantsnel tuo pacchetto. - Devi specificare il parametro di query
tenantIdche è l'id del tuoparent tenantcon il white labeling abilitato.
Possiamo creare un Tenant con solo pochi parametri:



PATCH /api/v1/tenants/:id 
Questo endpoint API permette di aggiornare un Tenant tramite il suo id.
L'aggiornamento di un Tenant è soggetto alle seguenti restrizioni:
- I seguenti valori non possono essere aggiornati:
hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmountmanagedByTenantId
- La
signUpDatenon può essere nel futuro. - La
namenon può essere più lunga di200 characters. - La
emailnon può essere più lunga di300 characters. - La
emaildeve essere unica tra tutti i tenant di FastComments.com. - Quando si imposta
billingInfoValidatrue,billingInfodeve essere fornito nella stessa richiesta. - Non è possibile aggiornare il
packageIdassociato al proprio tenant. - Non è possibile aggiornare il
paymentFrequencyassociato al proprio tenant.



DELETE /api/v1/tenants/:id 
Questa route permette la rimozione di un Tenant e di tutti i dati associati (utenti, commenti, ecc.) per id.
Esistono le seguenti restrizioni per la rimozione dei tenant:
- Il tenant deve essere il tuo, o un tenant white-label che gestisci.
- Il parametro di query
suredeve essere impostato sutrue.



Struttura pacchetto tenant 
Il TenantPackage definisce le informazioni sul pacchetto disponibili per un Tenant. Un tenant può avere molti pacchetti disponibili, ma solo
uno in uso in un dato momento.
Un Tenant non può essere utilizzato per alcun prodotto finché il suo packageId non punta a un TenantPackage valido.
Esistono due tipi di oggetti TenantPackage:
- Pacchetti a prezzo fisso - dove
hasFlexPricingè false. - Prezzi flessibili - dove
hasFlexPricingè true.
In entrambi i casi i limiti sono definiti sull'account che utilizza il pacchetto, tuttavia con Flex il tenant viene addebitato un prezzo base più
l'utilizzo effettivo, definito dai parametri flex*.
Un tenant può avere più tenant package e può cambiare il pacchetto da solo dalla Pagina delle informazioni di fatturazione.
Se gestirete voi stessi la fatturazione per i tenant, dovrete comunque definire un pacchetto per ciascun tenant per definire i loro limiti. Impostate semplicemente billingHandledExternally su true nel Tenant e non potranno modificare autonomamente le loro informazioni di fatturazione o il pacchetto attivo.
Non è possibile creare pacchetti con limiti superiori rispetto al tenant padre.
La struttura dell'oggetto TenantPackage è la seguente:

GET /api/v1/tenant-packages/:id 
Questa route restituisce un singolo Tenant Package per ID.



GET /api/v1/tenant-packages 
Questa API utilizza la paginazione, fornita dal parametro di query skip. I TenantPackages vengono restituiti in pagine da 100, ordinati per createdAt e id.
Il costo si basa sul numero di tenant packages restituiti, pari a 1 credit per 10 tenant packages restituiti.



POST /api/v1/tenant-packages 
Questa route consente di aggiungere un singolo TenantPackage.
La creazione di un TenantPackage ha le seguenti restrizioni:
- I seguenti parametri sono obbligatori:
nametenantIdmonthlyCostUSD- Può essere null.yearlyCostUSD- Può essere null.maxMonthlyPageLoadsmaxMonthlyAPICreditsmaxMonthlyCommentsmaxConcurrentUsersmaxTenantUsersmaxSSOUsersmaxModeratorsmaxDomainshasDebrandingforWhoTextfeatureTaglineshasFlexPricing- SehasFlexPricingè true, allora tutti i parametriflex*sono obbligatori.
- Il
namenon può essere più lungo di50 characters. - Ogni elemento
forWhoTextnon può essere più lungo di200 characters. - Ogni elemento
featureTaglinesnon può essere più lungo di100 characters. - Il
TenantPackagedeve essere "smaller" rispetto al tenant padre. Ad esempio, tutti i parametrimax*devono avere valori inferiori rispetto al tenant padre. - Un tenant con white labeling può avere al massimo cinque pacchetti.
- Solo i tenant con accesso al white labeling possono creare un
TenantPackage. - Non puoi aggiungere pacchetti al tuo tenant. :)
Possiamo creare un TenantPackage come segue:



PATCH /api/v1/tenant-packages/:id 
Questo endpoint API fornisce la possibilità di aggiornare un TenantPackage tramite id.
L'aggiornamento di un TenantPackage ha le seguenti restrizioni:
- Se si imposta
hasFlexPricingsu true, allora tutti i parametriflex*sono obbligatori nella stessa richiesta. - Il
namenon può essere più lungo di50 characters. - Ogni elemento
forWhoTextnon può essere più lungo di200 characters. - Ogni elemento
featureTaglinesnon può essere più lungo di100 characters. - Il
TenantPackagedeve essere "più piccolo" del tenant principale. Ad esempio, tutti i parametrimax*devono avere valori inferiori rispetto al tenant principale. - Non è possibile modificare il
tenantIdassociato a unTenantPackage.



DELETE /api/v1/tenant-packages/:id 
Questa route fornisce la rimozione di un TenantPackage per id.
Non puoi rimuovere un TenantPackage che è in uso (il packageId di un tenant punta al pacchetto). Aggiorna prima il Tenant.



Struttura utente tenant 
Il TenantUser definisce un User che è gestito da un tenant specifico. Il loro account è sotto il completo controllo del tenant
a cui sono associati, e il loro account può essere aggiornato o eliminato tramite l'UI o l'API.
Gli utenti del tenant possono essere amministratori con tutti i permessi e accesso al Tenant, oppure possono essere limitati a permessi specifici per
moderare i commenti, accedere alle chiavi API, ecc.
La struttura dell'oggetto TenantUser è la seguente:

GET /api/v1/tenant-users/:id 
Questa route restituisce un singolo TenantUser per id.



GET /api/v1/tenant-users 
Questa API utilizza la paginazione, fornita dal parametro di query skip. TenantUsers vengono restituiti in pagine da 100, ordinati per signUpDate, username e id.
Il costo è basato sul numero di tenant users restituiti, con un costo di 1 credit per 10 tenant users restituiti.



POST /api/v1/tenant-users 
Questa route consente di aggiungere un singolo TenantUser.
La creazione di un TenantUser ha le seguenti restrizioni:
- Un
usernameè obbligatorio. - Una
emailè obbligatoria. - La
signUpDatenon può essere nel futuro. - La
localedeve essere nella lista di Locali supportate. - Il
usernamedeve essere unico su tutto FastComments.com. Se questo è un problema, suggeriamo di usare l'SSO. - La
emaildeve essere unica su tutto FastComments.com. Se questo è un problema, suggeriamo di usare l'SSO. - Non è possibile creare più tenant user di quanti definiti sotto
maxTenantUsersnel tuo pacchetto.
Possiamo creare un TenantUser come segue



POST /api/v1/tenant-users/:id/send-login-link 
Questa route fornisce la possibilità di inviare un link di accesso a un singolo TenantUser.
Utile quando si creano utenti in batch e non si vuole dover spiegare loro come effettuare il login su FastComments.com. Questo invierà loro semplicemente un "link magico" per accedere che scade dopo 30 days.
Esistono le seguenti restrizioni per inviare un link di accesso a un TenantUser:
- Il
TenantUserdeve già esistere. - Devi avere accesso per gestire il
Tenanta cui appartiene ilTenantUser.
Possiamo inviare un link di accesso a un TenantUser come segue:

Questo invierà un'email come Bob at TenantName is inviting you to be a moderator...


PATCH /api/v1/tenant-users/:id 
Questa route fornisce la possibilità di aggiornare un singolo TenantUser.
L'aggiornamento di un TenantUser ha le seguenti restrizioni:
- Il
signUpDatenon può essere nel futuro. - Il
localedeve essere nella lista dei Locali supportati. - Il
usernamedeve essere univoco in tutto FastComments.com. Se questo è un problema, suggeriamo di usare SSO. - La
emaildeve essere univoca in tutto FastComments.com. Se questo è un problema, suggeriamo di usare SSO. - Non è possibile aggiornare il
tenantIddi un utente.
Possiamo creare un TenantUser come segue



DELETE /api/v1/tenant-users/:id 
Questa route consente la rimozione di un TenantUser tramite ID.
È possibile eliminare i commenti dell'utente tramite il parametro di query deleteComments. Nota che se questo è true:
- Tutti i commenti dell'utente saranno eliminati in tempo reale.
- Tutti i child (ora orfani) commenti saranno eliminati o anonimizzati in base alla configurazione della pagina associata a ciascun commento. Ad esempio se la modalità di cancellazione del thread è "anonymize", allora le risposte rimarranno, e i commenti dell'utente saranno anonimizzati. Questo si applica solo quando
commentDeleteModeèRemove(il valore predefinito). - Il
creditsCostdiventa2.
Commenti anonimizzati
Puoi conservare i commenti dell'utente ma semplicemente anonimizzarli impostando commentDeleteMode=1.
Se i commenti dell'utente vengono anonimizzati, i seguenti valori vengono impostati su null:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badges
isDeleted e isDeletedUser vengono impostati a true.
Durante il rendering, il widget dei commenti utilizzerà DELETED_USER_PLACEHOLDER (default: "[deleted]") per il nome dell'utente e DELETED_CONTENT_PLACEHOLDER per il commento. Questi possono essere personalizzati tramite l'interfaccia di personalizzazione del Widget.
Esempi



Struttura utente 
User è un oggetto che rappresenta il denominatore comune di tutti gli utenti.
Tieni presente che in FastComments abbiamo diversi casi d'uso per gli utenti:
- Secure SSO
- Simple SSO
- Utenti Tenant (Ad esempio: Amministratori)
- Commentatori
Questa API è per i Commentatori e per gli utenti creati tramite Simple SSO. In pratica, qualsiasi utente creato
tramite il tuo sito può essere accessibile tramite questa API. Anche gli Utenti Tenant possono essere recuperati in questo modo, ma otterrai più informazioni interagendo con l'API /tenant-users/.
Per Secure SSO utilizza l'API /sso-users/.
Non puoi aggiornare questi tipi di utenti. Hanno creato il loro account tramite il tuo sito, quindi forniamo un accesso di base in sola lettura, ma
non puoi apportare modifiche. Se desideri avere questo tipo di flusso - devi configurare Secure SSO.
La struttura dell'oggetto User è la seguente:

GET /api/v1/users/:id 
Questa route restituisce un singolo User per id.



Struttura voto 
Un oggetto Vote rappresenta un voto lasciato da un utente.
La relazione tra commenti e il voto è definita tramite commentId.
La struttura dell'oggetto Vote è la seguente:

GET /api/v1/votes 
I voti devono essere recuperati tramite urlId.
Tipi di voti
Esistono tre tipi di voti:
- Voti autenticati, che vengono applicati al commento corrispondente. È possibile crearli tramite questa API.
- Voti autenticati, che sono in attesa di verifica e quindi non sono ancora applicati al commento. Questi vengono creati quando un utente usa il meccanismo FastComments.com accedi per votare.
- Voti anonimi, che vengono applicati al commento corrispondente. Questi vengono creati insieme ai commenti anonimi.
Questi vengono restituiti in liste separate nell'API per ridurre la confusione.



Note sui voti anonimi
Nota che i voti anonimi creati tramite questa API appariranno nella lista appliedAuthorizedVotes. Sono considerati autorizzati poiché sono stati creati tramite l'API con una API key.
La struttura appliedAnonymousVotes è per voti creati senza email, API key, ecc.
GET /api/v1/votes/for-user 
Permette di recuperare i voti lasciati da un utente su un determinato urlId. Richiede un userId che può essere un utente FastComments.com o un SSO User.
Questo è utile se vuoi mostrare se un utente ha votato un commento. Quando recuperi i commenti, chiama semplicemente questa API nello stesso momento per l'utente con lo stesso urlId.
Se usi il voto anonimo, dovresti invece passare anonUserId.


Nota che i voti anonimi appariranno nella lista appliedAuthorizedVotes. Sono considerati autorizzati poiché sono stati creati tramite l'API con una API key.


POST /api/v1/votes 
Questa route fornisce la possibilità di aggiungere un singolo Vote autorizzato. I voti possono essere up (+1) o down (-1).




Creazione di voti anonimi
I voti anonimi possono essere creati impostando anonUserId nei parametri di query invece di userId.
Questo id non deve corrispondere a un oggetto utente da nessuna parte (da qui anonimo). È semplicemente un identificatore per la sessione, così puoi recuperare nuovamente i voti nella stessa sessione, per verificare se a un commento è stato dato un voto.
Se non hai qualcosa come "sessioni anonime" come fa FastComments, puoi semplicemente impostarlo su un ID casuale, come un UUID (anche se apprezziamo identificatori più piccoli per risparmiare spazio).
Altre note
- Questa API rispetta le impostazioni a livello di tenant. Per esempio, se disabiliti il voto per una determinata pagina e tenti di creare un voto tramite l'API, fallirà con il codice di errore
voting-disabled. - Questa API è attiva di default.
- Questa API aggiornerà i
votesdel corrispondenteComment.
DELETE /api/v1/votes/:id 
Questa route fornisce la possibilità di eliminare un singolo Vote.



Note:
- Questa API rispetta le impostazioni a livello di tenant. Ad esempio, se disabiliti il voto per una data pagina, e tenti di creare un voto tramite l'API, fallirà con il codice di errore
voting-disabled. - Questa API è attiva per impostazione predefinita.
- Questa API aggiornerà i
votesdel corrispondenteComment.
Struttura configurazione dominio 
Un oggetto DomainConfig rappresenta la configurazione per un dominio di un tenant.
La struttura dell'oggetto DomainConfig è la seguente:


Per l'autenticazione
La configurazione del dominio viene utilizzata per determinare quali siti possono ospitare il widget FastComments per il tuo account. Questa è una forma di autenticazione di base, il che significa che aggiungere o rimuovere qualsiasi configurazione di dominio può influire sulla disponibilità della tua installazione FastComments in produzione.
Non rimuovere o aggiornare la proprietà domain di un Domain Config per un dominio attualmente in uso, a meno che non sia tua intenzione disabilitare quel dominio.
Questo ha lo stesso comportamento della rimozione di un dominio da /auth/my-account/configure-domains.
Nota inoltre che rimuovere un dominio dall'interfaccia My Domains rimuoverà qualsiasi configurazione corrispondente per quel dominio che potrebbe essere stata aggiunta tramite tale interfaccia.
Per la personalizzazione delle email
Il link di disiscrizione nel footer dell'email e la funzionalità di disiscrizione con un clic offerta da molti client di posta possono essere configurati tramite questa API definendo rispettivamente footerUnsubscribeURL e emailHeaders.
Per DKIM
Dopo aver definito i record DNS DKIM, aggiorna semplicemente il DomainConfig con la tua configurazione DKIM utilizzando la struttura definita.
GET /api/v1/domain-configs 
Questa API consente di recuperare tutti gli oggetti DomainConfig per un tenant.



GET /api/v1/domain-configs/:domain 
I singoli DomainConfigs possono essere recuperati tramite il corrispondente domain.



POST /api/v1/domain-configs 
Questo endpoint API consente di creare configurazioni di dominio.
Aggiungere una configurazione per un dominio autorizza quel dominio per l'account FastComments.
I casi d'uso comuni per questa API sono la configurazione iniziale, l'aggiunta di molti domini, o la personalizzazione della configurazione per l'invio di email.



PATCH /api/v1/domain-configs/:domain 
Questo endpoint API consente di aggiornare la configurazione di un dominio specificando solamente il dominio e l'attributo da aggiornare.



PUT /api/v1/domain-configs/:domain 
Questo endpoint API consente di sostituire una configurazione del dominio.



DELETE /api/v1/domain-configs/:domain 
Questa route consente la rimozione di un singolo DomainConfig tramite id.
- Nota: La rimozione di un
DomainConfigrevoca l'autorizzazione di quel dominio all'utilizzo di FastComments. - Nota: Riaggiungere un dominio tramite la UI ricreerà l'oggetto (con solo
domainpopolato).



Struttura configurazione domanda 
FastComments fornisce un modo per creare domande e aggregarne i risultati. Un esempio di domanda (d'ora in poi chiamata QuestionConfig) potrebbe essere una valutazione a stelle, uno slider, o una domanda NPS (determinata tramite type).
I dati delle domande possono essere aggregati individualmente, insieme, nel tempo, complessivamente, per pagina, e così via.
Il framework dispone di tutte le funzionalità necessarie per costruire widget client-side (con il tuo server davanti a questa API), pannelli di amministrazione e strumenti di reporting.
Per prima cosa, dobbiamo definire un QuestionConfig. La struttura è la seguente:

GET /api/v1/question-configs 
Questa route restituisce fino a 100 oggetti QuestionConfig alla volta, paginati. Il costo è 1 per ogni 100 oggetti. Sono
ordinati per testo della domanda in ordine ascendente (question field).



GET /api/v1/question-configs/:id 
Questa route restituisce un singolo QuestionConfig per il suo id.



POST /api/v1/question-configs 
Questo endpoint API consente di creare un QuestionConfig.



PATCH /api/v1/question-configs/:id 
Questa route permette di aggiornare un singolo QuestionConfig.
La seguente struttura rappresenta tutti i valori che possono essere modificati:




DELETE /api/v1/question-configs/:id 
Questa route permette la rimozione di un QuestionConfig tramite id.
Questo cancellerà tutti i risultati delle domande corrispondenti (ma non i commenti). Fa parte del costo elevato in crediti.



Struttura risultato domanda 
Per salvare i risultati delle domande, crei un QuestionResult. Puoi quindi aggregare i risultati delle domande e anche collegarli ai commenti per scopi di reportistica.

GET /api/v1/question-results 
Questa route restituisce fino a 1000 oggetti QuestionResults alla volta, paginati. Il costo è 1 ogni 100 oggetti. Sono
ordinati per createdAt, in ordine crescente. Puoi filtrare per vari parametri.



GET /api/v1/question-results/:id 
Questa route restituisce un singolo QuestionResult in base al suo id.



POST /api/v1/question-results 
Questo endpoint API consente di creare un QuestionResult.



PATCH /api/v1/question-results/:id 
Questa route fornisce la possibilità di aggiornare un singolo QuestionResult.
La struttura seguente rappresenta tutti i valori che possono essere modificati:




DELETE /api/v1/question-results/:id 
Questa route consente la rimozione di un QuestionResult tramite id.



GET /api/v1/question-results-aggregate 
Qui avviene l'aggregazione dei risultati.
La struttura della risposta di aggregazione è la seguente:

Ecco i parametri di query disponibili per l'aggregazione:

Ecco un esempio di richiesta:

Esempio di risposta:


Note sulle prestazioni
- In caso di cache miss, le aggregazioni richiedono generalmente cinque secondi per milione di risultati.
- In caso contrario, le richieste hanno tempo costante.
Note su caching e costi
- Quando viene specificato
forceRecalculate, il costo è sempre10, invece del normale2. - Se la cache scade e i dati vengono ricalcolati, il costo rimane comunque costante a
2seforceRecalculatenon è specificato. La cache scade in base alla dimensione del set di dati aggregato (può variare tra 30 secondi e 5 minuti). - Questo per incentivare l'uso della cache.
GET /api/v1/question-results-aggregate/combine/comments 
Qui avviene la combinazione dei risultati con i commenti. Utile, per esempio, per creare un grafico di "commenti recenti positivi e negativi" per un prodotto.
È possibile cercare tramite un intervallo di valori (inclusivo), una o più domande e per data di inizio (inclusiva).
La struttura della risposta è la seguente:

Ecco i parametri di query disponibili per l'aggregazione:

Ecco una richiesta di esempio:

Esempio di risposta:


Note sulla cache e sui costi
- Quando
forceRecalculateè specificato, il costo è sempre10, invece del normale2. - Se la cache scade e i dati vengono ricalcolati, il costo rimane comunque una costante di
2seforceRecalculatenon è specificato. - Questo per incentivare l'uso della cache.
Struttura badge utente 
UserBadge è un oggetto che rappresenta un badge assegnato a un utente nel sistema FastComments.
I badge possono essere assegnati agli utenti automaticamente in base alla loro attività (come il numero di commenti, il tempo di risposta, lo stato di veterano) o manualmente dagli amministratori del sito.
La struttura dell'oggetto UserBadge è la seguente:

GET /api/v1/user-badges 
Questo endpoint consente di recuperare i badge degli utenti in base a vari criteri.
Esempio di richiesta:
Run 
Puoi aggiungere vari parametri di query per filtrare i risultati:
userId- Ottieni i badge per uno specifico utentebadgeId- Ottieni le istanze di uno specifico badgetype- Filtra per tipo di badge (0=CommentCount, 1=CommentUpVotes, 2=CommentReplies, etc. Vedi la struttura UserBadge per l'elenco completo)displayedOnComments- Filtra in base a se il badge è visualizzato nei commenti (true/false)limit- Numero massimo di badge da restituire (default 30, max 200)skip- Numero di badge da saltare (per la paginazione)
Esempio di risposta:

Possibili risposte di errore:


GET /api/v1/user-badges/:id 
Questo endpoint consente di recuperare un badge utente specifico tramite il suo ID univoco.
Esempio di richiesta:
Run 
Esempio di risposta:

Possibili risposte di errore:


POST /api/v1/user-badges 
Questo endpoint consente di creare una nuova assegnazione di badge per un utente.
Esempio di richiesta:
Run 
Il corpo della richiesta deve contenere i seguenti parametri:
userId(obbligatorio) - L'ID dell'utente a cui assegnare il badgebadgeId(obbligatorio) - L'ID del badge da assegnaredisplayedOnComments(opzionale) - Se il badge deve essere visualizzato nei commenti dell'utente (predefinito: true)
Note importanti:
- Il badge deve esistere ed essere abilitato nel catalogo dei badge del tuo tenant
- Puoi assegnare badge solo agli utenti che appartengono al tuo tenant o che hanno commentato sul tuo sito
Esempio di risposta:

Possibili risposte di errore:





PUT /api/v1/user-badges/:id 
Questo endpoint ti consente di aggiornare l'assegnazione di un badge utente.
Attualmente, l'unica proprietà che può essere aggiornata è displayedOnComments, che controlla se il badge viene mostrato nei commenti dell'utente.
Esempio di richiesta:
Run 
Esempio di risposta:

Possibili risposte di errore:



DELETE /api/v1/user-badges/:id 
Questo endpoint consente di eliminare un'assegnazione di badge utente.
Esempio di richiesta:
Run 
Esempio di risposta:

Possibili risposte di errore:



Struttura progresso badge utente 
UserBadgeProgress è un oggetto che rappresenta il progresso di un utente verso l'ottenimento di vari badge nel sistema FastComments.
Questo tracciamento aiuta a determinare quando gli utenti dovrebbero ricevere badge automatici in base alla loro attività e partecipazione nella tua community.
La struttura per l'oggetto UserBadgeProgress è la seguente:

GET /api/v1/user-badge-progress 
Questo endpoint permette di recuperare i record di avanzamento dei badge utente in base a vari criteri.
Example Request:
Run 
Puoi aggiungere vari parametri di query per filtrare i risultati:
userId- Ottieni l'avanzamento per uno specifico utentelimit- Numero massimo di record da restituire (default 30, max 200)skip- Numero di record da saltare (per la paginazione)
Example Response:

Possible Error Responses:


GET /api/v1/user-badge-progress/:id 
Questo endpoint consente di recuperare un record specifico di avanzamento del badge utente tramite il suo ID univoco.
Esempio di richiesta:
Run 
Esempio di risposta:

Possibili risposte di errore:


GET /api/v1/user-badge-progress/user/:userId 
Questo endpoint consente di recuperare il record di avanzamento del badge di un utente tramite il suo ID utente.
Esempio di richiesta:
Run 
Esempio di risposta:

Possibili risposte di errore:



In conclusione
Speriamo che tu abbia trovato la nostra documentazione API esaustiva e facile da comprendere. Se trovi delle lacune, faccelo sapere qui sotto.