
Мова 🇺🇦 Українська
Ресурси API
Агрегації
Журнали аудиту
Коментарі
Шаблони електронної пошти
Хештеги
Модератори
Кількість сповіщень
Сповіщення
Сторінки
Очікувані події вебхуків
Користувачі SSO
Підписки
Щоденне використання орендаря
Орендарі
Пакети орендарів
Користувачі орендарів
Користувачі
Голоси
Налаштування домену
Налаштування запитань
Результати запитань
Агрегація результатів запитань
Значки користувачів
Прогрес значків користувача
API FastComments
FastComments надає API для взаємодії з багатьма ресурсами. Створюйте інтеграції з нашою платформою або навіть пишіть власні клієнти!
У цій документації ви знайдете всі ресурси, що підтримуються API, задокументовані разом із типами запитів і відповідей.
Для корпоративних (Enterprise) клієнтів увесь доступ до API фіксується в журналі аудиту.
Згенеровані SDK
FastComments тепер генерує API Spec з нашого коду (це ще не завершено, але включає багато API).
Також тепер у нас є SDK для популярних мов:
- fastcomments-cpp
- fastcomments-go
- fastcomments-java
- fastcomments-sdk-js
- fastcomments-nim
- fastcomments-php
- fastcomments-php-sso
- fastcomments-python
- fastcomments-ruby
- fastcomments-rust
- fastcomments-swift
Аутентифікація
Доступ до API аутентифікується шляхом передачі вашого api key у вигляді заголовка X-API-KEY або як параметра запиту API_KEY. Вам також знадобиться ваш tenantId для викликів API. Його можна отримати на тій же сторінці, що й ваш api key.
Примітка щодо безпеки
Ці маршрути призначені для виклику з серверу. НЕ викликайте їх з браузера. Це розкриє ваш API-ключ — це надасть повний доступ до вашого облікового запису будь-кому, хто може переглянути вихідний код сторінки!
Варіант аутентифікації 1 — Заголовки
- Заголовок:
X-API-KEY - Заголовок:
X-TENANT-ID
Варіант аутентифікації 2 — Параметри запиту
- Параметр запиту:
API_KEY - Параметр запиту:
tenantId
Ресурси API 
Використання ресурсів
Слід зауважити, що отримання даних з API рахується як використання для вашого облікового запису.
Кожен ресурс вказує, яке саме використання він спричиняє, у відповідному розділі.
Деякі ресурси вимагають більше ресурсів для обслуговування, ніж інші. Кожна кінцева точка має фіксовану вартість у кредитах за виклик API. Для деяких кінцевих точок кількість кредитів може змінюватися залежно від опцій і розміру відповіді.
Використання API можна переглянути на сторінці Аналітика білінгу, і воно оновлюється кожні кілька хвилин.
Примітка!
Рекомендуємо спочатку ознайомитися з документацією Pages, щоб зменшити плутанину при визначенні, які значення передавати для urlId у Comment API.
Агрегація даних 
Цей API агрегує документи, групуючи їх (якщо groupBy надано) і застосовуючи кілька операцій. Підтримуються різні операції (наприклад, sum, countDistinct, avg тощо).
Вартість є змінною. Кожні 500 об'єктів, що скануються, коштують 1 кредит API.
За замовчуванням максимальне використання пам'яті на один виклик API становить 64MB, і за замовчуванням ви можете мати лише одну агрегацію, що працює одночасно. Якщо ви надішлете кілька агрегацій одночасно, вони будуть поставлені в чергу й виконані в порядку надходження. Очікувані агрегації чекатимуть максимум 60 секунд, після чого запит завершиться тайм-аутом. Окремі агрегації можуть виконуватися до 5 хвилин.
Якщо у вас є managed tenants, ви можете агрегувати всі ресурси дочірніх tenants в одному виклику, передавши параметр запиту parentTenantId.
Приклади
Приклад: Підрахунок унікальних


Приклад: Підрахунок різних

Відповідь:

Приклад: Сума значень кількох полів

Відповідь:

Приклад: Середні значення кількох полів

Відповідь:

Приклад: Мінімальні/максимальні значення кількох полів

Відповідь:

Приклад: Підрахунок унікальних значень кількох полів

Відповідь:

Приклад: Створення запиту

Відповідь:

Приклад: Підрахунок коментарів, що очікують перевірки

Відповідь:

Приклад: Розподіл схвалених, перевірених та спам-коментарів

Відповідь:

Структури


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

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



Структура коментаря 
Об'єкт Comment представляє коментар, залишений користувачем.
Взаємовідносини між батьківськими та дочірніми коментарями визначаються через parentId.
Структура об'єкта Comment наступна:

Деякі з цих полів позначені як READONLY — вони повертаються API, але їх не можна встановити.
Структура тексту коментаря
Коментарі пишуться у власному діалекті markdown від FastComments, який є стандартним markdown плюс традиційні bbcode-подібні теги для зображень, такі як [img]path[/img].
Текст зберігається у двох полях. Текст, який ввів користувач, зберігається без змін у полі comment. Його відрендерений варіант зберігається у полі commentHTML.
Дозволені HTML-теги: b, u, i, strike, pre, span, code, img, a, strong, ul, ol, li, and br.
Рекомендується рендерити HTML, оскільки це дуже невеликий піднабір HTML, і створити рендерер досить просто. Існує кілька бібліотек, наприклад для React Native і Flutter, які можуть у цьому допомогти.
Ви можете обрати рендеринг ненормалізованого значення поля comment. Приклад парсера тут..
Приклад парсера також можна налаштувати для роботи з HTML і перетворювати HTML-теги у очікувані елементи для рендерингу на вашій платформі.
Тегування
Коли користувачів згадують у коментарі, інформація зберігається у списку mentions. Кожен об'єкт у цьому списку має таку структуру.
Run 
Хештеги
Коли хештеги використовуються і успішно розпізнаються, інформація зберігається в масиві hashTags. Кожен об'єкт у цьому масиві має таку структуру. Хештеги також можна додавати вручну в масив hashTags коментаря для запитів, якщо встановлено retain.
Run 
GET /api/v1/comments 
Цей API використовується для отримання коментарів для відображення користувачу. Наприклад, він автоматично відфільтровує непідтверджені або спам-коментарі.
Pagination
Пагінація може здійснюватися одним із двох способів, залежно від вимог до продуктивності та випадку використання:
- Найшвидший: Попередньо обчислена пагінація:
- Так працює FastComments, коли ви використовуєте наші готові віджети та клієнти.
- Натискання "next" просто збільшує номер сторінки.
- Це можна уявити як отримання з key-value сховища.
- У цьому випадку просто визначте параметр
page, що починається з0, та напрям сортування якdirection. - Розміри сторінок можна налаштовувати через правила кастомізації.
- Найгнучкіший: Гнучка пагінація:
- У цьому випадку ви можете визначити кастомні параметри
limitіskip. Не передавайтеpage. - Підтримується також напрям сортування
direction. limit— це загальна кількість для повернення після застосуванняskip.- Приклад: встановіть
skip = 200, limit = 100, колиpage size = 100іpage = 2.
- Приклад: встановіть
- Дочірні коментарі все одно враховуються в пагінації. Ви можете обійти це, використавши опцію
asTree.- Ви можете здійснювати пагінацію дітей через
limitChildrenіskipChildren. - Ви можете обмежити глибину повернутих тредів за допомогою
maxTreeDepth.
- Ви можете здійснювати пагінацію дітей через
- У цьому випадку ви можете визначити кастомні параметри
Threads
- При використанні
Precalculated Paginationкоментарі групуються за сторінкою, і коментарі в тредах впливають на загальну сторінку.- У цьому випадку треди можна визначити на клієнті на основі
parentId. - Наприклад, на сторінці з одним коментарем верхнього рівня та 29 відповідями, і встановивши
page=0в API — ви отримаєте тільки верхній рівень та 29 дочірніх. - Приклад зображення, що ілюструє кілька сторінок.
- У цьому випадку треди можна визначити на клієнті на основі
- При використанні
Flexible Paginationви можете визначити параметрparentId.- Встановіть його в null, щоб отримати лише коментарі верхнього рівня.
- Потім, щоб переглянути треди, викличте API ще раз і передайте
parentId. - Звичне рішення — зробити виклик API для коментарів верхнього рівня, а потім паралельні виклики API, щоб отримати коментарі для дітей кожного коментаря.
- НОВИНКА станом на лютий 2023! Отримуйте у вигляді дерева, використовуючи
&asTree=true.- Це можна уявити як
Гнучка пагінація у вигляді дерева. - У пагінації враховуються тільки коментарі верхнього рівня.
- Встановіть
parentId=null, щоб почати дерево з кореня (ви повинні встановитиparentId). - Встановіть
skipіlimitдля пагінації. - Встановіть
asTreeвtrue. - Вартість в кредитах збільшується в
2x, оскільки наш бекенд повинен виконати набагато більше роботи в цьому сценарії. - Встановіть
maxTreeDepth,limitChildrenіskipChildrenза потреби.
- Це можна уявити як
Trees Explained
Коли використовується asTree, зрозуміти пагінацію може бути складно. Ось корисна схема:
Fetching Comments in The Context of a User
API /comments може використовуватися в двох контекстах, для різних випадків використання:
- Для повернення коментарів, відсортованих та позначених інформацією для побудови власного клієнта.
- У цьому випадку визначте параметр запиту
contextUserId.
- У цьому випадку визначте параметр запиту
- Для отримання коментарів з вашого бекенду для кастомних інтеграцій.
- Платформа за замовчуванням використовуватиме цей варіант без
contextUserId.
- Платформа за замовчуванням використовуватиме цей варіант без




Get Comments as a Tree
Можна отримати коментарі у вигляді дерева, причому в пагінації враховуються лише коментарі верхнього рівня.

Хочете отримати лише коментарі верхнього рівня та їхніх безпосередніх дочірніх? Ось один зі способів:

Однак у вашому інтерфейсі може знадобитися знати, чи показувати кнопку «show replies» під кожним коментарем. Під час отримання коментарів у вигляді дерева до коментарів додається властивість hasChildren, коли це застосовно.
Get Comments as a Tree, Searching by Hash Tag
Можна шукати за хештегом через API по всьому вашому орендарю (не обмежуючись однією сторінкою або urlId).
У цьому прикладі ми опускаємо urlId і шукаємо за кількома хештегами. API поверне лише ті коментарі, які містять усі запитані хештеги.

All Request Params

The Response

Helpful Tips
URL ID
Ймовірно, ви захочете використовувати API Comment з параметром urlId. Ви можете спочатку викликати API Pages, щоб побачити, як виглядають доступні для вас значення urlId.
Anonymous Actions
Для анонімного коментування ймовірно варто передавати anonUserId під час отримання коментарів, а також під час виконання флагування та блокування.
(!) Це обов'язково для багатьох магазинів застосунків, оскільки користувачі повинні мати можливість позначати контент, створений користувачами, який вони бачать, навіть якщо вони не увійшли в систему. Невиконання цього може призвести до видалення вашого застосунку з відповідного магазину.
Comments Not Being Returned
Перевірте, що ваші коментарі схвалені і не є спамом.
GET /api/v1/comments/:id 
Цей API надає можливість отримати один коментар за id.



POST /api/v1/comments 
Цей API-ендпоінт надає можливість створювати коментарі.
Типові варіанти використання: кастомні інтерфейси, інтеграції або імпорти.
Примітки:
- Цей API може оновлювати віджет коментарів "live" за бажанням (це збільшує
creditsCostз1до2). - Якщо вказано email, цей API автоматично створить об'єкти користувачів у нашій системі.
- Спроба зберегти два коментарі з різними email, але однаковим іменем користувача, призведе до помилки для другого коментаря.
- Якщо ви вказуєте
parentId, і дочірній коментар маєnotificationSentForParentзі значенням false, ми відправимо повідомлення для батьківського коментаря. Це робиться щогодини (ми групуємо повідомлення, щоб зменшити кількість відправлених електронних листів). - Якщо ви хочете надсилати вітальні листи при створенні користувачів або листи для верифікації коментарів, встановіть
sendEmailsвtrueу параметрах запиту. - Коментарі, створені через цей API, відображатимуться на сторінках Аналітики та Модерації в адмін-додатку.
- Якщо налаштування увімкнено, "bad words" все ще маскуються в іменах коментаторів та в тексті коментаря.
- Коментарі, створені через цей API, все ще можуть перевірятися на спам за бажанням.
- Налаштування, такі як максимальна довжина коментаря, якщо вони вказані через сторінку правил кастомізації в адмін-панелі, застосовуватимуться тут.
Мінімальні дані, необхідні для відправки і відображення у віджеті коментарів, такі:

Більш реальний запит може виглядати так:



PATCH /api/v1/comments/:id 
Цей кінцевий пункт API надає можливість оновити один коментар.
Notes:
- Цей API може оновлювати віджет коментарів "live", якщо потрібно (це збільшує базовий
creditsCostз1до2).- Це дозволяє робити міграцію коментарів між сторінками "live" (зміна
urlId). - Міграції коштують додаткових
2кредити, оскільки сторінки попередньо обчислюються і це інтенсивно використовує CPU.
- Це дозволяє робити міграцію коментарів між сторінками "live" (зміна
- На відміну від API створення, цей API НЕ буде автоматично створювати об'єкти користувача в нашій системі, якщо надано email.
- Коментарі, оновлені через цей API, все ще можуть перевірятися на спам за бажанням.
- Налаштування, такі як максимальна довжина коментаря, якщо вони налаштовані через сторінку адміністратора Customization Rule, застосовуватимуться тут.
- Щоб дозволити користувачам оновлювати текст свого коментаря, ви можете просто вказати
commentу тілі запиту. Ми згенеруємо відповіднийcommentHTML.- Якщо ви визначите і
comment, іcommentHTML, ми не будемо автоматично генерувати HTML. - Якщо користувач додасть згадки або хештеги у свій новий текст, вони все одно будуть оброблені так само, як у
POSTAPI.
- Якщо ви визначите і
- Під час оновлення
commenterEmailу коментарі найкраще також вказатиuserId. Інакше ви повинні переконатися, що користувач з цим email належить вашому tenant, інакше запит зазнає невдачі.



DELETE /api/v1/comments/:id 
Ця кінцева точка API надає можливість видалити коментар.
Примітки:
- Цей API може оновлювати віджет коментарів у режимі реального часу, якщо потрібно (це збільшує
creditsCostз1до2). - Цей API видалить всі дочірні коментарі.



POST /api/v1/comments/:id/flag 
Цей API-ендпоінт дозволяє позначити коментар для конкретного користувача.
Примітки:
- Цей виклик завжди має виконуватися в контексті користувача. Користувач може бути користувачем FastComments.com, SSO-користувачем або користувачем орендаря.
- Якщо встановлено поріг flag-to-hide, коментар буде автоматично приховано в реальному часі після того, як його позначать визначену кількість разів.
- Після того, як він автоматично буде знятий зі схвалених (прихований) — коментар може бути повторно схвалений лише адміністратором або модератором. Зняття позначки (un-flagging) не призведе до повторного схвалення коментаря.

Для анонімного позначення потрібно вказати anonUserId. Це може бути ідентифікатор, який представляє анонімну сесію, або випадковий UUID.
Це дозволяє підтримувати позначення та зняття позначки з коментарів навіть якщо користувач не увійшов у систему. Таким чином, коментар може бути позначений як flagged, коли коментарі витягуються з тим самим anonUserId.



POST /api/v1/comments/:id/un-flag 
Цей API-ендпоінт надає можливість зняти позначку з коментаря для конкретного користувача.
Примітки:
- Цей виклик завжди має виконуватися в контексті користувача. Користувач може бути FastComments.com User, SSO User, або Tenant User.
- Після того, як коментар було автоматично відхилено (приховано), його можна повторно схвалити лише адміністратором або модератором. Зняття позначки не призведе до повторного схвалення коментаря.

Для анонімного позначення необхідно вказати anonUserId. Це може бути ідентифікатор, що представляє анонімну сесію, або випадковий UUID.



POST /api/v1/comments/:id/block 
Цей API-ендпоінт надає можливість заблокувати користувача, який написав певний коментар. Підтримується блокування коментарів, написаних користувачами FastComments.com, SSO-користувачами та користувачами орендаря.
Підтримується параметр тіла commentIdsToCheck, щоб перевірити, чи інші потенційно видимі коментарі на клієнті повинні бути заблоковані/розблоковані після виконання цієї дії.
Примітки:
- Цей виклик завжди має виконуватися в контексті користувача. Користувач може бути користувачем FastComments.com, SSO-користувачем або користувачем орендаря.
userIdу запиті — це користувач, який виконує блокування. Наприклад:User Aхоче заблокуватиUser B. ПередайтеuserId=User Aта id коментаря, який написавUser B.- Повністю анонімні коментарі (немає id користувача, немає електронної пошти) не можна заблокувати — буде повернено помилку.

Для анонімного блокування ми маємо вказати anonUserId. Це може бути ідентифікатор, який представляє анонімну сесію, або випадковий UUID.
Це дозволяє нам підтримувати блокування коментарів навіть якщо користувач не увійшов, отримуючи коментарі з тим самим anonUserId.



POST /api/v1/comments/:id/un-block 
Цей API-ендпоінт надає можливість розблокувати користувача, який написав певний коментар. Підтримується розблокування коментарів, написаних користувачами FastComments.com, SSO Users та Tenant Users.
Він підтримує параметр тіла запиту commentIdsToCheck, щоб перевірити, чи інші потенційно видимі коментарі на клієнті слід заблокувати/розблокувати після виконання цієї дії.
Примітки:
- Цей виклик завжди має виконуватися в контексті користувача. Користувач може бути FastComments.com User, SSO User або Tenant User.
- Параметр
userIdу запиті — це користувач, який виконує розблокування. Наприклад:User Aхоче розблокуватиUser B. ПередайтеuserId=User Aта id коментаря, який написавUser B. - Повністю анонімні коментарі (без ідентифікатора користувача та без електронної пошти) не можуть бути заблоковані, і буде повернено помилку.




Структура шаблону електронної пошти 
Об'єкт EmailTemplate представляє конфігурацію для користувацького шаблону електронного листа для тенанта.
Система обиратиме шаблон електронного листа для використання за допомогою:
- Ідентифікатора типу, який ми називаємо
emailTemplateId. Це константи. domain. Спочатку ми намагатимемося знайти шаблон для домену, до якого прив'язаний пов'язаний об'єкт (наприклад,Comment), і якщо відповідність не знайдена, тоді ми спробуємо знайти шаблон, де domain дорівнює null або*.
Структура об'єкта EmailTemplate виглядає так:

Примітки
- Дійсні значення
emailTemplateIdможна отримати з кінцевої точки/definitions. - Кінцева точка
/definitionsтакож містить стандартні переклади та тестові дані. - Шаблони не збережуться, якщо структура або тестові дані недійсні.
GET /api/v1/email-templates/:id 
Окремі EmailTemplate можна отримати за відповідним id (НЕ emailTemplateId).



GET /api/v1/email-templates 
Цей API використовує пагінацію, яка задається параметром запиту page. EmailTemplates повертаються сторінками по 100, відсортовані за createdAt, а потім за id.



PATCH /api/v1/email-templates/:id 
This API endpoint provides the ability to update an email template by only specifying the id and the attributes to update.
Note that all the same validations for creating a template also apply, for example:
- The template must render. This is checked with each update.
- You can't have duplicate templates for the same domain (otherwise one would be silently ignored).



POST /api/v1/email-templates 
This API endpoint provides the ability to create email templates.
Notes:
- You can't have multiple templates with the same
emailTemplateIdwith the same domain. - But you can have a wildcard template (
domain=*and a domain specific template for the sameemailTemplateId). - Specifying
domainis only relevant if you have different domains, or want to use specific templates for testing (domainset tolocalhostetc). - If you do specify
domainit must match aDomainConfig. On error a list of valid domains is provided. - The template syntax is EJS and is rendered with a 500ms timeout. P99 for rendering is <5ms, so if you hit 500ms something is wrong.
- Your template must render with your given
testDatato save. Render errors are aggregated and reported on in the dashboard (soon available via API).
The minimum data required to add a template is as follows:

You may want to have templates per-site, in which case you define domain:



POST /api/v1/email-templates/render 
Цей API-ендпоінт дозволяє попередньо переглядати шаблони електронної пошти.



DELETE /api/v1/email-templates/:id 
Цей маршрут дозволяє видалити один EmailTemplate за id.



Структура хештегу 
Об'єкт HashTag представляє тег, який може залишити користувач. Хештеги можуть використовуватися для зв'язування з зовнішнім вмістом або для об'єднання пов'язаних коментарів.
Структура об'єкта HashTag виглядає так:

Notes:
- In some API endpoints you will see that the hashtag is used in the URL. Remember to URI-Encoded values. For example,
#should instead be represented as%23. - Some of these fields are marked
READONLY- these are returned by the API but cannot be set.
GET /api/v1/hash-tags 
Цей API використовує пагінацію, яку задає параметр запиту page. HashTags повертаються сторінками по 100, впорядковані за tag.



PATCH /api/v1/hash-tags/:tag 
Цей маршрут дозволяє оновити окремий HashTag.



POST /api/v1/hash-tags 
Цей маршрут дозволяє додати один HashTag.



POST /api/v1/hash-tags/bulk 
Цей маршрут дозволяє додати до 100 об'єктів HashTag одночасно.



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



Структура модератора 
Об'єкт Moderator представляє конфігурацію для модератора.
Існує три типи модераторів:
- Користувачі-адміністратори, які мають прапорець
isCommentModeratorAdmin. - Користувачі SSO з прапорцем
isCommentModeratorAdmin. - Звичайні коментатори або користувачі FastComments.com, яких запрошують як модераторів.
Структура Moderator використовується для представлення стану модерації для випадку використання 3.
Якщо ви хочете запросити користувача стати модератором через API, використайте API Moderator, створивши Moderator і inviting їх.
Якщо у користувача немає облікового запису FastComments.com, електронний лист із запрошенням допоможе їм налаштуватись. Якщо вони вже мають обліковий запис, вони
отримають доступ для модерації до вашого tenant, і поле userId об'єкта Moderator буде оновлено, щоб вказувати на їхнього користувача. Ви не матимете API
доступу до їхнього користувача, оскільки в цьому випадку він належить їм і управляється FastComments.com.
Якщо вам потрібне повне управління обліковим записом користувача, ми рекомендуємо або використовувати SSO, або додати їх як a Tenant User і
потім додати об'єкт Moderator для відстеження їхніх статистик.
Структура Moderator може використовуватись як механізм відстеження статистики для випадків використання 1 та 2. Після створення користувача, додайте Moderator
об'єкт з визначеним userId, і їхні статистики будуть відстежуватись на сторінці Comment Moderators Page.
The structure for the Moderator object is as follows:

GET /api/v1/moderators/:id 
Цей маршрут повертає одного модератора за його/її id.



GET /api/v1/moderators 
Цей API використовує пагінацію, яку забезпечує параметр запиту skip. Модератори повертаються сторінками по 100, відсортовані за createdAt та id.
Вартість залежить від кількості повернених модераторів: 1 credit per 10 повернених модераторів.



PATCH /api/v1/moderators/:id 
Ця кінцева точка API дозволяє оновити 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, що вказаний у параметрах запиту. - Не можна додати двох модераторів у тому самому тенанті з однаковим
email.
Ми можемо створити Moderator для користувача, якого ми знаємо тільки за електронною поштою:

Або ми можемо створити Moderator для користувача, який належить нашому тенанту, щоб відстежувати його статистику модерації:



POST /api/v1/moderators/:id/send-invite 
Цей маршрут надає можливість запросити одного Moderator.
Існують такі обмеження для відправки запрошення електронною поштою Moderator:
Moderatorповинен уже існувати.fromNameне може бути довшим за100 characters.
Примітки:
- Якщо користувач із вказаною електронною поштою вже існує, йому буде надіслано запрошення модерувати коментарі вашого тенанта.
- Якщо користувача з вказаною електронною поштою не існує, посилання-запрошення проведе його через процес створення облікового запису.
- Термін дії запрошення закінчується через
30 days.
Ми можемо створити Moderator для користувача, про якого ми знаємо лише електронну пошту:

Це надішле електронний лист приблизно такого змісту: Bob at TenantName is inviting you to be a moderator...


DELETE /api/v1/moderators/:id 
Цей маршрут забезпечує видалення Moderator за id.



Структура лічильника сповіщень 
Об'єкт NotificationCount представляє собою кількість непрочитаних сповіщень та метадані для користувача.
Якщо немає непрочитаних сповіщень, для користувача не існуватиме NotificationCount.
NotificationCount об'єкти створюються автоматично і не можуть бути створені через API. Термін їх дії закінчується через один рік.
Ви можете очистити кількість непрочитаних сповіщень користувача, видаливши його NotificationCount.
Структура об'єкта NotificationCount виглядає так:

GET /api/v1/notification-count/:user_id 
Цей маршрут повертає один NotificationCount за ідентифікатором користувача. З SSO ідентифікатор користувача має формат <tenant id>:<user id>.
Якщо немає непрочитаних сповіщень, NotificationCount не буде - отримаєте 404.
Це відрізняється від notifications/count тим, що є набагато швидшим, але не дозволяє фільтрування.



DELETE /api/v1/notification-count/:user_id 
Цей маршрут видаляє одиночний NotificationCount за ідентифікатором користувача. При SSO ідентифікатор користувача має формат <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 ідентифікатор користувача має формат <tenant id>:<user id>.



GET /api/v1/notifications/count 
Цей маршрут повертає об'єкт, що містить кількість сповіщень у параметрі count.
Він повільніший за /notification-count/ і коштує вдвічі більше кредитів, але дозволяє фільтрувати за більшою кількістю параметрів.
Ви можете фільтрувати за тими ж параметрами, що й кінцева точка /notifications, наприклад userId. При SSO ідентифікатор користувача має формат <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. Це може бути корисно для отримання заголовків сторінок або кількості коментарів.



Корисна порада
Пам'ятайте кодувати значення, такі як urlId, у форматі URI.
PATCH /api/v1/pages/:id 
Цей маршрут дає змогу оновити один Page. Відповідні коментарі будуть оновлені.



Примітка
Деякі параметри в об'єкті Page оновлюються автоматично. Ці параметри — підрахунки та атрибути заголовка. Підрахунки не можна оновити
через API, оскільки вони є обчислюваними значеннями. Заголовок сторінки title можна встановити через API, але він буде перезаписаний, якщо віджет коментарів використовується на
сторінці з тим самим urlId та іншим заголовком сторінки.
POST /api/v1/pages 
Ця кінцева точка API надає можливість створювати сторінки.
Одним із поширених випадків використання є контроль доступу.
Примітки:
- Якщо ви залишали коментар у гілці коментарів або викликали API для створення
Comment, ви вже створили об'єктPage! Ви можете спробувати отримати його через маршрутPage/by-url-id, передавши той самийurlId, який передається віджетові коментарів. - Структура
Pageмістить деякі обчислені значення. Наразі цеcommentCountтаrootCommentCount. Вони заповнюються автоматично і не можуть бути встановлені через API. Спроба зробити це призведе до того, що API поверне помилку.



DELETE /api/v1/pages/:id 
Цей маршрут дозволяє видалити одну сторінку за її id.
Зверніть увагу, що взаємодія з віджетом коментарів на сторінці з тим самим urlId просто знову створить Page.



Структура очікуваної події вебхука 
Об'єкт PendingWebhookEvent представляє подію вебхука, яка знаходиться в черзі та очікує виконання.
PendingWebhookEvent об'єкти створюються автоматично і не можуть бути створені вручну через API. Їх термін дії також закінчується через один рік.
Їх можна видалити, що видаляє завдання з черги.
Існують різні типи подій — перевіряйте eventType (OutboundSyncEventType) і type (OutboundSyncType).
Поширений випадок використання цього API — реалізація власного моніторингу. Можливо, ви захочете періодично викликати ендпоінт /count
щоб опитувати кількість невиконаних завдань за заданими фільтрами.
Структура об'єкта PendingWebhookEvent має такий вигляд:

GET /api/v1/pending-webhook-events 
Цей маршрут повертає список очікуваних подій вебхуків у параметрі pendingWebhookEvents.
Цей API використовує пагінацію, яку задає параметр skip. PendingWebhookEvents повертаються сторінками по 100, впорядковані за createdAt від найновіших.



GET /api/v1/pending-webhook-events/count 
Цей маршрут повертає об'єкт, що містить кількість очікуваних webhook-подій у параметрі count.
Ви можете фільтрувати за тими ж параметрами, що й для /pending-webhook-events endpoint



DELETE /api/v1/pending-webhook-events/:id 
Цей маршрут дозволяє видалити один PendingWebhookEvent.
Якщо потрібно виконати масове видалення, викличте GET API з пагінацією, а потім послідовно викликайте цей API.



Структура користувача SSO 
FastComments provides an easy to use SSO solution. Updating a user's information with the HMAC-based integration is as simple as having the user load the page with an updated payload.
However, it may be desirable to manage a user outside that flow, to improve consistency of your application.
The SSO User API provides a way to CRUD objects that we call SSOUsers. These objects are different from regular Users and kept separate for type safety.
The structure for the SSOUser object is as follows:

Billing for SSO Users
SSO users are billed differently based on their permission flags:
- Regular SSO Users: Users without admin or moderator permissions are billed as regular SSO users
- SSO Admins: Users with
isAccountOwnerorisAdminAdminflags are billed separately as SSO Admins (same rate as regular tenant admins) - SSO Moderators: Users with
isCommentModeratorAdminflag are billed separately as SSO Moderators (same rate as regular moderators)
Important: To prevent double billing, the system automatically deduplicates SSO users against regular tenant users and moderators by email address. If an SSO user has the same email as a regular tenant user or moderator, they will not be billed twice.
Access Control
Users can be broken into groups. This is what the groupIds field is for, and is optional.
@Mentions
By default @mentions will use username to search for other sso users when the @ character is typed. If displayName is used, then results matching
username will be ignored when there is a match for displayName, and the @mention search results will use displayName.
Subscriptions
With FastComments, users can subscribe to a page by clicking the bell icon in the comment widget and clicking Subscribe.
With a regular user, we send them notification emails based on their notification settings.
With SSO Users, we split this up for backwards compatibility. Users will only get sent these additional subscription notification
emails if you set optedInSubscriptionNotifications to true.
Badges
You can assign badges to SSO users using the badgeConfig property. Badges are visual indicators that appear next to a user's name in comments.
badgeIds- An array of badge IDs to assign to the user. These must be valid badge IDs created in your FastComments account. Limited to 30 badges.override- If true, all existing badges displayed on comments will be replaced with the provided ones. If false or omitted, the provided badges will be added to any existing badges.update- If true, badge display properties will be updated from the tenant configuration whenever the user logs in.
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. Наприклад, якщо ви задасте username через API, але потім передасте інший через SSO-процес при завантаженні сторінки, ми автоматично оновимо їхній username.
Ми не будемо оновлювати параметри користувача в цьому процесі, якщо ви явно не вкажете їх або не встановите їх у null (не undefined).
PUT /api/v1/sso-users/:id 
Цей маршрут дозволяє оновити одного SSO-користувача.

У цьому прикладі ми вказуємо groupIds для керування доступом, але це необов'язково.


DELETE /api/v1/sso-users/:id 
Цей маршрут дозволяє видалити одного SSO-користувача за його id.
Зверніть увагу, що повторне завантаження віджета коментарів з payload для цього користувача просто повторно створить користувача без помітних змін.
Видалення коментарів користувача можливе через параметр запиту deleteComments. Зауважте, що якщо це true:
- Усі коментарі користувача будуть видалені в режимі live.
- Всі child (тепер сирітські) коментарі будуть видалені або анонімізовані залежно від конфігурації сторінки, пов'язаної з кожним коментарем. Наприклад, якщо режим видалення треду — "anonymize", то відповіді залишаться, а коментарі користувача будуть анонімізовані. Це застосовується лише коли
commentDeleteModeрівнийRemove(значення за замовчуванням). - Значення
creditsCostстає2.
Анонімізовані коментарі
Ви можете зберегти коментарі користувача, але просто анонімізувати їх, встановивши commentDeleteMode=1.
Якщо коментарі користувача анонімізовано, то наступні значення встановлюються в null:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badgesПоля isDeleted та isDeletedUser встановлюються в true.
Під час рендерингу віджет коментарів використовуватиме DELETED_USER_PLACEHOLDER (за замовчуванням: "[deleted]") для імені користувача та DELETED_CONTENT_PLACEHOLDER для коментаря. Це можна налаштувати через інтерфейс налаштування віджета.
Приклади



Структура підписки 
Об'єкт Subscription представляє підписку для користувача.
Subscription objects are created when a user clicks the notification bell in the comment widget and clicks "Підписатися на цю сторінку".
Підписки також можна створювати через API.
Наявність об'єкта Subscription призводить до створення об'єктів Notification і надсилання електронних листів, коли на корені пов'язаної сторінки, для якої призначена підписка, з'являються нові коментарі. Надсилання електронних листів залежить від типу користувача. Для звичайних користувачів це залежить від optedInNotifications. Для SSO-користувачів це залежить від optedInSubscriptionNotifications. Зверніть увагу, що деякі застосунки можуть не мати поняття веб-доступної сторінки; у такому випадку просто встановіть urlId в id елемента, на який ви підписуєтесь (те ж значення urlId, яке ви передали б віджету коментарів).
Структура об'єкта Subscription виглядає так:

GET /api/v1/subscriptions/:id 
Цей маршрут повертає до 30 об'єктів Subscription, відсортованих за createdAt, починаючи з найновіших.
Ви можете фільтрувати за userId. При SSO ідентифікатор користувача має формат <tenant id>:<user id>.



POST /api/v1/subscriptions 
Ця кінцева точка API надає можливість створити Subscription. Зауважте, що користувач може мати лише одну підписку на сторінку, оскільки більше є надлишковим, і спроба створити більше ніж одну підписку для того самого користувача для тієї самої сторінки призведе до помилки.
Створення підписки призведе до створення об'єктів Notification, коли на корені підписаного urlId буде залишено новий коментар (коли parentId коментаря дорівнює null).



DELETE /api/v1/subscriptions/:id 
Цей маршрут видаляє один об'єкт Subscription за id.



Структура щоденного використання орендаря 
Об'єкт TenantDailyUsage представляє використання для орендаря за конкретний день. Якщо для певного орендаря в певний
день не було активності, у цей день не буде об'єкта TenantDailyUsage.
Об'єкт TenantDailyUsage не є в режимі реального часу і може відставати від фактичного використання на декілька хвилин.
Структура об'єкта TenantDailyUsage має такий вигляд:

GET /api/v1/tenant-daily-usage 
This route allows searching for the usage of a tenant by year, month, and day. Up to 365 objects can be returned, and the cost is 1 api credit per 10 objects.
Response objects are sorted by the date they are created (the oldest first).



Структура орендаря 
Tenant визначає клієнта FastComments.com. Вони можуть бути створені через API орендарями з доступом до white labeling. White labeled tenants
не можуть створювати інших white labeled tenants (дозволено тільки один рівень вкладеності).
Структура об'єкта Tenant виглядає так:

GET /api/v1/tenants/:id 
Цей маршрут повертає одного Tenant за id.



GET /api/v1/tenants 
Цей API повертає tenants, якими керує ваш tenant.
Пагінація здійснюється за допомогою параметра запиту skip. Tenants повертаються сторінками по 100, впорядковані за signUpDate та id.
Вартість залежить від кількості повернутих tenants і становить 1 credit per 10 tenants.

Ви можете визначати параметри meta в об'єктах Tenant і виконувати запит для пошуку відповідних tenants. Наприклад, для ключа someKey та значення meta some-value, ми можемо
construct a JSON object with this key/value pair and then URI encode it as a query param to filter:



POST /api/v1/tenants 
Цей маршрут надає можливість додати один Tenant.
Створення Tenant має такі обмеження:
- Поле
nameє обов'язковим. - Поле
domainConfigurationє обов'язковим. - Наступні значення не можуть бути вказані під час створення
Tenant:hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmount
- Поле
signUpDateне може бути в майбутньому. - Поле
nameне може бути довшим за200 characters. - Поле
emailне може бути довшим за300 characters. - Поле
emailмає бути унікальним серед усіх tenants FastComments.com. - Ви не можете створювати tenants, якщо батьківський tenant не має визначеного дійсного
TenantPackage.- Якщо ваш tenant був створений через FastComments.com, це не має становити проблему.
- Ви не можете створити більше tenants, ніж визначено у
maxWhiteLabeledTenantsу вашому пакеті. - Ви повинні вказати параметр запиту
tenantId, який є id вашогоparent tenantз увімкненою white labeling.
Ми можемо створити Tenant, вказавши лише декілька параметрів:



PATCH /api/v1/tenants/:id 
Ця кінцева точка API надає можливість оновити Tenant за id.
Оновлення Tenant має такі обмеження:
- Наступні значення не можуть бути оновлені:
hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmountmanagedByTenantId
- Значення
signUpDateне може бути в майбутньому. - Поле
nameне може бути довшим за200 characters. - Поле
emailне може бути довшим за300 characters. - Значення
emailмає бути унікальним серед усіх тенантів FastComments.com. - Якщо встановити
billingInfoValidвtrue, тоbillingInfoмає бути надано в тому самому запиті. - Ви не можете оновити
packageId, пов'язаний з вашим власним тенантом. - Ви не можете оновити
paymentFrequency, пов'язаний з вашим власним тенантом.



DELETE /api/v1/tenants/:id 
Цей маршрут дозволяє видалити Tenant та всі пов'язані дані (користувачі, коментарі тощо) за id.
Існують такі обмеження щодо видалення тенантів:
- Тенант має належати вам або бути white-label тенантом, яким ви керуєте.
- Параметр запиту
sureмає бути встановлений уtrue.



Структура пакету орендаря 
The TenantPackage визначає інформацію про пакет, доступний для Tenant. У одного tenant може бути багато доступних пакетів, але лише
один використовується в певний момент часу.
З Tenant не можна користуватися жодними продуктами, поки його packageId не вказує на дійсний TenantPackage.
Існує два типи об'єктів TenantPackage:
- Пакети з фіксованими тарифами - де
hasFlexPricingмає значення false. - Гнучке ціноутворення - де
hasFlexPricingмає значення true.
У обох випадках ліміти визначаються для облікового запису, що використовує пакет, проте у випадку Flex орендарю нараховується базова плата плюс оплата за фактичне використання, яка задається параметрами 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 packages і становить 1 credit per 10 tenant packages.



POST /api/v1/tenant-packages 
Цей маршрут надає можливість додати один TenantPackage.
Створення TenantPackage має такі обмеження:
- Наступні параметри є обов'язковими:
nametenantIdmonthlyCostUSD- Can be null.yearlyCostUSD- Can be null.maxMonthlyPageLoadsmaxMonthlyAPICreditsmaxMonthlyCommentsmaxConcurrentUsersmaxTenantUsersmaxSSOUsersmaxModeratorsmaxDomainshasDebrandingforWhoTextfeatureTaglineshasFlexPricing- Якщо true, то всі параметриflex*є обов'язковими.
nameне може бути довшим за50 characters.- Кожен елемент
forWhoTextне може бути довшим за200 characters. - Кожен елемент
featureTaglinesне може бути довшим за100 characters. TenantPackageмає бути «меншим» за батьківський тенант. Наприклад, всі параметриmax*мають мати менші значення, ніж у батьківського тенанта.- Тенант із white-label може мати максимум п'ять пакетів.
- Створювати
TenantPackageможуть лише тенанти з доступом до white-label. - Ви не можете додавати пакети до власного тенанта. :)
Ми можемо створити TenantPackage наступним чином:



PATCH /api/v1/tenant-packages/:id 
Цей API-ендпойнт надає можливість оновити TenantPackage за id.
Оновлення TenantPackage має такі обмеження:
- Якщо ви встановлюєте
hasFlexPricingв true, тоді всі параметриflex*повинні бути вказані в тому ж запиті. - Поле
nameне може бути довшим за50 characters. - Кожен елемент
forWhoTextне може бути довшим за200 characters. - Кожен елемент
featureTaglinesне може бути довшим за100 characters. TenantPackageмає бути "меншим" за батьківський tenant. Наприклад, всі параметриmax*повинні мати менші значення, ніж у батьківського tenant.- Ви не можете змінювати
tenantId, пов'язаний зTenantPackage.



DELETE /api/v1/tenant-packages/:id 
Цей маршрут дозволяє видалити TenantPackage за id.
Ви не можете видалити TenantPackage, який використовується (у орендаря поле packageId вказує на пакет). Спочатку оновіть Tenant.



Структура користувача орендаря 
The TenantUser визначає User, яким управляє конкретний тенант. Їхній обліковий запис повністю контролюється тим тенантом, з яким він пов'язаний, і обліковий запис може бути оновлений або видалений через UI або API.
Користувачі тенанта можуть бути адміністраторами з усіма правами та доступом до Tenant, або їм можуть бути надані обмежені права для модерування коментарів, доступу до ключів API тощо.
Структура об'єкта TenantUser наведена нижче:

GET /api/v1/tenant-users/:id 
Цей маршрут повертає одного TenantUser за id.



GET /api/v1/tenant-users 
Цей API використовує пагінацію, що забезпечується параметром запиту skip. TenantUsers повертаються сторінками по 100, впорядковані за signUpDate, username та id.
Вартість базується на кількості повернутих користувачів тенанта, становить 1 credit per 10 повернутих користувачів тенанта.



POST /api/v1/tenant-users 
Цей маршрут надає можливість додати одного TenantUser.
Створення TenantUser має такі обмеження:
- Потрібен
username. - Потрібен
email. - Поле
signUpDateне може містити дату в майбутньому. - Значення
localeмає бути в списку Підтримувані локалі. usernameмає бути унікальним у межах всього FastComments.com. Якщо це проблема, ми радимо використовувати SSO.emailмає бути унікальним у межах всього FastComments.com. Якщо це проблема, ми радимо використовувати SSO.- Ви не можете створити більше
TenantUser, ніж визначено вmaxTenantUsersу вашому пакеті.
Ми можемо створити TenantUser таким чином



POST /api/v1/tenant-users/:id/send-login-link 
Цей маршрут дозволяє надіслати посилання для входу одному TenantUser.
Корисно при масовому створенні користувачів, щоб не інструктувати їх щодо входу на FastComments.com. Це надішле їм «магічне посилання» для входу, яке діє протягом 30 days.
Існують наступні обмеження для надсилання посилання на вхід TenantUser:
- The
TenantUsermust already exist. - You must have access to manage the
TenanttheTenantUserbelongs to.
Ми можемо надіслати посилання для входу TenantUser таким чином:

This will send an email like Bob at TenantName is inviting you to be a moderator...


PATCH /api/v1/tenant-users/:id 
This route provides the ability to update a single TenantUser.
Updating a TenantUser has the following restrictions:
- The
signUpDatemay not be in the future. - The
localemust be in the list of Підтримувані локалі. - The
usernamemust be unique across all of FastComments.com. If this is an issue, we suggest using SSO instead. - The
emailmust be unique across all of FastComments.com. If this is an issue, we suggest using SSO instead. - You cannot update the
tenantIdof a user.
We can create a TenantUser as follows



DELETE /api/v1/tenant-users/:id 
Цей маршрут виконує видалення TenantUser за id.
Видалення коментарів користувача можливе через параметр запиту deleteComments. Зверніть увагу, що якщо це true:
- Всі коментарі користувача будуть видалені в реальному часі.
- Всі child (тепер сирітські) коментарі будуть видалені або анонімізовані залежно від конфігурації сторінки, пов'язаної з кожним коментарем. Наприклад, якщо режим видалення нитки — "анонімізувати", тоді відповіді залишаться, а коментарі користувача будуть анонімізовані. Це застосовується лише коли
commentDeleteModeдорівнюєRemove(значення за замовчуванням). creditsCostстає2.
Анонімізовані коментарі
Ви можете зберегти коментарі користувача, але анонімізувати їх, встановивши commentDeleteMode=1.
Якщо коментарі користувача анонімізовані, то наступні значення встановлюються в null:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badgesisDeleted і isDeletedUser встановлюються в true.
Під час відображення віджет коментарів використовуватиме DELETED_USER_PLACEHOLDER (за замовчуванням: "[deleted]") для імені користувача та DELETED_CONTENT_PLACEHOLDER для коментаря. Ці значення можна налаштувати через інтерфейс налаштування віджету.
Приклади



Структура користувача 
User — це об'єкт, що представляє найбільш загальний знаменник усіх користувачів.
Майте на увазі, що в FastComments у нас є кілька різних сценаріїв використання для користувачів:
- Безпечний SSO
- Простий SSO
- Користувачі орендаря (наприклад: Адміністратори)
- Коментатори
Цей API призначений для Коментаторів та користувачів, створених через Простий SSO. Насправді будь-який користувач, створений через ваш сайт, може бути отриманий через цей API. Користувачів орендаря також можна отримати цим способом, але ви отримаєте більше інформації, взаємодіючи з /tenant-users/ API.
Для Secure SSO будь ласка використовуйте /sso-users/ API.
Ви не можете оновлювати ці типи користувачів. Вони створили свій акаунт через ваш сайт, тому ми надаємо базовий доступ лише для читання, але ви не можете вносити зміни. Якщо ви хочете мати такий тип потоку — вам потрібно налаштувати Secure 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 key.
Структура appliedAnonymousVotes призначена для голосів, створених без електронної пошти, API key тощо.
GET /api/v1/votes/for-user 
Дозволяє отримати голоси, залишені користувачем для певного urlId. Потребує userId, який може бути будь-яким користувачем FastComments.com або SSO User.
Це корисно, якщо ви хочете показати, чи голосував користувач за коментар. Коли ви отримуєте коментарі, просто викликайте цей API одночасно для цього користувача з тією ж urlId.
Якщо ви використовуєте анонімне голосування, передавайте натомість anonUserId.


Зверніть увагу, що анонімні голоси з'являться в списку appliedAuthorizedVotes. Вони вважаються авторизованими, оскільки були створені через API з використанням API-ключа.


POST /api/v1/votes 
Цей маршрут надає можливість додати один авторизований Vote. Голоси можуть бути up (+1) або down (-1).




Creating Anonymous Votes
Анонімні голоси можна створити, встановивши anonUserId в параметрах запиту замість userId.
This id does not have to correspond to a user object anywhere (hence anonymous). It is simply an identifier for the session, so you can fetch votes again in the same session, to check if a comment has been voted.
If you do not have such a thing as "anonymous sessions" like FastComments does - you can simply set this to a random ID, like a UUID (although we appreciate smaller identifiers to save space).
Other Notes
- This API obeys tenant-level settings. For example, if you disable voting for a given page, and you attempt to create a vote via the API, it will fail with error code
voting-disabled. - This API is live by default.
- This API will update the
votesof the correspondingComment.
DELETE /api/v1/votes/:id 
Цей маршрут надає можливість видалити один Vote.



Примітки:
- Цей API дотримується налаштувань на рівні орендаря. Наприклад, якщо ви вимкнете голосування для певної сторінки, і ви спробуєте створити голос через API, це завершиться помилкою з кодом
voting-disabled. - Цей API за замовчуванням є активним.
- Цей API оновить
votesвідповідногоComment.
Структура конфігурації домену 
Об'єкт DomainConfig представляє конфігурацію для домену орендаря.
Структура об'єкта 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 об'єкти для орендаря.



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 
Тут відбувається агрегація результатів.
Структура відповіді агрегації така:

Нижче наведено параметри запиту, доступні для агрегації:

Ось приклад запиту:

Приклад відповіді:


Примітки щодо продуктивності
- У разі промаху кеша (cache miss) агрегація зазвичай займає п'ять секунд на мільйон результатів.
- В іншому випадку запити виконуються за константний час.
Примітки щодо кешування та вартості
- Коли зазначено
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 
Цей endpoint дозволяє отримувати бейджі користувачів на основі різних критеріїв.
Example Request:
Run 
You can add various query parameters to filter the results:
userId- Отримати бейджі для конкретного користувачаbadgeId- Отримати екземпляри конкретного бейджаtype- Фільтрувати за типом бейджа (0=CommentCount, 1=CommentUpVotes, 2=CommentReplies, etc. See UserBadge structure for full list)displayedOnComments- Фільтрувати за тим, чи відображається бейдж у коментарях (true/false)limit- Максимальна кількість бейджів для повернення (за замовчуванням 30, максимум 200)skip- Кількість бейджів для пропуску (для пагінації)
Example Response:

Possible Error Responses:


GET /api/v1/user-badges/:id 
Ця кінцева точка дозволяє отримати конкретний значок користувача за його унікальним ідентифікатором.
Приклад запиту:
Run 
Приклад відповіді:

Можливі відповіді з помилками:


POST /api/v1/user-badges 
Цей endpoint дозволяє створити нове призначення бейджа для користувача.
Example Request:
Run 
The request body must contain the following parameters:
userId(required) - Ідентифікатор користувача, якому призначається бейджbadgeId(required) - Ідентифікатор бейджа, який призначаєтьсяdisplayedOnComments(optional) - Чи має бейдж відображатися у коментарях користувача (за замовчуванням true)
Important Notes:
- The badge must exist and be enabled in your tenant's badge catalog
- You can only assign badges to users who belong to your tenant or have commented on your site
Example Response:

Possible Error Responses:





PUT /api/v1/user-badges/:id 
Ця кінцева точка дозволяє оновити призначення бейджу користувача.
Наразі єдина властивість, яку можна оновити, — displayedOnComments, яка контролює, чи бейдж відображається в коментарях користувача.
Example Request:
Run 
Example Response:

Possible Error Responses:



DELETE /api/v1/user-badges/:id 
Цей endpoint дозволяє видалити призначення бейджа користувача.
Example Request:
Run 
Example Response:

Possible Error Responses:



Структура прогресу значка користувача 
UserBadgeProgress — це об'єкт, який представляє прогрес користувача щодо здобуття різних значків у системі FastComments.
Це відстеження допомагає визначити, коли користувачі повинні отримувати автоматичні значки на основі їхньої активності та участі у вашій спільноті.
Структура об'єкта UserBadgeProgress виглядає так:

GET /api/v1/user-badge-progress 
Цей кінцевий пункт дозволяє отримати записи про прогрес значків користувачів на основі різних критеріїв.
Приклад запиту:
Run 
Ви можете додати різні параметри запиту для фільтрування результатів:
userId- Отримати прогрес для конкретного користувачаlimit- Максимальна кількість записів для повернення (за замовчуванням 30, максимум 200)skip- Кількість записів для пропуску (для пагінації)
Приклад відповіді:

Можливі відповіді з помилкою:


GET /api/v1/user-badge-progress/:id 
Ця кінцева точка дозволяє отримати конкретний запис прогресу значка користувача за його унікальним ідентифікатором.
Приклад запиту:
Run 
Приклад відповіді:

Можливі відповіді з помилкою:


GET /api/v1/user-badge-progress/user/:userId 
Цей endpoint дозволяє отримати запис про прогрес бейджів користувача за його User ID.
Приклад запиту:
Run 
Приклад відповіді:

Можливі відповіді з помилкою:



На завершення
Ми сподіваємося, що наша документація API була для вас вичерпною та зрозумілою. Якщо ви знайдете будь-які прогалини, повідомте нам нижче.