
Език 🇧🇬 Български
Ресурси на API
Агрегации
Аудитни записи
Коментари
Шаблони за имейли
Хаштагове
Модератори
Брой известия
Известия
Страници
Очакващи уебхук събития
SSO потребители
Абонаменти
Дневна употреба на тенанта
Тенанти
Пакети на тенанта
Потребители на тенанта
Потребители
Гласове
Конфигурации на домейн
Конфигурации на въпроси
Резултати от въпроси
Агрегация на резултатите от въпроси
Потребителски значки
Напредък на потребителските значки
The FastComments API
FastComments предоставя API за взаимодействие с множество ресурси. Създавайте интеграции с нашата платформа или дори изграждайте свои собствени клиенти!
В тази документация ще намерите всички поддържани ресурси от API, документирани с техните типове заявки и отговори.
За корпоративни клиенти, целият достъп до API се записва в дневника на одита.
Generated SDKs
FastComments вече генерира един API Spec от нашия код (това все още не е пълно, но включва много APIs).
Също така вече разполагаме със SDK за популярни езици:
- fastcomments-cpp
- fastcomments-go
- fastcomments-java
- fastcomments-sdk-js
- fastcomments-nim
- fastcomments-php
- fastcomments-php-sso
- fastcomments-python
- fastcomments-ruby
- fastcomments-rust
- fastcomments-swift
Authentication
API-то се удостоверява чрез подаване на вашия api key като или X-API-KEY хедър, или като API_KEY query параметър. Също така ще ви е необходим вашият tenantId за извършване на API повиквания. Той може да бъде получен от същата страница като вашия api key.
Security Note
Тези рутове са предназначени да се вика от сървър. НЕ ги викайте от браузър. Правенето на това ще изложи вашия API key - това ще предостави пълен достъп до вашия акаунт на всеки, който може да види изходния код на страница!
Authentication Option One - Headers
- Хедър:
X-API-KEY - Хедър:
X-TENANT-ID
Authentication Option Two - Query Parameters
- Параметър на заявката:
API_KEY - Параметър на заявката:
tenantId
Ресурси на API 
Използване на ресурси
Трябва да се отбележи, че извличането на данни от API се брои като използване на вашия акаунт.
Всеки ресурс ще посочи какво е това използване в собствения си раздел.
Някои ресурси струват повече за обслужване от други. Всяка крайна точка има определена цена от кредити за API извикване. За някои крайни точки броят на кредитите варира в зависимост от опциите и размера на отговорите.
Използването на API може да се провери на страницата Анализ на фактуриране и се актуализира на всеки няколко минути.
Забележка!
Препоръчваме първо да прочетете документацията за Pages, за да ограничите объркването при определяне какви стойности да подадете за urlId в Comment API.
Обобщете данните си 
Този API агрегира документи, като ги групира (ако е предоставен groupBy) и прилага множество операции. Поддържат се различни операции (напр. sum, countDistinct, avg и др.).
Цената е променлива. Всеки 500 сканирани обекта струва 1 API кредит.
Максималното използване на паметта, разрешено за API извикване по подразбиране, е 64MB и по подразбиране можете да имате само една агрегация, работеща едновременно. Ако изпратите множество агрегации едновременно, те ще бъдат поставени на опашка и ще се изпълняват в реда на подаване. Чакащите агрегации ще изчакат максимум 60 секунди, след което заявката ще изтече. Отделните агрегации могат да работят до 5 минути.
Ако имате управлявани наематели, можете да агрегирате всички ресурси на дъщерните наематели в едно извикване, като подадете параметъра parentTenantId в заявката.
Примери
Пример: Брой уникални


Пример: Брой различни

Отговор:

Пример: Сума на стойности от множество полета

Отговор:

Пример: Средна стойност на множество полета

Отговор:

Пример: Минимални/Максимални стойности на множество полета

Отговор:

Пример: Брой уникални стойности на множество полета

Отговор:

Пример: Създаване на заявка

Отговор:

Пример: Брой коментари, чакащи преглед

Отговор:

Пример: Разбивка на одобрени, прегледани и спам коментари

Отговор:

Структури


Следните ресурси могат да бъдат агрегирани:
- AffiliateEvent
- AnonymousVote
- BannedUser
- BatchJob
- BlockedUser
- Comment
- CommentDeleted
- CommentIdToSyncOutbound
- CommentScheduled
- CommentSyncLog
- CustomConfig
- CustomEmailTemplateRenderError
- EmailToSend
- EventLogEntry
- ImportedCommentScheduled
- ModerationGroup
- Moderator
- Page
- PageReact
- PendingVote
- QuestionResult
- SSOUser
- SentEmail
- SpamEvent
- Tenant
- TenantAuditLog
- TenantBadge
- TenantDailyUsage
- TenantInvoiceHistory
- TenantPackage
- User
- UserBadge
- UserBadgeProgress
- UserNotification
- UserSubscription
- UserUsage
- Vote
Структура на AuditLog 
AuditLog е обект, който представлява одитирано събитие за наематели, които имат достъп до тази функция.
Структурата на обекта AuditLog е следната:

Одитният дневник е неизменяем. Също така не може да се записва ръчно. Само FastComments.com може да реши кога да записва в одитния дневник. Въпреки това можете да четете от него чрез този API.
Събитията в одитния дневник изтичат след две години.
GET /api/v1/audit-logs 
Този API използва странициране, предоставено от параметрите skip, before и after. AuditLogs се връщат на страници от 1000, подредени по when и id.
Извличането на всеки 1000 лога има кредитна цена от 10.
По подразбиране ще получите списък с най-новите елементи първи. По този начин можете да анкетирате, започвайки от skip=0, страници докато намерите последния запис, който сте консумирали.
Алтернативно, можете да сортирате най-старите първи и да страницирате докато няма повече записи.
Сортирането може да се направи като зададете order на ASC или DESC. По подразбиране е ASC.
Заявка по дата е възможна чрез before и after като времеви печати с милисекунди. before и after НЕ са включителни.



Структура на коментара 
Обектът Comment представлява коментар, оставен от потребител.
Връзката между родителски и дъщерни коментари се определя чрез parentId.
Структурата на обекта Comment е следната:

Някои от тези полета са маркирани като READONLY - те се връщат от API, но не могат да бъдат зададени.
Структура на текста на коментара
Коментарите се пишат във FastComments вариант на markdown, който е просто markdown плюс традиционни bbcode стилови тагове за изображения, като [img]path[/img].
Текстът се съхранява в две полета. Текстът, въведен от потребителя, се съхранява непроменен в полето comment. Той се обработва и съхранява в полето commentHTML.
Позволените HTML тагове са b, u, i, strike, pre, span, code, img, a, strong, ul, ol, li, и br.
Препоръчително е да визуализирате HTML, тъй като е много малко подмножество от HTML, изграждането на визуализатор е доста лесно. Има множество библиотеки за React Native и Flutter, например, които да помогнат с това.
Можете да изберете да визуализирате ненормализираната стойност на полето comment. Примерен парсер е тук..
Примерният парсер може също да бъде адаптиран да работи с HTML и да трансформира HTML таговете в очакваните елементи за визуализация за вашата платформа.
Отбелязване
Когато потребителите са отбелязани в коментар, информацията се съхранява в списък, наречен mentions. Всеки обект в този списък
има следната структура.
Run 
Хаштагове
Когато се използват хаштагове и са успешно обработени, информацията се съхранява в списък, наречен hashTags. Всеки обект в този списък
има следната структура. Хаштаговете могат също да бъдат ръчно добавени към масива hashTags на коментара за заявки, ако retain е зададен.
Run 
GET /api/v1/comments 
Този API се използва за получаване на коментари за показване на потребител. Например, автоматично филтрира неодобрени или спам коментари.
Странициране
Страницирането може да се направи по един от два начина, в зависимост от изискванията за производителност и случая на употреба:
- Най-бързо: Предварително изчислено странициране:
- Така работи FastComments, когато използвате нашите готови уиджети и клиенти.
- Щракването върху "следващ" просто увеличава броя на страниците.
- Можете да мислите за това като извличане чрез хранилище ключ-стойност.
- По този начин просто дефинирайте параметър
page, започващ от0, и посока на сортиране катоdirection. - Размерите на страниците могат да бъдат персонализирани чрез правила за персонализация.
- Най-гъвкаво: Гъвкаво странициране:
- По този начин можете да дефинирате персонализирани параметри
limitиskip. Не подавайтеpage. - Посока на сортиране
directionсъщо се поддържа. limitе общият брой за връщане след прилагане наskip.- Пример: задайте
skip = 200, limit = 100, когатоpage size = 100иpage = 2.
- Пример: задайте
- Дъщерните коментари все още се броят при страницирането. Можете да заобиколите това, като използвате опцията
asTree.- Можете да странирате децата чрез
limitChildrenиskipChildren. - Можете да ограничите дълбочината на върнатите нишки чрез
maxTreeDepth.
- Можете да странирате децата чрез
- По този начин можете да дефинирате персонализирани параметри
Нишки
- Когато използвате
Предварително изчислено странициране, коментарите се групират по страница и коментарите в нишки влияят на общата страница.- По този начин нишките могат да се определят на клиента въз основа на
parentId. - Например, със страница с един коментар от най-високо ниво и 29 отговора, и задаване на
page=0в API - ще получите само коментара от най-високо ниво и 29-те деца. - Примерно изображение тук, илюстриращо множество страници.
- По този начин нишките могат да се определят на клиента въз основа на
- Когато използвате
Гъвкаво странициране, можете да дефинирате параметърparentId.- Задайте това на null, за да получите само коментари от най-високо ниво.
- След това, за да видите нишки, извикайте API отново и подайте
parentId. - Често срещано решение е да направите API извикване за коментарите от най-високо ниво и след това да направите паралелни API извиквания, за да получите коментарите за децата на всеки коментар.
- НОВО от февруари 2023! Извличане като дърво с използване на
&asTree=true.- Можете да мислите за това като
Гъвкаво странициране като дърво. - Само коментарите от най-високо ниво се броят при страницирането.
- Задайте
parentId=null, за да започнете дървото от корена (трябва да зададетеparentId). - Задайте
skipиlimitза странициране. - Задайте
asTreeнаtrue. - Цената на кредитите се увеличава с
2x, тъй като нашият бекенд трябва да свърши много повече работа в този сценарий. - Задайте
maxTreeDepth,limitChildrenиskipChildrenпо желание.
- Можете да мислите за това като
Обяснение на дърветата
Когато използвате asTree, може да е трудно да разсъждавате за страницирането. Ето полезна графика:
Извличане на коментари в контекста на потребител
API /comments може да се използва в два контекста, за различни случаи на употреба:
- За връщане на коментари, сортирани и маркирани с информация за изграждане на ваш собствен клиент.
- В този случай дефинирайте параметър на заявката
contextUserId.
- В този случай дефинирайте параметър на заявката
- За извличане на коментари от вашия бекенд за персонализирани интеграции.
- Платформата ще използва това по подразбиране без
contextUserId.
- Платформата ще използва това по подразбиране без




Получаване на коментари като дърво
Възможно е коментарите да се върнат като дърво, като страницирането брои само коментарите от най-високо ниво.

Искате да получите само коментарите от най-високо ниво и непосредствените деца? Ето един начин:

Въпреки това, във вашия потребителски интерфейс може да се наложи да знаете дали да покажете бутон "покажи отговорите" на
всеки коментар. Когато извличате коментари чрез дърво, има свойство hasChildren, маркирано
към коментарите, когато е приложимо.
Получаване на коментари като дърво, търсене по хаштаг
Възможно е да търсите по хаштаг с помощта на API, в целия ви tenant (не е ограничено до една страница или urlId).
В този пример пропускаме urlId и търсим по множество хаштагове. API ще върне само коментари, които имат всички заявени хаштагове.

Всички параметри на заявката

Отговорът

Полезни съвети
URL ID
Вероятно искате да използвате API Comment с параметъра urlId. Можете първо да извикате API Pages, за да видите как изглеждат наличните за вас стойности на urlId.
Анонимни действия
За анонимно коментиране вероятно искате да подадете anonUserId, когато извличате коментари и когато извършвате докладване и блокиране.
(!) Това е необходимо за много магазини за приложения, тъй като потребителите трябва да могат да докладват съдържание, създадено от потребители, което могат да видят, дори ако не са влезли. Неизпълнението на това може да доведе до премахване на приложението ви от съответния магазин.
Коментарите не се връщат
Проверете дали вашите коментари са одобрени и не са спам.
GET /api/v1/comments/:id 
Този API предоставя възможност за извличане на единичен коментар по id.



POST /api/v1/comments 
Тази API крайна точка предоставя възможност за създаване на коментари.
Често срещани случаи на употреба са персонализирани потребителски интерфейси, интеграции или импортиране.
Забележки:
- Този API може да актуализира уиджета за коментари "на живо" ако желаете (това увеличава
creditsCostот1на2). - Този API автоматично ще създаде потребителски обекти в нашата система, ако е предоставен имейл.
- Опитът да запазите два коментара с различни имейли, но с едно и също потребителско име, ще доведе до грешка за втория коментар.
- Ако посочвате
parentIdи дъщерният коментар имаnotificationSentForParentкато false, ние ще изпратим известия за родителския коментар. Това се прави на всеки час (групираме известията заедно, за да намалим броя на изпратените имейли). - Ако искате да изпращате приветствени имейли при създаване на потребители или имейли за потвърждение на коментари, задайте
sendEmailsнаtrueв параметрите на заявката. - Коментарите, създадени чрез този API, ще се показват в страниците за анализ и модерация на административното приложение.
- "лошите думи" все още се маскират в имената на коментиращите и текста на коментарите, ако настройката е включена.
- Коментарите, създадени чрез този API, все още могат да бъдат проверявани за спам, ако желаете.
- Конфигурацията като максимална дължина на коментара, ако е конфигурирана чрез административната страница за правила за персонализация, ще се прилага тук.
Минималните данни, необходими за изпращане, които ще се показват в уиджета за коментари, са следните:

По-реалистична заявка може да изглежда така:



PATCH /api/v1/comments/:id 
Тази API крайна точка предоставя възможност за актуализиране на единичен коментар.
Забележки:
- Този API може да актуализира уиджета за коментари "на живо" ако желаете (това увеличава базовата
creditsCostот1на2).- Това може да направи мигрирането на коментари между страници "на живо" (промяна на
urlId). - Миграциите струват допълнително
2кредита, тъй като страниците се предварително изчисляват и това е CPU интензивно.
- Това може да направи мигрирането на коментари между страници "на живо" (промяна на
- За разлика от API за създаване, този API НЯМА автоматично да създава потребителски обекти в нашата система, ако е предоставен имейл.
- Коментарите, актуализирани чрез този API, все още могат да бъдат проверявани за спам, ако желаете.
- Конфигурацията като максимална дължина на коментара, ако е конфигурирана чрез административната страница за правила за персонализация, ще се прилага тук.
- За да позволите на потребителите да актуализират текста на коментара си, можете просто да посочите
commentв тялото на заявката. Ние ще генерираме резултатнияcommentHTML.- Ако дефинирате и
comment, иcommentHTML, ние няма автоматично да генерираме HTML. - Ако потребителят добави споменавания или хаштагове в новия си текст, той все още ще бъде обработен като
POSTAPI.
- Ако дефинирате и
- Когато актуализирате
commenterEmailна коментар, е най-добре също да посочитеuserId. В противен случай трябва да се уверите, че потребителят с този имейл принадлежи на вашия tenant, или заявката ще се провали.



DELETE /api/v1/comments/:id 
Тази API крайна точка предоставя възможност за изтриване на коментар.
Забележки:
- Този API може да актуализира уиджета за коментари "на живо" ако желаете (това увеличава
creditsCostот1на2). - Този API ще изтрие всички дъщерни коментари.



POST /api/v1/comments/:id/flag 
Тази API крайна точка предоставя възможност за докладване на коментар за конкретен потребител.
Забележки:
- Това извикване винаги трябва да се прави в контекста на потребител. Потребителят може да бъде FastComments.com потребител, SSO потребител или Tenant потребител.
- Ако е зададен праг за докладване-скриване, коментарът ще бъде автоматично скрит на живо след като бъде докладван определен брой пъти.
- След като бъде автоматично неодобрен (скрит) - коментарът може да бъде повторно одобрен само от администратор или модератор. Премахването на докладването няма да одобри отново коментара.

За анонимно докладване трябва да посочим anonUserId. Това може да бъде ID, който представлява анонимната сесия, или случаен UUID.
Това ни позволява да поддържаме докладване и премахване на докладване на коментари дори ако потребителят не е влязъл в системата. По този начин коментарът може да бъде маркиран като
докладван, когато коментарите се извличат със същия anonUserId.



POST /api/v1/comments/:id/un-flag 
Тази API крайна точка предоставя възможност за премахване на докладването на коментар за конкретен потребител.
Забележки:
- Това извикване винаги трябва да се прави в контекста на потребител. Потребителят може да бъде FastComments.com потребител, SSO потребител или Tenant потребител.
- След като коментарът е автоматично неодобрен (скрит) - коментарът може да бъде повторно одобрен само от администратор или модератор. Премахването на докладването няма да одобри отново коментара.

За анонимно докладване трябва да посочим anonUserId. Това може да бъде ID, който представлява анонимната сесия, или случаен UUID.



POST /api/v1/comments/:id/block 
Тази API крайна точка предоставя възможност за блокиране на потребител, написал даден коментар. Поддържа блокиране от коментари, написани от FastComments.com потребители, SSO потребители и Tenant потребители.
Поддържа параметър commentIdsToCheck в тялото, за да провери дали други потенциално видими коментари на клиента трябва да бъдат блокирани/отблокирани след извършване на това действие.
Забележки:
- Това извикване винаги трябва да се прави в контекста на потребител. Потребителят може да бъде FastComments.com потребител, SSO потребител или Tenant потребител.
userIdв заявката е потребителят, който извършва блокирането. Например:Потребител Aиска да блокираПотребител B. ПодайтеuserId=Потребител Aи id на коментара, койтоПотребител Bе написал.- Напълно анонимни коментари (без потребителски id, без имейл) не могат да бъдат блокирани и ще бъде върната грешка.

За анонимно блокиране трябва да посочим anonUserId. Това може да бъде ID, който представлява анонимната сесия, или случаен UUID.
Това ни позволява да поддържаме блокиране на коментари дори ако потребителят не е влязъл в системата, като извличаме коментарите със същия anonUserId.



POST /api/v1/comments/:id/un-block 
Тази API крайна точка предоставя възможност за отблокиране на потребител, написал даден коментар. Поддържа отблокиране от коментари, написани от FastComments.com потребители, SSO потребители и Tenant потребители.
Поддържа параметър commentIdsToCheck в тялото, за да провери дали други потенциално видими коментари на клиента трябва да бъдат блокирани/отблокирани след извършване на това действие.
Забележки:
- Това извикване винаги трябва да се прави в контекста на потребител. Потребителят може да бъде FastComments.com потребител, SSO потребител или Tenant потребител.
userIdв заявката е потребителят, който извършва отблокирането. Например:Потребител Aиска да отблокираПотребител B. ПодайтеuserId=Потребител Aи id на коментара, койтоПотребител Bе написал.- Напълно анонимни коментари (без потребителски id, без имейл) не могат да бъдат блокирани и ще бъде върната грешка.




Структура на шаблон за имейл 
Обектът EmailTemplate представлява конфигурация за персонализиран имейл шаблон за tenant.
Системата ще избере имейл шаблона за използване чрез:
- Неговия идентификатор на типа, наречен
emailTemplateId. Това са константи. domain. Първо ще се опитаме да намерим шаблон за домейна, към който е свързан съответният обект (катоComment), и ако не бъде намерено съвпадение, ще се опитаме да намерим шаблон, където domain е null или*.
Структурата на обекта EmailTemplate е следната:

Забележки
- Можете да получите валидните стойности на
emailTemplateIdот крайната точка/definitions. - Крайната точка
/definitionsсъщо включва преводите по подразбиране и тестовите данни. - Шаблоните няма да се запазят с невалидна структура или тестови данни.
GET /api/v1/email-templates/:id 
Индивидуални EmailTemplates могат да бъдат извлечени по съответния им id (НЕ emailTemplateId).



GET /api/v1/email-templates 
Този API използва странициране, предоставено от параметъра на заявката page. EmailTemplates се връщат на страници от 100, подредени по createdAt и след това id.



PATCH /api/v1/email-templates/:id 
Тази API крайна точка предоставя възможност за актуализиране на имейл шаблон, като посочите само id и атрибутите за актуализиране.
Имайте предвид, че всички същите валидации за създаване на шаблон се прилагат, например:
- Шаблонът трябва да се визуализира. Това се проверява при всяка актуализация.
- Не можете да имате дублирани шаблони за същия домейн (в противен случай един ще бъде мълчаливо игнориран).



POST /api/v1/email-templates 
Тази API крайна точка предоставя възможност за създаване на имейл шаблони.
Забележки:
- Не можете да имате множество шаблони с един и същ
emailTemplateIdс един и същ домейн. - Но можете да имате универсален шаблон (
domain=*) и специфичен за домейн шаблон за същияemailTemplateId. - Посочването на
domainе уместно само ако имате различни домейни или искате да използвате специфични шаблони за тестване (domainзададен наlocalhostи т.н.). - Ако посочите
domain, той трябва да съвпада сDomainConfig. При грешка се предоставя списък с валидни домейни. - Синтаксисът на шаблона е EJS и се визуализира с таймаут от 500ms. P99 за визуализация е <5ms, така че ако достигнете 500ms, нещо не е наред.
- Вашият шаблон трябва да се визуализира с вашите дадени
testData, за да се запази. Грешките при визуализация се агрегират и докладват в таблото (скоро налично чрез API).
Минималните данни, необходими за добавяне на шаблон, са следните:

Може да искате да имате шаблони за всеки сайт, в който случай дефинирате domain:



POST /api/v1/email-templates/render 
Тази API крайна точка предоставя възможност за предварителен преглед на имейл шаблони.



DELETE /api/v1/email-templates/:id 
Този маршрут предоставя премахването на единичен EmailTemplate по id.



Структура на хаштаг 
Обектът HashTag представлява таг, който може да бъде оставен от потребител. HashTags могат да се използват за свързване към външно съдържание или за
свързване на свързани коментари заедно.
Структурата на обекта HashTag е следната:

Забележки:
- В някои API крайни точки ще видите, че хаштагът се използва в URL. Не забравяйте да URI-кодирате стойностите. Например
#трябва вместо това да се представи като%23. - Някои от тези полета са маркирани като
READONLY- те се връщат от API, но не могат да бъдат зададени.
GET /api/v1/hash-tags 
Този API използва странициране, предоставено от параметъра на заявката page. HashTags се връщат на страници от 100, подредени по tag.



PATCH /api/v1/hash-tags/:tag 
Този маршрут предоставя възможност за актуализиране на единичен HashTag.



POST /api/v1/hash-tags 
Този маршрут предоставя възможност за добавяне на единичен HashTag.



POST /api/v1/hash-tags/bulk 
Този маршрут предоставя възможност за добавяне на до 100 обекта HashTag наведнъж.



DELETE /api/v1/hash-tags/:tag 
Този маршрут предоставя премахването на HashTag по предоставения таг.
Имайте предвид, че освен ако автоматичното създаване на HashTag не е деактивирано, хаштаговете могат да бъдат пресъздадени от потребител, предоставящ хаштага при коментиране.



Структура на модератора 
Обектът Moderator представлява конфигурация за модератор.
Има три типа модератори:
- Администраторски потребители, които имат флага
isCommentModeratorAdmin. - SSO потребители с флага
isCommentModeratorAdmin. - Обикновени коментиращи или FastComments.com потребители, които са поканени като модератори.
Структурата Moderator се използва за представяне на състоянието на модерация за случай на употреба 3.
Ако искате да поканите потребител да бъде модератор чрез API, използвайте API Moderator, като създадете Moderator и го поканите.
Ако потребителят няма акаунт в FastComments.com, имейлът с покана ще му помогне да се настрои. Ако вече има акаунт, ще му бъде
даден достъп за модерация до вашия tenant и userId на обекта Moderator ще бъде актуализиран, за да сочи към неговия потребител. Няма да имате API
достъп до техния потребител, тъй като в този случай той принадлежи на самите тях и се управлява от FastComments.com.
Ако изисквате пълно управление на акаунта на потребителя, препоръчваме или да използвате SSO, или да ги добавите като Tenant потребител и
след това да добавите обект Moderator, за да проследявате техните статистики.
Структурата Moderator може да се използва като механизъм за проследяване на статистики за случаи на употреба 1 и 2. След създаване на потребителя добавете обект Moderator
с дефиниран userId и техните статистики ще бъдат проследявани на страницата с модератори на коментари.
Структурата на обекта Moderator е следната:

GET /api/v1/moderators/:id 
Този маршрут връща единичен модератор по неговия id.



GET /api/v1/moderators 
Този API използва странициране, предоставено от параметъра на заявката skip. Moderators се връщат на страници от 100, подредени по createdAt и id.
Цената се базира на броя върнати модератори, като струва 1 кредит на 10 върнати модератора.



PATCH /api/v1/moderators/:id 
Тази API крайна точка предоставя възможност за актуализиране на Moderator по id.
Актуализирането на Moderator има следните ограничения:
- Следните стойности не могат да бъдат предоставени при актуализиране на
Moderator:acceptedInvitemarkReviewedCountdeletedCountmarkedSpamCountapprovedCounteditedCountbannedCountverificationIdcreatedAt
- Когато е посочен
userId, този потребител трябва да съществува. - Когато е посочен
userId, той трябва да принадлежи на същияtenantId, посочен в параметрите на заявката. - Двама модератори в един и същ tenant не могат да бъдат добавени с един и същ
email. - Не можете да променяте
tenantId, свързан сModerator.



POST /api/v1/moderators 
Този маршрут предоставя възможност за добавяне на единичен Moderator.
Създаването на Moderator има следните ограничения:
- Винаги трябва да се предоставят
nameиemail.userIdе незадължителен. - Следните стойности не могат да бъдат предоставени при създаване на
Moderator:acceptedInvitemarkReviewedCountdeletedCountmarkedSpamCountapprovedCounteditedCountbannedCountverificationIdcreatedAt
- Когато е посочен
userId, този потребител трябва да съществува. - Когато е посочен
userId, той трябва да принадлежи на същияtenantId, посочен в параметрите на заявката. - Двама модератори в един и същ tenant не могат да бъдат добавени с един и същ
email.
Можем да създадем Moderator за потребител, за който знаем само имейла:

Или можем да създадем Moderator за потребител, който принадлежи на нашия tenant, за да проследяваме неговите статистики за модерация:



POST /api/v1/moderators/:id/send-invite 
Този маршрут предоставя възможност за покана на единичен Moderator.
Съществуват следните ограничения за изпращане на имейл с покана на Moderator:
Moderatorтрябва вече да съществува.fromNameне може да бъде по-дълъг от100 символа.
Забележки:
- Ако потребител с предоставения имейл вече съществува, той ще бъде поканен да модерира коментарите на вашия tenant.
- Ако потребител с предоставения имейл не съществува, връзката за покана ще го насочи през създаването на акаунта им.
- Поканата ще изтече след
30 дни.
Можем да създадем Moderator за потребител, за който знаем само имейла:

Това ще изпрати имейл като Bob от TenantName ви кани да бъдете модератор...


DELETE /api/v1/moderators/:id 
Този маршрут предоставя премахването на Moderator по id.



Структура на броя известия 
Обектът NotificationCount представлява броя на непрочетените известия и метаданни за потребител.
Ако няма непрочетени известия, няма да има NotificationCount за потребителя.
Обектите NotificationCount се създават автоматично и не могат да бъдат създавани чрез API. Те също изтичат след една година.
Можете да изчистите броя на непрочетените известия на потребител, като изтриете неговия NotificationCount.
Структурата на обекта NotificationCount е следната:

GET /api/v1/notification-count/:user_id 
Този маршрут връща единичен NotificationCount по потребителски id. С SSO потребителският id е във формат <tenant id>:<user id>.
Ако няма непрочетени известия, няма да има NotificationCount - така че ще получите 404.
Това е различно от notifications/count по това, че е много по-бързо, но не позволява филтриране.



DELETE /api/v1/notification-count/:user_id 
Този маршрут изтрива единичен NotificationCount по потребителски id. С SSO потребителският id е във формат <tenant id>:<user id>.
Това ще изчисти броя на непрочетените известия на потребителя (червената камбанка в уиджета за коментари ще избледнее и броят ще изчезне).



Структура на известие 
Обектът Notification представлява известие за потребител.
Обектите Notification се създават автоматично и не могат да бъдат създавани чрез API. Те също изтичат след една година.
Известията не могат да бъдат изтривани. Въпреки това те могат да бъдат актуализирани, за да зададете viewed на false, и можете да търсите по viewed.
Потребителят може също да се откаже от известия за конкретен коментар, като зададе optedOut в известието на true. Можете да се включите отново, като го зададете на false.
Има различни типове известия - проверете relatedObjectType и type.
Начините, по които се създават известия, са доста гъвкави и могат да бъдат задействани от много сценарии (вижте NotificationType).
Към днешна дата съществуването на Notification всъщност не означава, че имейл е или трябва да бъде изпратен. По-скоро известията
се използват за емисия от известия и свързани интеграции.
Структурата на обекта Notification е следната:

GET /api/v1/notifications 
Този маршрут връща до 30 обекта Notification, сортирани по createdAt, най-новите първи.
Можете да филтрирате по userId. С SSO потребителският id е във формат <tenant id>:<user id>.



GET /api/v1/notifications/count 
Този маршрут връща обект, съдържащ броя на известията под параметър count.
Той е по-бавен от /notification-count/ и струва двойно повече кредити, но позволява филтриране по повече измерения.
Можете да филтрирате по същите параметри като крайната точка /notifications, като userId. С SSO потребителският id е във формат <tenant id>:<user id>.




PATCH /api/v1/notifications/:id 
Тази API крайна точка предоставя възможност за актуализиране на Notification по id.
Актуализирането на Notification има следните ограничения:
- Можете да актуализирате само следните полета:
viewedoptedOut



Структура на страница 
Обектът Page представлява страницата, към която могат да принадлежат много коментари. Тази връзка се определя от
urlId.
Page съхранява информация като заглавието на страницата, броя на коментарите и urlId.
Структурата на обекта Page е следната:

GET /api/v1/pages 
В момента можете да извличате само всички страници (или единична страница чрез /by-url-id), свързани с вашия акаунт. Ако искате по-прецизно търсене, свържете се с нас.



Полезен съвет
API Comment изисква urlId. Можете първо да извикате API Pages, за да видите как изглеждат наличните за вас стойности на urlId.
GET /api/v1/pages/by-url-id 
Индивидуални страници могат да бъдат извлечени по съответния им urlId. Това може да бъде полезно за търсене на заглавия на страници или брой коментари.



Полезен съвет
Не забравяйте да URI кодирате стойности като urlId.
PATCH /api/v1/pages/:id 
Този маршрут предоставя възможност за актуализиране на единична Page. Съответните коментари ще бъдат актуализирани.



Забележка
Някои параметри в обекта Page се актуализират автоматично. Това са атрибутите за брой и заглавие. Броевете не могат да бъдат актуализирани
чрез API, тъй като са изчислени стойности. title на страницата може да бъде зададен чрез API, но ще бъде презаписан, ако уиджетът за коментари се използва на
страница със същия urlId и различно заглавие на страницата.
POST /api/v1/pages 
Тази API крайна точка предоставя възможност за създаване на страници.
Често срещан случай на употреба е контролът на достъпа.
Забележки:
- Ако сте коментирали в нишка за коментари или сте извикали API, за да създадете
Comment, вече сте създали обектPage! Можете да опитате да го извлечете чрез маршрута/by-url-idPage, подавайки същияurlId, подаден на уиджета за коментари. - Структурата
Pageсъдържа някои изчислени стойности. В момента това саcommentCountиrootCommentCount. Те се попълват автоматично и не могат да бъдат зададени от API. Опитът да направите това ще накара API да върне грешка.



DELETE /api/v1/pages/:id 
Този маршрут предоставя премахването на единична страница по id.
Имайте предвид, че взаимодействието с уиджета за коментари за страница със същия urlId просто ще пресъздаде Page безпроблемно.



Структура на чакащо уебхук събитие 
Обектът PendingWebhookEvent представлява webhook събитие в опашката, което чака обработка.
Обектите PendingWebhookEvent се създават автоматично и не могат да бъдат създадени ръчно чрез API. Те също изтичат след една година.
Могат да бъдат изтрити, което премахва задачата от опашката.
Има различни типове събития - проверете eventType (OutboundSyncEventType) и type (OutboundSyncType).
Често срещан случай на употреба за този API е внедряването на персонализиран мониторинг. Може да искате да извикате крайната точка /count периодично,
за да проверявате броя на чакащите събития за дадени филтри.
Структурата на обекта PendingWebhookEvent е следната:

GET /api/v1/pending-webhook-events 
Този маршрут връща списък с чакащи webhook събития в параметър pendingWebhookEvents.
Този API използва пагинация, предоставена чрез параметъра skip. PendingWebhookEvents се връщат на страници от 100, подредени по createdAt от най-новите.



GET /api/v1/pending-webhook-events/count 
Този маршрут връща обект, съдържащ броя на чакащите webhook събития в параметър count.
Можете да филтрирате по същите параметри като крайната точка /pending-webhook-events



DELETE /api/v1/pending-webhook-events/:id 
Този маршрут позволява изтриването на единичен PendingWebhookEvent.
Ако имате нужда от групово изтриване, извикайте GET API с пагинация и след това извикайте този API последователно.



Структура на SSO потребител 
FastComments предоставя лесно за използване SSO решение. Актуализирането на информацията на потребител с интеграцията, базирана на HMAC, е толкова просто, колкото потребителят да зареди страницата с актуализиран payload.
Въпреки това може да е желателно да управлявате потребител извън този поток, за да подобрите последователността на вашето приложение.
API за SSO потребители предоставя начин за CRUD на обекти, които наричаме SSOUsers. Тези обекти са различни от обикновените Users и се съхраняват отделно за безопасност на типовете.
Структурата на обекта SSOUser е следната:

Фактуриране за SSO потребители
SSO потребителите се таксуват различно въз основа на техните флагове за права:
- Обикновени SSO потребители: Потребители без администраторски или модераторски права се таксуват като обикновени SSO потребители
- SSO администратори: Потребители с флагове
isAccountOwnerилиisAdminAdminсе таксуват отделно като SSO администратори (същата ставка като обикновените tenant администратори) - SSO модератори: Потребители с флаг
isCommentModeratorAdminсе таксуват отделно като SSO модератори (същата ставка като обикновените модератори)
Важно: За да се предотврати двойно таксуване, системата автоматично дедублира SSO потребители спрямо обикновени tenant потребители и модератори по имейл адрес. Ако SSO потребител има същия имейл като обикновен tenant потребител или модератор, той няма да бъде таксуван два пъти.
Контрол на достъпа
Потребителите могат да бъдат разделени на групи. За това служи полето groupIds и е незадължително.
@Споменавания
По подразбиране @споменаванията ще използват username за търсене на други sso потребители, когато се въведе символът @. Ако се използва displayName, тогава резултатите, съвпадащи с
username, ще бъдат игнорирани, когато има съвпадение за displayName, и резултатите от търсенето на @споменаване ще използват displayName.
Абонаменти
С FastComments потребителите могат да се абонират за страница, като щракнат върху иконата на камбанката в уиджета за коментари и щракнат върху Абониране.
При обикновен потребител изпращаме имейли за известия въз основа на техните настройки за известия.
При SSO потребители разделяме това за обратна съвместимост. Потребителите ще получават тези допълнителни имейли за известия за абонамент
само ако зададете optedInSubscriptionNotifications на true.
Значки
Можете да присвоявате значки на SSO потребители, като използвате свойството badgeConfig. Значките са визуални индикатори, които се появяват до името на потребителя в коментарите.
badgeIds- Масив от ID на значки за присвояване на потребителя. Те трябва да бъдат валидни ID на значки, създадени във вашия акаунт в FastComments. Ограничено до 30 значки.override- Ако е true, всички съществуващи значки, показвани в коментарите, ще бъдат заменени с предоставените. Ако е false или е пропуснато, предоставените значки ще бъдат добавени към съществуващите значки.update- Ако е true, свойствата за показване на значки ще бъдат актуализирани от конфигурацията на tenant всеки път, когато потребителят влезе.
GET /api/v1/sso-users 
Този маршрут връща SSO потребители на страници от 100. Пагинацията се предоставя чрез параметъра skip. Потребителите са сортирани по тяхната signUpDate и id.



GET /api/v1/sso-users/by-id/:id 
Този маршрут връща единичен SSO потребител по тяхното id.



GET /api/v1/sso-users/by-email/:email 
Този маршрут връща единичен SSO потребител по техния имейл.



PATCH /api/v1/sso-users/:id 
Този маршрут предоставя възможност за актуализиране на единичен SSO потребител.



POST /api/v1/sso-users 
Този маршрут предоставя създаването на единичен SSO потребител.
Опитът да създадете двама потребители с едно и също ID ще доведе до грешка.

В този пример указваме groupIds за контрол на достъпа, но това е незадължително.


Бележка за интеграция
Данните, подадени от API, могат да бъдат презаписани просто чрез подаване на различен SSO User HMAC payload. Например, ако зададете потребителско име чрез API, но след това подадете различно чрез SSO потока при зареждане на страницата, ние автоматично ще актуализираме потребителското му име.
Ние няма да актуализираме параметрите на потребителя в този поток, освен ако изрично не ги посочите или ги зададете на null (не undefined).
PUT /api/v1/sso-users/:id 
Този маршрут предоставя възможност за актуализиране на единичен SSO потребител.

В този пример указваме groupIds за контрол на достъпа, но това е незадължително.


DELETE /api/v1/sso-users/:id 
Този маршрут предоставя премахване на единичен SSO потребител по неговото id.
Обърнете внимание, че зареждането на уиджета за коментари отново с payload за този потребител просто ще създаде потребителя отново безпроблемно.
Изтриването на коментарите на потребителя е възможно чрез параметъра на заявката deleteComments. Обърнете внимание, че ако това е true:
- Всички коментари на потребителя ще бъдат изтрити на живо.
- Всички дъщерни (сега сираци) коментари ще бъдат изтрити или анонимизирани въз основа на конфигурацията на асоциираната страница на всеки коментар. Например, ако режимът на изтриване на нишка е "anonymize", тогава отговорите ще останат, а коментарите на потребителя ще бъдат анонимизирани. Това се прилага само когато
commentDeleteModeеRemove(стойността по подразбиране). creditsCostстава2.
Анонимизирани коментари
Можете да запазите коментарите на потребителя, но просто да ги анонимизирате, като зададете commentDeleteMode=1.
Ако коментарите на потребителя са анонимизирани, следните стойности се задават на null:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badgesisDeleted и isDeletedUser се задават на true.
При рендериране уиджетът за коментари ще използва DELETED_USER_PLACEHOLDER (по подразбиране: "[deleted]") за името на потребителя и DELETED_CONTENT_PLACEHOLDER за коментара. Те могат да бъдат персонализирани чрез UI за персонализиране на уиджета.
Примери



Структура на абонамент 
Обектът Subscription представлява абонамент за потребител.
Обектите Subscription се създават, когато потребител кликне върху камбанката за известия в уиджета за коментари и щракне върху "Абониране за тази страница".
Абонаментите могат да бъдат създадени и чрез API.
Наличието на обект Subscription причинява генерирането на обекти Notification и изпращането на имейли, когато нови коментари са оставени в корена на асоциираната страница,
за която е Subscription. Изпращането на имейли зависи от типа потребител. За обикновени потребители това зависи от optedInNotifications. За SSO потребители това зависи от optedInSubscriptionNotifications. Обърнете внимание, че някои приложения може да нямат концепцията за уеб достъпна страница, в този случай просто задайте urlId на
id на елемента, за който се абонирате (същата стойност за urlId, която бихте подали на уиджета за коментари).
Структурата на обекта Subscription е следната:

GET /api/v1/subscriptions/:id 
Този маршрут връща до 30 обекта Subscription, сортирани по createdAt, от най-новите.
Можете да филтрирате по userId. При SSO потребителският id е във формат <tenant id>:<user id>.



POST /api/v1/subscriptions 
Тази API крайна точка предоставя възможност за създаване на Subscription. Обърнете внимание, че потребител може да има само един абонамент на страница, тъй като повече е излишно, и опитът
да създадете повече от един абонамент за един и същи потребител за една и съща страница ще доведе до грешка.
Създаването на абонамент ще доведе до създаването на обекти Notification, когато нов коментар е оставен в корена на абонирания urlId (когато parentId на коментара е null).



DELETE /api/v1/subscriptions/:id 
Този маршрут изтрива единичен обект Subscription по id.



Структура на дневната употреба на тенанта 
Обектът TenantDailyUsage представлява използването за tenant за даден ден. Ако няма активност за даден tenant за даден
ден, този ден няма да има обект TenantDailyUsage.
Обектът TenantDailyUsage не е в реално време и може да е с минути назад от действителното използване.
Структурата на обекта TenantDailyUsage е следната:

GET /api/v1/tenant-daily-usage 
Този маршрут позволява търсене на използването на tenant по година, месец и ден. Могат да бъдат върнати до 365 обекта, а цената е 1 api кредит на 10 обекта.
Обектите в отговора са сортирани по датата, на която са създадени (най-старите първо).



Структура на тенант 
Tenant дефинира клиент на FastComments.com. Те могат да бъдат създадени чрез API от tenant-и с достъп до white labeling. White labeled tenant-и
не могат да създават други white labeled tenant-и (позволено е само едно ниво на влагане).
Структурата на обекта Tenant е следната:

GET /api/v1/tenants/:id 
Този маршрут връща единичен Tenant по id.



GET /api/v1/tenants 
Този API връща tenant-и, които се управляват от вашия tenant.
Пагинацията се предоставя чрез параметъра на заявката skip. Tenant-ите се връщат на страници от 100, подредени по signUpDate и id.
Цената се базира на броя върнати tenant-и, струващи 1 кредит на 10 върнати tenant-а.

Можете да дефинирате meta параметри на обектите Tenant и да търсите съвпадащи tenant-и. Например, за ключа someKey и мета стойността some-value, можем да
конструираме JSON обект с тази двойка ключ/стойност и след това да го URI кодираме като параметър на заявката за филтриране:



POST /api/v1/tenants 
Този маршрут предоставя възможност за добавяне на единичен Tenant.
Създаването на Tenant има следните ограничения:
nameе задължително.domainConfigurationе задължително.- Следните стойности не могат да бъдат предоставени при създаване на
Tenant:hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmount
signUpDateне може да бъде в бъдещето.nameне може да бъде по-дълго от200 символа.emailне може да бъде по-дълго от300 символа.emailтрябва да бъде уникален за всички tenant-и на FastComments.com.- Не можете да създавате tenant-и, ако родителският tenant няма дефиниран валиден
TenantPackage.- Ако вашият tenant е бил създаден чрез FastComments.com, това не би трябвало да е проблем.
- Не можете да създавате повече tenant-и от дефинираното под
maxWhiteLabeledTenantsвъв вашия пакет. - Трябва да посочите параметъра на заявката
tenantId, който е id на вашияродителски tenantс активиран white labeling.
Можем да създадем Tenant само с няколко параметъра:



PATCH /api/v1/tenants/:id 
Тази API крайна точка предоставя възможност за актуализиране на Tenant по id.
Актуализирането на Tenant има следните ограничения:
- Следните стойности не могат да бъдат актуализирани:
hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmountmanagedByTenantId
signUpDateне може да бъде в бъдещето.nameне може да бъде по-дълго от200 символа.emailне може да бъде по-дълго от300 символа.emailтрябва да бъде уникален за всички tenant-и на FastComments.com.- Когато задавате
billingInfoValidнаtrue,billingInfoтрябва да бъде предоставен в същата заявка. - Не можете да актуализирате
packageId, асоцииран с вашия собствен tenant. - Не можете да актуализирате
paymentFrequency, асоциирана с вашия собствен tenant.



DELETE /api/v1/tenants/:id 
Този маршрут предоставя премахване на Tenant и всички свързани данни (потребители, коментари и т.н.) по id.
Съществуват следните ограничения около премахването на tenant-и:
- Tenant-ът трябва да е ваш собствен или white labeled tenant, който управлявате.
- Параметърът на заявката
sureтрябва да е зададен наtrue.



Структура на пакет на тенанта 
TenantPackage дефинира информация за пакет, достъпна за Tenant. Tenant може да има много налични пакети, но само
един в употреба в даден момент.
Tenant не може да се използва за никакви продукти, докато неговият packageId не сочи към валиден TenantPackage.
Има два типа обекти TenantPackage:
- Пакети с фиксирана цена - където
hasFlexPricingе false. - Гъвкаво ценообразуване - където
hasFlexPricingе true.
И в двата случая се дефинират лимити на акаунта, използващ пакета, но при Flex tenant-ът се таксува базова цена плюс
това, което е използвал, дефинирано от flex* параметрите.
Tenant може да има множество tenant пакети и да има възможност сам да променя пакета от страницата за информация за фактуриране.
Ако ще се справяте сами с фактурирането за tenant-и, все пак ще трябва да дефинирате пакет за всеки tenant, за да дефинирате техните лимити. Просто задайте billingHandledExternally на true за Tenant и те
няма да могат сами да променят своята информация за фактуриране или активен пакет.
Не можете да създавате пакети с по-високи лимити от родителския tenant.
Структурата на обекта TenantPackage е следната:

GET /api/v1/tenant-packages/:id 
Този маршрут връща единичен Tenant Package по id.



GET /api/v1/tenant-packages 
Този API използва пагинация, предоставена чрез параметъра на заявката skip. TenantPackages се връщат на страници от 100, подредени по createdAt и id.
Цената се базира на броя върнати tenant пакети, струващи 1 кредит на 10 върнати tenant пакета.



POST /api/v1/tenant-packages 
Този маршрут предоставя възможност за добавяне на единичен TenantPackage.
Създаването на TenantPackage има следните ограничения:
- Следните параметри са задължителни:
nametenantIdmonthlyCostUSD- Може да бъде null.yearlyCostUSD- Може да бъде null.maxMonthlyPageLoadsmaxMonthlyAPICreditsmaxMonthlyCommentsmaxConcurrentUsersmaxTenantUsersmaxSSOUsersmaxModeratorsmaxDomainshasDebrandingforWhoTextfeatureTaglineshasFlexPricing- Ако е true, тогава всичкиflex*параметри са задължителни.
nameне може да бъде по-дълго от50 символа.- Всеки елемент на
forWhoTextне може да бъде по-дълъг от200 символа. - Всеки елемент на
featureTaglinesне може да бъде по-дълъг от100 символа. TenantPackageтрябва да бъде "по-малък" от родителския tenant. Например, всичкиmax*параметри трябва да имат по-ниски стойности от родителския tenant.- White labeled tenant може да има максимум пет пакета.
- Само tenant-и с достъп до white labeling могат да създават
TenantPackage. - Не можете да добавяте пакети към вашия собствен tenant. :)
Можем да създадем TenantPackage по следния начин:



PATCH /api/v1/tenant-packages/:id 
Тази API крайна точка предоставя възможност за актуализиране на TenantPackage по id.
Актуализирането на TenantPackage има следните ограничения:
- Ако задавате
hasFlexPricingна true, тогава всичкиflex*параметри са задължителни в същата заявка. nameне може да бъде по-дълго от50 символа.- Всеки елемент на
forWhoTextне може да бъде по-дълъг от200 символа. - Всеки елемент на
featureTaglinesне може да бъде по-дълъг от100 символа. TenantPackageтрябва да бъде "по-малък" от родителския tenant. Например, всичкиmax*параметри трябва да имат по-ниски стойности от родителския tenant.- Не можете да променяте
tenantId, асоцииран сTenantPackage.



DELETE /api/v1/tenant-packages/:id 
Този маршрут предоставя премахване на TenantPackage по id.
Не можете да премахнете TenantPackage, който се използва (packageId на tenant сочи към пакета). Първо актуализирайте Tenant.



Структура на потребител на тенанта 
TenantUser дефинира User, който се управлява от конкретен tenant. Акаунтът им е под пълен контрол на tenant-а,
с който са асоциирани, и техният акаунт може да бъде актуализиран или изтрит чрез UI или API.
Tenant потребителите могат да бъдат администратори с всички права и достъп до Tenant, или могат да бъдат ограничени до конкретни права за
модериране на коментари, достъп до API ключове и т.н.
Структурата на обекта TenantUser е следната:

GET /api/v1/tenant-users/:id 
Този маршрут връща единичен TenantUser по id.



GET /api/v1/tenant-users 
Този API използва пагинация, предоставена чрез параметъра на заявката skip. TenantUsers се връщат на страници от 100, подредени по signUpDate, username и id.
Цената се базира на броя върнати tenant потребители, струващи 1 кредит на 10 върнати tenant потребители.



POST /api/v1/tenant-users 
Този маршрут предоставя възможност за добавяне на единичен TenantUser.
Създаването на TenantUser има следните ограничения:
usernameе задължително.emailе задължително.signUpDateне може да бъде в бъдещето.localeтрябва да бъде в списъка на Поддържани локали.usernameтрябва да бъде уникално в целия FastComments.com. Ако това е проблем, предлагаме да използвате SSO вместо това.emailтрябва да бъде уникален в целия FastComments.com. Ако това е проблем, предлагаме да използвате SSO вместо това.- Не можете да създавате повече tenant потребители от дефинираното под
maxTenantUsersвъв вашия пакет.
Можем да създадем TenantUser по следния начин



POST /api/v1/tenant-users/:id/send-login-link 
Този маршрут предоставя възможност за изпращане на линк за вход на единичен TenantUser.
Полезно е при групово създаване на потребители, без да се налага да им обяснявате как да влязат във FastComments.com. Това просто ще им изпрати "магически линк" за вход, който
изтича след 30 дни.
Съществуват следните ограничения за изпращане на линк за вход на TenantUser:
TenantUserтрябва вече да съществува.- Трябва да имате достъп за управление на
Tenant, към който принадлежиTenantUser.
Можем да изпратим линк за вход на TenantUser по следния начин:

Това ще изпрати имейл като Bob от TenantName ви кани да бъдете модератор...


PATCH /api/v1/tenant-users/:id 
Този маршрут предоставя възможност за актуализиране на единичен TenantUser.
Актуализирането на TenantUser има следните ограничения:
signUpDateне може да бъде в бъдещето.localeтрябва да бъде в списъка на Поддържани локали.usernameтрябва да бъде уникално в целия FastComments.com. Ако това е проблем, предлагаме да използвате SSO вместо това.emailтрябва да бъде уникален в целия FastComments.com. Ако това е проблем, предлагаме да използвате SSO вместо това.- Не можете да актуализирате
tenantIdна потребител.
Можем да създадем TenantUser по следния начин



DELETE /api/v1/tenant-users/:id 
Този маршрут предоставя премахване на TenantUser по id.
Изтриването на коментарите на потребителя е възможно чрез параметъра на заявката deleteComments. Обърнете внимание, че ако това е true:
- Всички коментари на потребителя ще бъдат изтрити на живо.
- Всички дъщерни (сега сираци) коментари ще бъдат изтрити или анонимизирани въз основа на конфигурацията на асоциираната страница на всеки коментар. Например, ако режимът на изтриване на нишка е "anonymize", тогава отговорите ще останат, а коментарите на потребителя ще бъдат анонимизирани. Това се прилага само когато
commentDeleteModeеRemove(стойността по подразбиране). creditsCostстава2.
Анонимизирани коментари
Можете да запазите коментарите на потребителя, но просто да ги анонимизирате, като зададете commentDeleteMode=1.
Ако коментарите на потребителя са анонимизирани, следните стойности се задават на null:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badgesisDeleted и isDeletedUser се задават на true.
При рендериране уиджетът за коментари ще използва DELETED_USER_PLACEHOLDER (по подразбиране: "[deleted]") за името на потребителя и DELETED_CONTENT_PLACEHOLDER за коментара. Те могат да бъдат персонализирани чрез UI за персонализиране на уиджета.
Примери



Структура на потребителя 
User е обект, който представлява най-общ знаменател на всички потребители.
Имайте предвид, че във FastComments имаме множество различни случаи на употреба за потребители:
- Сигурно SSO
- Просто SSO
- Tenant потребители (Например: Администратори)
- Коментатори
Този API е за Коментатори и потребители, създадени чрез Просто SSO. По същество всеки потребител, създаден
чрез вашия сайт, може да бъде достъпен чрез този API. Tenant потребители също могат да бъдат извлечени по този начин, но ще получите повече информация, като взаимодействате с API /tenant-users/.
За Сигурно SSO моля използвайте API /sso-users/.
Не можете да актуализирате тези типове потребители. Те са създали акаунта си чрез вашия сайт, така че предоставяме някакъв базов достъп само за четене, но
не можете да правите промени. Ако искате да имате такъв тип поток - трябва да настроите Сигурно SSO.
Структурата на обекта User е следната:

GET /api/v1/users/:id 
Този маршрут връща единичен User по id.



Структура на глас 
Обектът Vote представлява глас, оставен от потребител.
Връзката между коментари и глас се дефинира чрез commentId.
Структурата на обекта Vote е следната:

GET /api/v1/votes 
Гласовете трябва да бъдат извлечени по urlId.
Типове гласове
Има три типа гласове:
- Удостоверени гласове, които се прилагат към съответния коментар. Можете да ги създадете чрез този API.
- Удостоверени гласове, които са в очакване на верификация и следователно все още не са приложени към коментара. Те се създават, когато потребител използва механизма влизане за гласуване на FastComments.com.
- Анонимни гласове, които се прилагат към съответния коментар. Те се създават заедно с анонимното коментиране.
Те се връщат в отделни списъци в API, за да се намали объркването.



Бележки за анонимни гласове
Обърнете внимание, че анонимните гласове, създадени чрез този API, ще се появят в списъка appliedAuthorizedVotes. Те се считат за оторизирани, тъй като са създадени чрез API с API ключ.
Структурата appliedAnonymousVotes е за гласове, създадени без имейл, API ключ и т.н.
GET /api/v1/votes/for-user 
Позволява извличане на гласове, оставени от потребител за даден urlId. Приема userId, който може да бъде всеки потребител на FastComments.com или SSO User.
Това е полезно, ако искате да покажете дали потребител е гласувал за коментар. Когато извличате коментари, просто извикайте този API едновременно за потребителя със
същия urlId.
Ако използвате анонимно гласуване, ще искате да подадете anonUserId вместо това.


Обърнете внимание, че анонимните гласове ще се появят в списъка appliedAuthorizedVotes. Те се считат за оторизирани, тъй като са създадени чрез API с API ключ.


POST /api/v1/votes 
Този маршрут предоставя възможност за добавяне на единичен оторизиран Vote. Гласовете могат да бъдат up (+1) или down (-1).




Създаване на анонимни гласове
Анонимни гласове могат да бъдат създадени чрез задаване на anonUserId в параметрите на заявката вместо userId.
Този id не трябва да съответства на потребителски обект никъде (оттук анонимен). Това е просто идентификатор за сесията, така че да можете да извлечете гласовете отново в същата сесия, за да проверите дали даден коментар е бил гласуван.
Ако нямате такова нещо като "анонимни сесии" както FastComments - можете просто да зададете това на случаен ID, като UUID (въпреки че оценяваме по-малки идентификатори за спестяване на място).
Други бележки
- Този API се подчинява на настройките на ниво tenant. Например, ако деактивирате гласуването за дадена страница и се опитате да създадете глас чрез API, то ще се провали с код на грешка
voting-disabled. - Този API е на живо по подразбиране.
- Този API ще актуализира
votesна съответнияComment.
DELETE /api/v1/votes/:id 
Този маршрут предоставя възможност за изтриване на единичен Vote.



Бележки:
- Този API се подчинява на настройките на ниво tenant. Например, ако деактивирате гласуването за дадена страница и се опитате да създадете глас чрез API, то ще се провали с код на грешка
voting-disabled. - Този API е на живо по подразбиране.
- Този API ще актуализира
votesна съответнияComment.
Структура на конфигурация на домейн 
Обектът DomainConfig представлява конфигурация за домейн за tenant.
Структурата на обекта DomainConfig е следната:


За удостоверяване
Конфигурацията на домейна се използва за определяне кои сайтове могат да хостват уиджета FastComments за вашия акаунт. Това е основна форма на удостоверяване, което означава, че добавянето или премахването на каквито и да е конфигурации на домейни може да повлияе на наличността на вашата инсталация на FastComments в продукция.
Не премахвайте или актуализирайте свойството domain на Domain Config за домейн, който в момента се използва, освен ако деактивирането на този домейн е предвидено.
Това има същото поведение като премахването на домейн от /auth/my-account/configure-domains.
Също така имайте предвид, че премахването на домейн от потребителския интерфейс My Domains ще премахне всяка съответна конфигурация за този домейн, която може да е била добавена чрез този потребителски интерфейс.
За персонализация на имейли
Връзката за отписване в долния колонтитул на имейла и функцията за отписване с едно щракване, предлагана от много имейл клиенти, могат да бъдат конфигурирани чрез този API, като дефинирате съответно footerUnsubscribeURL и emailHeaders.
За DKIM
След като дефинирате вашите DKIM DNS записи, просто актуализирайте DomainConfig с вашата DKIM конфигурация, като използвате дефинираната структура.
GET /api/v1/domain-configs 
Този API предоставя възможност за извличане на всички обекти DomainConfig за tenant.



GET /api/v1/domain-configs/:domain 
Индивидуални DomainConfigs могат да бъдат извлечени по съответния им domain.



POST /api/v1/domain-configs 
Тази API крайна точка предоставя възможност за създаване на конфигурации на домейни.
Добавянето на конфигурация за домейн оторизира този домейн за акаунта FastComments.
Често срещани случаи на употреба на този API са първоначална настройка, ако се желае добавяне на много домейни, или персонализирана конфигурация за изпращане на имейли.



PATCH /api/v1/domain-configs/:domain 
Тази API крайна точка предоставя възможност за актуализиране на конфигурация на домейн, като посочите само домейна и атрибута за актуализиране.



PUT /api/v1/domain-configs/:domain 
Тази API крайна точка предоставя възможност за замяна на конфигурация на домейн.



DELETE /api/v1/domain-configs/:domain 
Този маршрут предоставя премахването на единичен DomainConfig по id.
- Забележка: Премахването на
DomainConfigще деоторизира този домейн от използването на FastComments. - Забележка: Повторното добавяне на домейн чрез потребителския интерфейс ще пресъздаде обекта (само с попълнен
domain).



Структура на конфигурация на въпрос 
FastComments предоставя начин за конструиране на въпроси и агрегиране на техните резултати. Пример за въпрос (наричан по-нататък QuestionConfig)
може да бъде звездна оценка, плъзгач или NPS въпрос (определен чрез type).
Данните от въпросите могат да бъдат агрегирани индивидуално, заедно, във времето, общо, по страница и така нататък.
Рамката има всички възможности, необходими за изграждане на уиджети от клиентска страна (с вашия сървър пред този API), административни табла и инструменти за отчетност.
Първо трябва да дефинираме QuestionConfig. Структурата е следната:

GET /api/v1/question-configs 
Този маршрут връща до 100 обекта QuestionConfig наведнъж, пагинирани. Цената е 1 за всеки 100 обекта. Те са
сортирани по текста на въпроса във възходящ ред (поле question).



GET /api/v1/question-configs/:id 
Този маршрут връща единичен QuestionConfig по неговото id.



POST /api/v1/question-configs 
Тази API крайна точка предоставя възможност за създаване на QuestionConfig.



PATCH /api/v1/question-configs/:id 
Този маршрут предоставя възможност за актуализиране на единичен QuestionConfig.
Следната структура представлява всички стойности, които могат да бъдат променени:




DELETE /api/v1/question-configs/:id 
Този маршрут предоставя премахване на QuestionConfig по id.
Това ще изтрие всички съответни резултати от въпроси (но не и коментарите). Това е част от високата цена на кредитите.



Структура на резултат от въпрос 
За да запазите резултати от въпроси, създавате QuestionResult. След това можете да агрегирате резултатите от въпросите и също
да ги свържете с коментари за целите на отчетността.

GET /api/v1/question-results 
Този маршрут връща до 1000 обекта QuestionResults наведнъж, пагинирани. Цената е 1 за всеки 100 обекта. Те са
сортирани по createdAt, във възходящ ред. Можете да филтрирате по различни параметри.



GET /api/v1/question-results/:id 
Този маршрут връща единичен QuestionResult по неговото id.



POST /api/v1/question-results 
Тази API крайна точка предоставя възможност за създаване на QuestionResult.



PATCH /api/v1/question-results/:id 
Този маршрут предоставя възможност за актуализиране на единичен QuestionResult.
Следната структура представлява всички стойности, които могат да бъдат променени:




DELETE /api/v1/question-results/:id 
Този маршрут предоставя премахване на QuestionResult по id.



GET /api/v1/question-results-aggregate 
Тук се извършва агрегирането на резултати.
Структурата на отговора за агрегиране е следната:

Ето наличните параметри на заявката за агрегиране:

Ето примерна заявка:

Примерен отговор:


Бележки за производителност
- При пропуск на кеша агрегациите обикновено отнемат пет секунди на милион резултата.
- В противен случай заявките са с константно време.
Бележки за кеширане и цена
- Когато е указано
forceRecalculate, цената винаги е10вместо нормалните2. - Ако кешът изтече и данните се преизчисляват, цената все още е константа
2, акоforceRecalculateне е указано. Кешът изтича въз основа на размера на агрегирания набор от данни (може да варира между 30 секунди и 5 минути). - Това е за да се стимулира използването на кеша.
GET /api/v1/question-results-aggregate/combine/comments 
Тук се извършва комбинирането на резултати с коментари. Полезно е за създаване на диаграма "скорошни положителни и отрицателни коментари" за продукт, например.
Можете да търсите чрез диапазон от стойности (включително), един или повече въпроса и по начална дата (включително).
Структурата на отговора е следната:

Ето наличните параметри на заявката за агрегиране:

Ето примерна заявка:

Примерен отговор:


Бележки за кеширане и цена
- Когато е указано
forceRecalculate, цената винаги е10вместо нормалните2. - Ако кешът изтече и данните се преизчисляват, цената все още е константа
2, акоforceRecalculateне е указано. - Това е за да се стимулира използването на кеша.
Структура на потребителска значка 
UserBadge е обект, който представлява значка, присвоена на потребител в системата FastComments.
Значки могат да бъдат присвоявани на потребители автоматично въз основа на тяхната активност (като брой коментари, време за отговор, ветерански статус) или ръчно от администраторите на сайта.
Структурата на обекта UserBadge е следната:

GET /api/v1/user-badges 
Тази крайна точка ви позволява да извличате потребителски значки въз основа на различни критерии.
Примерна заявка:
Run 
Можете да добавите различни параметри на заявката за филтриране на резултатите:
userId- Вземете значки за конкретен потребителbadgeId- Вземете инстанции на конкретна значкаtype- Филтриране по тип значка (0=CommentCount, 1=CommentUpVotes, 2=CommentReplies и т.н. Вижте структурата на UserBadge за пълен списък)displayedOnComments- Филтриране по това дали значката се показва в коментарите (true/false)limit- Максимален брой значки за връщане (по подразбиране 30, максимум 200)skip- Брой значки за пропускане (за пагинация)
Примерен отговор:

Възможни отговори за грешка:


GET /api/v1/user-badges/:id 
Тази крайна точка ви позволява да извлечете конкретна потребителска значка по нейния уникален ID.
Примерна заявка:
Run 
Примерен отговор:

Възможни отговори за грешка:


POST /api/v1/user-badges 
Тази крайна точка ви позволява да създадете ново присвояване на потребителска значка.
Примерна заявка:
Run 
Тялото на заявката трябва да съдържа следните параметри:
userId(задължително) - ID на потребителя, на когото да се присвои значкатаbadgeId(задължително) - ID на значката за присвояванеdisplayedOnComments(незадължително) - Дали значката да се показва в коментарите на потребителя (по подразбиране true)
Важни бележки:
- Значката трябва да съществува и да е активирана в каталога на значките на вашия tenant
- Можете да присвоявате значки само на потребители, които принадлежат към вашия tenant или са коментирали на вашия сайт
Примерен отговор:

Възможни отговори за грешка:





PUT /api/v1/user-badges/:id 
Тази крайна точка ви позволява да актуализирате присвояване на потребителска значка.
В момента единственото свойство, което може да бъде актуализирано, е displayedOnComments, което контролира дали значката се показва в коментарите на потребителя.
Примерна заявка:
Run 
Примерен отговор:

Възможни отговори за грешка:



DELETE /api/v1/user-badges/:id 
Тази крайна точка ви позволява да изтриете присвояване на потребителска значка.
Примерна заявка:
Run 
Примерен отговор:

Възможни отговори за грешка:



Структура на напредъка на потребителска значка 
UserBadgeProgress е обект, който представлява напредъка на потребител към спечелване на различни значки в системата FastComments.
Това проследяване помага да се определи кога потребителите трябва да получат автоматични значки въз основа на тяхната активност и участие във вашата общност.
Структурата на обекта UserBadgeProgress е следната:

GET /api/v1/user-badge-progress 
Тази крайна точка ви позволява да извличате записи за напредък на потребителски значки въз основа на различни критерии.
Примерна заявка:
Run 
Можете да добавите различни параметри на заявката за филтриране на резултатите:
userId- Вземете напредъка за конкретен потребителlimit- Максимален брой записи за връщане (по подразбиране 30, максимум 200)skip- Брой записи за пропускане (за пагинация)
Примерен отговор:

Възможни отговори за грешка:


GET /api/v1/user-badge-progress/:id 
Тази крайна точка ви позволява да извлечете конкретен запис за напредък на потребителска значка по неговия уникален ID.
Примерна заявка:
Run 
Примерен отговор:

Възможни отговори за грешка:


GET /api/v1/user-badge-progress/user/:userId 
Тази крайна точка ви позволява да извлечете запис за напредък на значка на потребител по техния потребителски ID.
Примерна заявка:
Run 
Примерен отговор:

Възможни отговори за грешка:



В заключение
Надяваме се, че нашата API документация е била изчерпателна и лесна за разбиране. Ако откриете пропуски, уведомете ни по-долу.