
שפה 🇮🇱 עברית
משאבי API
אגרגציות
יומני ביקורת
תגובות
תבניות דוא״ל
תגיות
מודרטורים
ספירת התראות
התראות
עמודים
אירועי Webhook ממתינים
משתמשי SSO
מנויים
שימוש יומי של שוכר
שוכרים
חבילות שוכר
משתמשי שוכר
משתמשים
הצבעות
הגדרות דומיין
הגדרות שאלה
תוצאות שאלות
אגרגציית תוצאות שאלות
תגי משתמש
התקדמות תגי משתמש
ממשק ה-API של FastComments
FastComments מספקת ממשק API לאינטראקציה עם משאבים רבים. צרו אינטגרציות עם הפלטפורמה שלנו, או אפילו צרו לקוחות משלכם!
בתיעוד זה תמצאו את כל המשאבים הנתמכים על ידי ה-API שתועדו עם סוגי הבקשה והתשובה שלהם.
ללקוחות Enterprise, כל הגישה ל-API נרשמת ביומן ביקורת.
SDKs שנוצרו
FastComments מייצרת כעת מפרט API מתוך הקוד שלנו (זה עדיין לא שלם, אך כולל ממשקי API רבים).
יש לנו גם SDKs לשפות נפוצות:
- fastcomments-cpp
- fastcomments-go
- fastcomments-java
- fastcomments-sdk-js
- fastcomments-nim
- fastcomments-php
- fastcomments-php-sso
- fastcomments-python
- fastcomments-ruby
- fastcomments-rust
- fastcomments-swift
אימות
ה-API מאומת על ידי העברת מפתח ה-API שלך ככותרת X-API-KEY או כפרמטר שאילתה API_KEY. תזדקקו גם ל-tenantId כדי לבצע קריאות ל-API. ניתן לקבל אותו מאותה עמוד שבו נמצא מפתח ה-API שלכם.
הערת אבטחה
ניתובים אלה מיועדים להיקרא משרת. אסור לקרוא להם מדפדפן. פעולה כזו תחשוף את מפתח ה-API שלכם — וזה ייתן גישה מלאה לחשבון שלכם לכל מי שיכול לצפות בקוד המקור של דף!
אפשרות אימות אחת - כותרות
- כותרת:
X-API-KEY - כותרת:
X-TENANT-ID
אפשרות אימות שנייה - פרמטרי שאילתה
- פרמטר שאילתה:
API_KEY - פרמטר שאילתה:
tenantId
קריאה של הכתיבות שלך
FastComments מספקת זמינות Active-Active. בקשות ממרכז הנתונים שלכם מנותבות אל נקודת הנוכחות הקרובה אליכם. זה אוטומטי, ובדרך כלל תוכלו להבחין בסמנטיקה של קריאה אחרי כתיבה. אם ברצונכם להיות בטוחים שנקרא את הכתיבות שלכם, תוכלו לקבע את הבקשות לאזור מסוים על ידי שימוש באזור זה כ-host של ה-API (עם זאת, בדרך כלל זה לא נדרש עבור רוב האינטגרציות):
- gdc-oregon.fastcomments.com
- gdc-virginia.fastcomments.com
- gdc-singapore.fastcomments.com
- gdc-falkenstein2.fastcomments.com
- gdc-sao-paulo.fastcomments.com
- eudc-helsinki2.fastcomments.com
- eudc-limburg.fastcomments.com
- eudc-france.fastcomments.com
שימו לב שאם תעשו זאת ייתכן שתרצו להגדיר נקודת גיבוי, שכן בעבר הסרנו צמתים של נקודות כניסה והשתמשנו בשמות חדשים בעת המעבר.
משאבי API 
שימוש במשאבים
יש לציין כי אחזור נתונים מה-API נספר כשימוש בחשבון שלך.
כל משאב יציין מה השימוש הזה בסעיף שלו.
חלק מהמשאבים יקרים יותר לשרת מאחרים. לכל נקודת קצה יש עלות קבועה של קרדיטים לכל קריאת API. עבור חלק מנקודות הקצה, מספר הקרדיטים משתנה בהתאם לאפשרויות ולגדלי התגובות.
ניתן לבדוק את השימוש ב-API בדף ניתוח חיוב והוא מתעדכן כל מספר דקות.
הערה!
אנו מציעים לקרוא קודם את תיעוד הדפים, כדי לסייע בהגבלת הבלבול בעת קביעת אילו ערכים להעביר עבור urlId ב-API של Comment.
לאגד את הנתונים שלך 
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 הוא כדלקמן:

יומן הביקורת הוא בלתי ניתן לשינוי. גם לא ניתן לכתוב אליו ידנית. 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 אך לא יכולים להיות מוגדרים.
Comment Text Structure
תגובות נכתבות בגירסה של 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. An example parser is here..
ניתן גם להתאים את מפענח הדוגמה לעבודה עם HTML, ולהמיר את תווי ה-HTML לאלמנטים הצפויים להצגה בפלטפורמה שלך.
Tagging
כאשר משתמשים מסומנים בתגובה, המידע מאוחסן ברשימה שנקראת mentions. כל אובייקט ברשימה זו
יש את המבנה הבא.
Run 
HashTags
כאשר משתמשים בהאשטאגים והם פוענחו בהצלחה, המידע מאוחסן ברשימה שנקראת 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, בכל השוכר שלך (לא מוגבל לעמוד אחד, או urlId).
בדוגמה זו, אנחנו משמיטים urlId, ומחפשים לפי מספר האשטאגים. ה-API יחזיר רק תגובות שיש להן את כל ההאשטאגים המבוקשים.

כל פרמטרי הבקשה

התגובה

טיפים מועילים
URL ID
סביר להניח שתרצה להשתמש ב-API של Comment עם פרמטר urlId. אתה יכול לקרוא קודם ל-API של Pages, כדי לראות איך נראים ערכי urlId הזמינים לך.
פעולות אנונימיות
לתגובות אנונימיות סביר להניח שתרצה להעביר anonUserId בעת אחזור תגובות, ובעת ביצוע דיווח וחסימה.
(!) זה נדרש עבור חנויות אפליקציות רבות מכיוון שמשתמשים חייבים להיות מסוגלים לדווח על תוכן שנוצר על ידי משתמשים שהם יכולים לראות, גם אם הם לא מחוברים. אי עשיית זאת עלולה לגרום להסרת האפליקציה שלך מהחנות האמורה.
תגובות לא מוחזרות
בדוק שהתגובות שלך מאושרות, ואינן ספאם.
GET /api/v1/comments/:id 
API זה מספק את היכולת לאחזר תגובה בודדת לפי מזהה.



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 זה עדיין יכולות להיבדק כספאם אם רצוי.
- הגדרות כגון אורכו המרבי של תגובה, אם הוגדרו דרך דף הניהול של כלל ההתאמה (Customization Rule), יחולו כאן.
- כדי לאפשר למשתמשים לעדכן את טקסט התגובה שלהם, ניתן פשוט לציין את
commentבגוף הבקשה. אנו נייצר את ה-commentHTMLהנובע.- אם תגדיר גם
commentוגםcommentHTMLלא נייצר את ה-HTML באופן אוטומטי. - אם המשתמש יוסיף אזכורים או האשטגים בטקסט החדש שלו, הם עדיין יעובדו כמו ב-API ה-
POST.
- אם תגדיר גם
- בעת עדכון
commenterEmailעל תגובה, עדיף גם לצייןuserId. אחרת, עליך להבטיח שהמשתמש עם אימייל זה שייך ל-tenant שלך, אחרת הבקשה תיכשל. - אם התגובה היעד נעולה (
isLocked: true), הבקשה תידחה עםcode: 'locked'. פתח את התגובה קודם, עדכן אותה, ואז נעל שוב אם רצוי.



DELETE /api/v1/comments/:id 
נקודת קצה זו של ה-API מאפשרת למחוק תגובה.
הערות:
- API זה יכול לעדכן את ווידג'ט התגובות "בלייב" אם רצוי (זה מעלה את
creditsCostמ-1ל-2). - ה-API ימחק את כל תגובות המשנה.
- אם התגובה המיועדת נעולה (
isLocked: true), הבקשה תידחה עםcode: 'locked'. הסר את הנעילה של התגובה תחילה, ואז מחק אותה.



POST /api/v1/comments/:id/flag 
נקודת קצה API זו מספקת את היכולת לדווח על תגובה עבור משתמש ספציפי.
הערות:
- קריאה זו חייבת תמיד להיעשות בהקשר של משתמש. המשתמש יכול להיות משתמש FastComments.com, משתמש SSO או משתמש שוכר.
- אם מוגדר סף דיווח-להסתרה, התגובה תוסתר אוטומטית בזמן אמת לאחר שדווחה את מספר הפעמים המוגדר.
- לאחר שהיא מאושרת אוטומטית (מוסתרת) - התגובה יכולה להיות מאושרת מחדש רק על ידי מנהל או מנחה. ביטול הדיווח לא יאשר מחדש את התגובה.

לדיווח אנונימי, עלינו לציין anonUserId. זה יכול להיות מזהה שמייצג את ההפעלה האנונימית, או UUID אקראי.
זה מאפשר לנו לתמוך בדיווח וביטול דיווח על תגובות גם אם משתמש לא מחובר. בדרך זו, התגובה יכולה להיות מסומנת כמדווחת
כאשר תגובות נאחזות עם אותו anonUserId.



POST /api/v1/comments/:id/un-flag 
נקודת קצה API זו מספקת את היכולת לבטל דיווח על תגובה עבור משתמש ספציפי.
הערות:
- קריאה זו חייבת תמיד להיעשות בהקשר של משתמש. המשתמש יכול להיות משתמש FastComments.com, משתמש SSO או משתמש שוכר.
- לאחר שתגובה מאושרת אוטומטית (מוסתרת) - התגובה יכולה להיות מאושרת מחדש רק על ידי מנהל או מנחה. ביטול הדיווח לא יאשר מחדש את התגובה.

לדיווח אנונימי, עלינו לציין anonUserId. זה יכול להיות מזהה שמייצג את ההפעלה האנונימית, או UUID אקראי.



POST /api/v1/comments/:id/block 
נקודת קצה API זו מספקת את היכולת לחסום משתמש שכתב תגובה נתונה. היא תומכת בחסימה מתגובות שנכתבו על ידי משתמשי FastComments.com, משתמשי SSO ומשתמשי שוכר.
היא תומכת בפרמטר גוף commentIdsToCheck כדי לבדוק אם תגובות אחרות שעלולות להיות גלויות בלקוח צריכות להיחסם/להיפתח לאחר ביצוע פעולה זו.
הערות:
- קריאה זו חייבת תמיד להיעשות בהקשר של משתמש. המשתמש יכול להיות משתמש FastComments.com, משתמש SSO או משתמש שוכר.
- ה-
userIdבבקשה הוא המשתמש שמבצע את החסימה. לדוגמה:משתמש א'רוצה לחסום אתמשתמש ב'. העברuserId=משתמש א'ואת מזהה התגובה שמשתמש ב'כתב. - תגובות אנונימיות לחלוטין (ללא מזהה משתמש, ללא אימייל) לא ניתנות לחסימה ושגיאה תוחזר.

לחסימה אנונימית, עלינו לציין anonUserId. זה יכול להיות מזהה שמייצג את ההפעלה האנונימית, או UUID אקראי.
זה מאפשר לנו לתמוך בחסימת תגובות גם אם משתמש לא מחובר על ידי אחזור התגובות עם אותו anonUserId.



POST /api/v1/comments/:id/un-block 
נקודת קצה API זו מספקת את היכולת לבטל חסימה של משתמש שכתב תגובה נתונה. היא תומכת בביטול חסימה מתגובות שנכתבו על ידי משתמשי FastComments.com, משתמשי SSO ומשתמשי שוכר.
היא תומכת בפרמטר גוף commentIdsToCheck כדי לבדוק אם תגובות אחרות שעלולות להיות גלויות בלקוח צריכות להיחסם/להיפתח לאחר ביצוע פעולה זו.
הערות:
- קריאה זו חייבת תמיד להיעשות בהקשר של משתמש. המשתמש יכול להיות משתמש FastComments.com, משתמש SSO או משתמש שוכר.
- ה-
userIdבבקשה הוא המשתמש שמבצע את ביטול החסימה. לדוגמה:משתמש א'רוצה לבטל חסימה שלמשתמש ב'. העברuserId=משתמש א'ואת מזהה התגובה שמשתמש ב'כתב. - תגובות אנונימיות לחלוטין (ללא מזהה משתמש, ללא אימייל) לא ניתנות לחסימה ושגיאה תוחזר.




מבנה תבנית דוא״ל 
אובייקט EmailTemplate מייצג קונפיגורציה לתבנית אימייל מותאמת אישית, עבור שוכר.
המערכת תבחר את תבנית האימייל לשימוש באמצעות:
- מזהה הסוג שלה, אנחנו קוראים לזה
emailTemplateId. אלה קבועים. - ה-
domain. אנחנו קודם ננסה למצוא תבנית עבור הדומיין שהאובייקט הקשור (כמוComment) קשור אליו, ואם לא נמצאה התאמה אז ננסה למצוא תבנית שבה domain הוא null או*.
המבנה עבור אובייקט EmailTemplate הוא כדלקמן:

הערות
- אתה יכול לקבל את ערכי
emailTemplateIdהחוקיים מנקודת הקצה/definitions. - נקודת הקצה
/definitionsכוללת גם את התרגומים ברירת המחדל ונתוני הבדיקה. - תבניות ייכשלו בשמירה עם מבנה או נתוני בדיקה לא חוקיים.
GET /api/v1/email-templates/:id 
ניתן לאחזר תבניות אימייל בודדות לפי ה-id התואם שלהן (לא emailTemplateId).



GET /api/v1/email-templates 
API זה משתמש בעימוד, המסופק על ידי פרמטר השאילתה page. תבניות אימייל מוחזרות בעמודים של 100, ממוינות לפי createdAt ולאחר מכן id.



PATCH /api/v1/email-templates/:id 
נקודת קצה API זו מספקת את היכולת לעדכן תבנית אימייל על ידי ציון המזהה והמאפיינים לעדכון בלבד.
שים לב שכל אותן בדיקות אימות ליצירת תבנית חלות גם כן, לדוגמה:
- התבנית חייבת להירנדר. זה נבדק עם כל עדכון.
- לא יכולות להיות תבניות כפולות לאותו דומיין (אחרת אחת תתעלם בשקט).



POST /api/v1/email-templates 
נקודת קצה API זו מספקת את היכולת ליצור תבניות אימייל.
הערות:
- לא יכולות להיות מספר תבניות עם אותו
emailTemplateIdעם אותו דומיין. - אבל אתה יכול לקבל תבנית עם תו כללי (
domain=*ותבנית ספציפית לדומיין לאותוemailTemplateId). - ציון
domainרלוונטי רק אם יש לך דומיינים שונים, או רוצה להשתמש בתבניות ספציפיות לבדיקות (domainמוגדר ל-localhostוכד'). - אם אתה כן מציין
domainהוא חייב להתאים ל-DomainConfig. בשגיאה מסופקת רשימה של דומיינים חוקיים. - תחביר התבנית הוא EJS והיא מרונדרת עם timeout של 500ms. P99 לרנדור הוא <5ms, אז אם אתה מגיע ל-500ms משהו לא בסדר.
- התבנית שלך חייבת להירנדר עם ה-
testDataהנתון כדי להישמר. שגיאות רנדור נאספות ומדווחות בדשבורד (בקרוב יהיה זמין דרך API).
הנתונים המינימליים הנדרשים להוספת תבנית הם כדלקמן:

ייתכן שתרצה תבניות לכל אתר, במקרה זה אתה מגדיר domain:



POST /api/v1/email-templates/render 
נקודת קצה API זו מספקת את היכולת להציג תצוגה מקדימה של תבניות אימייל.



DELETE /api/v1/email-templates/:id 
נתיב זה מספק הסרה של EmailTemplate יחידה לפי מזהה.



מבנה תגית 
אובייקט HashTag מייצג תגית שיכולה להיות מושארת על ידי משתמש. האשטאגים יכולים לשמש לקישור לתוכן חיצוני או
לקשר תגובות קשורות יחד.
המבנה עבור אובייקט HashTag הוא כדלקמן:

הערות:
- בחלק מנקודות הקצה של ה-API תראה שההאשטאג משמש ב-URL. זכור לקודד URI את הערכים. לדוגמה,
#צריך להיות מיוצג כ-%23. - חלק מהשדות הללו מסומנים כ-
READONLY- אלה מוחזרים על ידי ה-API אבל לא ניתן להגדיר אותם.
GET /api/v1/hash-tags 
API זה משתמש בעימוד, המסופק על ידי פרמטר השאילתה page. האשטאגים מוחזרים בעמודים של 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, אימייל ההזמנה יעזור לו להתחיל. אם כבר יש לו חשבון, הוא
יקבל גישת ניהול תוכן לשוכר שלך ומאפיין userId של אובייקט ה-Moderator יתעדכן להצביע על המשתמש שלו. לא תהיה לך גישת API
למשתמש שלהם, כי במקרה זה הוא שייך להם ומנוהל על ידי FastComments.com.
אם אתה דורש ניהול מלא של חשבון המשתמש, אנחנו ממליצים להשתמש ב-SSO, או להוסיף אותם כ-משתמש שוכר ו
לאחר מכן להוסיף אובייקט Moderator למעקב אחר הסטטיסטיקות שלהם.
ניתן להשתמש במבנה Moderator כמנגנון מעקב סטטיסטיקות עבור מקרי שימוש 1 ו-2. לאחר יצירת המשתמש, הוסף אובייקט Moderator
עם userId שלו מוגדר והסטטיסטיקות שלו יעקבו ב-דף מנהלי התגובות.
המבנה עבור אובייקט Moderator הוא כדלקמן:

GET /api/v1/moderators/:id 
נתיב זה מחזיר מנהל תוכן יחיד לפי המזהה שלו.



GET /api/v1/moderators 
API זה משתמש בעימוד, המסופק על ידי פרמטר השאילתה skip. מנהלי תוכן מוחזרים בעמודים של 100, ממוינים לפי createdAt ו-id.
העלות מבוססת על מספר מנהלי התוכן המוחזרים, עולה 1 קרדיט לכל 10 מנהלי תוכן מוחזרים.



PATCH /api/v1/moderators/:id 
נקודת קצה API זו מספקת את היכולת לעדכן Moderator לפי id.
לעדכון Moderator יש את ההגבלות הבאות:
- אין לספק את הערכים הבאים בעת עדכון
Moderator:acceptedInvitemarkReviewedCountdeletedCountmarkedSpamCountapprovedCounteditedCountbannedCountverificationIdcreatedAt
- כאשר מצוין
userId, המשתמש הזה חייב להתקיים. - כאשר מצוין
userId, הוא חייב להשתייך לאותוtenantIdשצוין בפרמטרי השאילתה. - שני מנהלי תוכן באותו שוכר לא יכולים להתווסף עם אותו
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 תווים.
הערות:
- אם משתמש עם האימייל שסופק כבר קיים, הוא יוזמן למתן את תגובות השוכר שלך.
- אם משתמש עם האימייל שסופק לא קיים קישור ההזמנה ינחה אותו דרך יצירת החשבון שלו.
- ההזמנה תפוג לאחר
30 יום.
אנחנו יכולים ליצור Moderator למשתמש שאנחנו מכירים רק את האימייל שלו:

זה ישלח אימייל כמו Bob ב-TenantName מזמין אותך להיות מנחה...


DELETE /api/v1/moderators/:id 
נתיב זה מספק הסרה של Moderator לפי מזהה.



מבנה ספירת התראות 
אובייקט 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 התואם שלהם. זה יכול להיות שימושי לחיפוש כותרות עמודים או ספירות תגובות.



טיפ שימושי
זכור לקודד URI לערכים כמו ה-urlId.
PATCH /api/v1/pages/:id 
נתיב זה מספק את היכולת לעדכן Page יחיד. התגובות המתאימות יעודכנו.



הערה
חלק מהפרמטרים באובייקט Page מתעדכנים אוטומטית. אלה הם מאפייני הספירות והכותרת. לא ניתן לעדכן ספירות
דרך ה-API מכיוון שאלה ערכים מחושבים. ניתן להגדיר את title של העמוד דרך ה-API, אך הוא יידרס אם ווידג'ט התגובות משמש על
עמוד עם אותו urlId וכותרת עמוד שונה.
POST /api/v1/pages 
נקודת קצה API זו מספקת את היכולת ליצור עמודים.
מקרה שימוש נפוץ הוא בקרת גישה.
הערות:
- אם הגבת בשרשור תגובות, או קראת ל-API ליצירת
Comment, כבר יצרת אובייקטPage! אתה יכול לנסות לאחזר אותו דרך נתיב/by-url-idשלPage, תוך העברת אותוurlIdשהועבר לווידג'ט התגובות. - מבנה ה-
Pageמכיל כמה ערכים מחושבים. כרגע, אלה הםcommentCountו-rootCommentCount. הם מאוכלסים אוטומטית ולא ניתן להגדיר אותם על ידי ה-API. ניסיון לעשות זאת יגרום ל-API להחזיר שגיאה.



DELETE /api/v1/pages/:id 
נתיב זה מספק הסרה של עמוד בודד לפי מזהה.
שים לב שאינטראקציה עם ווידג'ט התגובות לעמוד עם אותו urlId פשוט תיצור מחדש את Page בצורה חלקה.



מבנה אירוע Webhook ממתין 
אובייקט 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 יחיד.
אם אתה צריך מחיקה בכמות, קרא ל-API של GET עם עימוד ואז קרא ל-API זה ברצף.



מבנה משתמש SSO 
FastComments מספק פתרון SSO קל לשימוש. עדכון המידע של משתמש בעזרת האינטגרציה מבוססת HMAC הוא פשוט כמו לגרום למשתמש לטעון את הדף עם מטען מעודכן.
עם זאת, ייתכן ותרצו לנהל משתמש מחוץ לזרימה זו, כדי לשפר את העקביות של היישום שלכם.
ממשק ה-SSO User API מספק דרך לבצע CRUD על אובייקטים שאנו קוראים להם SSOUsers. אובייקטים אלה שונים ממשתמשים רגילים ונשמרים בנפרד למען בטיחות טיפוסים.
המבנה של אובייקט SSOUser הוא כדלקמן:

חיוב עבור משתמשי SSO
משתמשי SSO מחוייבים באופן שונה בהתאם לדגלי ההרשאה שלהם:
- משתמשי SSO רגילים: משתמשים ללא הרשאות מנהל או מודרציה מחוייבים כמשתמשי SSO רגילים
- מנהלי SSO: משתמשים עם הדגלים
isAccountOwnerאוisAdminAdminמחוייבים בנפרד כ-מנהלי SSO (אותו שיעור כמו מנהלי שוכר רגילים) - מודרטורים של SSO: משתמשים עם הדגל
isCommentModeratorAdminמחוייבים בנפרד כ-מודרטורים של SSO (אותו שיעור כמו מודרטורים רגילים)
חשוב: כדי למנוע חיוב כפול, המערכת מבטלת כפילויות אוטומטית בין משתמשי SSO לבין משתמשי שוכר רגילים ומודרטורים על בסיס כתובת אימייל. אם למשתמש SSO יש את אותה כתובת אימייל כמו משתמש שוכר רגיל או מודרטור, הוא לא יחויב פעמיים.
בקרת גישה
משתמשים יכולים להיות מחולקים לקבוצות. לזה מיועד השדה groupIds, והוא אופציונלי.
@אזכורים
ברירת המחדל @mentions ישתמש ב-username כדי לחפש משתמשי SSO אחרים כאשר מקלידים את התו @. אם משתמשים ב-displayName, אז תוצאות התואמות ל-username יידחו כאשר יש התאמה ל-displayName, ותוצאות החיפוש של ה-@mention ישתמשו ב-displayName.
מנויים
ב-FastComments, משתמשים יכולים להירשם לדף על ידי לחיצה על סמל הפעמון בווידג'ט התגובות ולחיצה על הרשמה.
עם משתמש רגיל, אנו שולחים לו אימיילי התראות על בסיס הגדרות ההתראות שלו.
עם משתמשי SSO, אנו מפצלים זאת לתאימות לאחור. משתמשים יקבלו הודעות אימייל נוספות אלה רק אם תגדירו את optedInSubscriptionNotifications ל-true.
סמלים
ניתן להקצות סמלים למשתמשי SSO באמצעות השדה badgeConfig. סמלים הם אינדיקטורים ויזואליים המופיעים לצד שם המשתמש בתגובות.
badgeIds- מערך מזהי סמלים שיוקצו למשתמש. אלה סמלים גלובליים הנראים בכל הדפים. חייבים להיות מזהי סמלים תקפים שנוצרו בחשבון FastComments שלך. מוגבלים ל-30 סמלים.pageBadgeIds- מערך מזהי סמלים אופציונלי המוגדר לדף הנוכחי (urlId). סמלים אלה מוצגים רק בדף שבו הוקצו. דפים שונים יכולים להכיל סמלים ספציפיים לדף שונים עבור אותו משתמש.override- אם true, כל הסמלים המוצגים הקיימים יוחלפו באלו שסופקו. סמלים גלובליים וספציפיים לדף מוחלפים באופן עצמאי — החלפה של סמלים גלובליים לא משפיעה על סמלים ספציפיים לדף, ולהפך. אם false או לא צויין, הסמלים שסופקו יתווספו לסמלים הקיימים.update- אם true, תכונות תצוגת הסמל יעודכנו מתוך תצורת השוכר כל פעם שהמשתמש ייכנס.
GET /api/v1/sso-users 
נתיב זה מחזיר משתמשי SSO בעמודים של 100. עימוד מסופק על ידי פרמטר skip. משתמשים ממוינים לפי signUpDate ו-id שלהם.



GET /api/v1/sso-users/by-id/:id 
נתיב זה מחזיר משתמש SSO יחיד לפי המזהה שלו.



GET /api/v1/sso-users/by-email/:email 
נתיב זה מחזיר משתמש SSO יחיד לפי האימייל שלו.



PATCH /api/v1/sso-users/:id 
נתיב זה מספק את היכולת לעדכן משתמש SSO יחיד.



POST /api/v1/sso-users 
נתיב זה מספק יצירה של משתמש SSO יחיד.
ניסיון ליצור שני משתמשים עם אותו מזהה יגרום לשגיאה.

בדוגמה זו אנחנו מציינים groupIds לבקרת גישה, אבל זה אופציונלי.


הערת אינטגרציה
נתונים שמועברים על ידי ה-API יכולים להידרס פשוט על ידי העברת מטען HMAC של משתמש SSO שונה. לדוגמה, אם אתה מגדיר שם משתמש דרך ה-API, אבל אז מעביר שם אחר דרך זרימת ה-SSO בטעינת העמוד, אנחנו נעדכן אוטומטית את שם המשתמש שלו.
אנחנו לא נעדכן פרמטרי משתמש בזרימה זו אלא אם כן אתה מציין אותם במפורש או מגדיר אותם ל-null (לא undefined).
PUT /api/v1/sso-users/:id 
נתיב זה מספק את היכולת לעדכן משתמש SSO יחיד.

בדוגמה זו אנו מציינים groupIds לבקרת גישה, אך זה אופציונלי.


DELETE /api/v1/sso-users/:id 
נתיב זה מספק הסרה של משתמש SSO יחיד לפי המזהה שלו.
שים לב שטעינת ווידג'ט התגובות שוב עם מטען עבור משתמש זה פשוט תיצור מחדש את המשתמש בצורה חלקה.
מחיקת התגובות של המשתמש אפשרית באמצעות פרמטר השאילתה deleteComments. שים לב שאם זה true:
- כל התגובות של המשתמש יימחקו בזמן אמת.
- כל התגובות ילדים (עכשיו יתומות) יימחקו או יאונמו בהתבסס על קונפיגורציית העמוד המשויכת לכל תגובה. לדוגמה אם מצב מחיקת שרשור הוא "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 נוצרים כאשר משתמש לוחץ על פעמון ההתראות בווידג'ט התגובות ולוחץ על "הירשם לעמוד זה".
ניתן גם ליצור מנויים דרך ה-API.
קיום אובייקט Subscription גורם ליצירת אובייקטי Notification, ושליחת אימיילים, כאשר תגובות חדשות נשארות בשורש העמוד המשויך
שה-Subscription הוא עבורו. שליחת אימיילים תלויה בסוג המשתמש. למשתמשים רגילים זה תלוי ב-optedInNotifications. למשתמשי SSO זה תלוי ב-optedInSubscriptionNotifications. שים לב שלחלק מהאפליקציות אולי אין את הרעיון של עמוד נגיש לאינטרנט, במקרה זה פשוט הגדר את urlId ל-
מזהה הפריט שאתה נרשם אליו (אותו ערך עבור 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 יחיד לפי מזהה.



מבנה שימוש יומי של שוכר 
אובייקט TenantDailyUsage מייצג את השימוש של שוכר ביום נתון. אם לא הייתה פעילות לשוכר נתון ביום נתון,
אותו יום לא יהיה לו אובייקט TenantDailyUsage.
אובייקט TenantDailyUsage אינו בזמן אמת ועשוי להיות מספר דקות מאחורי השימוש בפועל.
המבנה עבור אובייקט TenantDailyUsage הוא כדלקמן:

GET /api/v1/tenant-daily-usage 
נתיב זה מאפשר חיפוש שימוש של שוכר לפי שנה, חודש ויום. ניתן להחזיר עד 365 אובייקטים, והעלות היא 1 קרדיט API לכל 10 אובייקטים.
אובייקטי תגובה ממוינים לפי התאריך שבו נוצרו (הישן ביותר קודם).



מבנה שוכר 
Tenant מגדיר לקוח של FastComments.com. ניתן ליצור אותם דרך ה-API על ידי שוכרים עם גישת white labeling. שוכרי white labeled
לא יכולים ליצור שוכרי white labeled אחרים (רק רמה אחת של קינון מותרת).
המבנה עבור אובייקט Tenant הוא כדלקמן:

GET /api/v1/tenants/:id 
נתיב זה מחזיר שוכר יחיד לפי מזהה.



GET /api/v1/tenants 
API זה מחזיר שוכרים המנוהלים על ידי השוכר שלך.
עימוד מסופק על ידי פרמטר השאילתה skip. שוכרים מוחזרים בעמודים של 100, מסודרים לפי signUpDate, ו-id.
העלות מבוססת על מספר השוכרים שהוחזרו, בעלות של 1 קרדיט לכל 10 שוכרים שהוחזרו.

אתה יכול להגדיר פרמטרי meta על אובייקטי ה-Tenant ולחפש שוכרים תואמים. לדוגמה, עבור המפתח someKey וערך המטא some-value, אנחנו יכולים
לבנות אובייקט JSON עם זוג מפתח/ערך זה ואז לקודד אותו כ-URI כפרמטר שאילתה לסינון:



POST /api/v1/tenants 
נתיב זה מספק את היכולת להוסיף Tenant יחיד.
ליצירת Tenant יש את ההגבלות הבאות:
- נדרש
name. - נדרש
domainConfiguration. - הערכים הבאים לא ניתנים לספק בעת יצירת
Tenant:hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmount
- ה-
signUpDateלא יכול להיות בעתיד. - ה-
nameלא יכול להיות ארוך מ-200 תווים. - ה-
emailלא יכול להיות ארוך מ-300 תווים. - ה-
emailחייב להיות ייחודי בכל שוכרי FastComments.com. - לא ניתן ליצור שוכרים אם לשוכר האב אין
TenantPackageתקף מוגדר.- אם השוכר שלך נוצר דרך FastComments.com, זו לא אמורה להיות בעיה.
- לא ניתן ליצור יותר שוכרים מהמוגדר תחת
maxWhiteLabeledTenantsבחבילה שלך. - חייב לציין את פרמטר השאילתה
tenantIdשהוא המזהה שלשוכר האבשלך עם תיוג לבן מופעל.
אנחנו יכולים ליצור Tenant עם רק כמה פרמטרים:



PATCH /api/v1/tenants/:id 
נקודת קצה API זו מספקת את היכולת לעדכן Tenant לפי id.
לעדכון Tenant יש את ההגבלות הבאות:
- הערכים הבאים לא ניתנים לעדכון:
hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmountmanagedByTenantId
- ה-
signUpDateלא יכול להיות בעתיד. - ה-
nameלא יכול להיות ארוך מ-200 תווים. - ה-
emailלא יכול להיות ארוך מ-300 תווים. - ה-
emailחייב להיות ייחודי בכל שוכרי FastComments.com. - כאשר מגדירים
billingInfoValidל-true, יש לספקbillingInfoבאותה בקשה. - לא ניתן לעדכן את ה-
packageIdהמשויך לשוכר שלך עצמו. - לא ניתן לעדכן את ה-
paymentFrequencyהמשויך לשוכר שלך עצמו.



DELETE /api/v1/tenants/:id 
נתיב זה מספק הסרה של Tenant וכל הנתונים המשויכים (משתמשים, תגובות, וכו') לפי מזהה.
ההגבלות הבאות קיימות סביב הסרת שוכרים:
- השוכר חייב להיות שלך, או שוכר white labeled שאתה מנהל.
- פרמטר השאילתה
sureחייב להיות מוגדר ל-true.



מבנה חבילת שוכר 
TenantPackage מגדיר מידע על חבילה זמינה ל-Tenant. לשוכר עשויות להיות חבילות רבות זמינות, אבל רק
אחת בשימוש בזמן נתון.
לא ניתן להשתמש ב-Tenant עבור מוצרים כלשהם עד ש-packageId שלו מצביע על TenantPackage חוקי.
ישנם שני סוגים של אובייקטי TenantPackage:
- חבילות מחיר קבוע - שבהן
hasFlexPricingהוא false. - תמחור גמיש - שבו
hasFlexPricingהוא true.
בשני המקרים מוגדרות מגבלות על החשבון שמשתמש בחבילה, אולם עם Flex השוכר מחויב במחיר בסיס בתוספת
מה שהשתמש, המוגדר על ידי פרמטרי flex*.
לשוכר עשויות להיות מספר חבילות שוכר ויכולת לשנות את החבילה בעצמו מ-דף פרטי החיוב.
אם אתה מתכנן לטפל בחיוב עבור שוכרים בעצמך, עדיין תצטרך להגדיר חבילה לכל שוכר כדי להגדיר את המגבלות שלהם. פשוט הגדר billingHandledExternally ל-true על ה-Tenant והם
לא יוכלו לשנות את פרטי החיוב שלהם, או את החבילה הפעילה, בעצמם.
אתה לא יכול ליצור חבילות עם מגבלות גבוהות יותר מהשוכר האב.
המבנה עבור אובייקט TenantPackage הוא כדלקמן:

GET /api/v1/tenant-packages/:id 
נתיב זה מחזיר חבילת שוכר יחידה לפי מזהה.



GET /api/v1/tenant-packages 
API זה משתמש בעימוד, המסופק על ידי פרמטר השאילתה skip. TenantPackages מוחזרים בעמודים של 100, מסודרים לפי createdAt ו-id.
העלות מבוססת על מספר חבילות השוכר שהוחזרו, בעלות של 1 קרדיט לכל 10 חבילות שוכר שהוחזרו.



POST /api/v1/tenant-packages 
נתיב זה מספק את היכולת להוסיף TenantPackage יחיד.
ליצירת TenantPackage יש את ההגבלות הבאות:
- הפרמטרים הבאים נדרשים:
nametenantIdmonthlyCostUSD- יכול להיות null.yearlyCostUSD- יכול להיות null.maxMonthlyPageLoadsmaxMonthlyAPICreditsmaxMonthlyCommentsmaxConcurrentUsersmaxTenantUsersmaxSSOUsersmaxModeratorsmaxDomainshasDebrandingforWhoTextfeatureTaglineshasFlexPricing- אם true, אז כל פרמטרי ה-flex*נדרשים.
- ה-
nameלא יכול להיות ארוך מ-50 תווים. - כל פריט
forWhoTextלא יכול להיות ארוך מ-200 תווים. - כל פריט
featureTaglinesלא יכול להיות ארוך מ-100 תווים. - ה-
TenantPackageחייב להיות "קטן יותר" מהשוכר האב. לדוגמה, כל פרמטרי ה-max*חייבים להיות בעלי ערכים נמוכים יותר מהשוכר האב. - שוכר עם תיוג לבן יכול להיות לו מקסימום חמש חבילות.
- רק שוכרים עם גישה לתיוג לבן יכולים ליצור
TenantPackage. - לא ניתן להוסיף חבילות לשוכר שלך עצמו. :)
אנחנו יכולים ליצור TenantPackage כדלקמן:



PATCH /api/v1/tenant-packages/:id 
נקודת קצה API זו מספקת את היכולת לעדכן TenantPackage לפי id.
לעדכון TenantPackage יש את ההגבלות הבאות:
- אם אתה מגדיר
hasFlexPricingל-true, אז כל פרמטרי ה-flex*נדרשים באותה בקשה. - ה-
nameלא יכול להיות ארוך מ-50 תווים. - כל פריט
forWhoTextלא יכול להיות ארוך מ-200 תווים. - כל פריט
featureTaglinesלא יכול להיות ארוך מ-100 תווים. - ה-
TenantPackageחייב להיות "קטן יותר" מהשוכר האב. לדוגמה, כל פרמטרי ה-max*חייבים להיות בעלי ערכים נמוכים יותר מהשוכר האב. - לא ניתן לשנות את ה-
tenantIdהמשויך ל-TenantPackage.



DELETE /api/v1/tenant-packages/:id 
נתיב זה מספק הסרה של TenantPackage לפי מזהה.
לא ניתן להסיר TenantPackage שנמצא בשימוש (ה-packageId של שוכר מצביע על החבילה). עדכן את ה-Tenant קודם.



מבנה משתמש שוכר 
TenantUser מגדיר User המנוהל על ידי שוכר ספציפי. החשבון שלו בשליטה מלאה של השוכר
שהוא משויך אליו, והחשבון שלו ניתן לעדכון או מחיקה דרך ממשק המשתמש או ה-API.
משתמשי שוכר יכולים להיות מנהלים עם כל ההרשאות וגישה ל-Tenant, או שהם יכולים להיות מוגבלים להרשאות ספציפיות ל
ניהול תגובות, גישה למפתחות API, וכו'.
המבנה עבור אובייקט TenantUser הוא כדלקמן:

GET /api/v1/tenant-users/:id 
נתיב זה מחזיר TenantUser יחיד לפי מזהה.



GET /api/v1/tenant-users 
API זה משתמש בעימוד, המסופק על ידי פרמטר השאילתה skip. TenantUsers מוחזרים בעמודים של 100, מסודרים לפי signUpDate, username ו-id.
העלות מבוססת על מספר משתמשי השוכר שהוחזרו, בעלות של 1 קרדיט לכל 10 משתמשי שוכר שהוחזרו.



POST /api/v1/tenant-users 
נתיב זה מספק את היכולת להוסיף TenantUser יחיד.
ליצירת TenantUser יש את ההגבלות הבאות:
- נדרש
username. - נדרש
email. - ה-
signUpDateלא יכול להיות בעתיד. - ה-
localeחייב להיות ברשימת לוקלים נתמכים. - ה-
usernameחייב להיות ייחודי בכל FastComments.com. אם זו בעיה, אנו מציעים להשתמש ב-SSO במקום זאת. - ה-
emailחייב להיות ייחודי בכל FastComments.com. אם זו בעיה, אנו מציעים להשתמש ב-SSO במקום זאת. - לא ניתן ליצור יותר משתמשי שוכר מהמוגדר תחת
maxTenantUsersבחבילה שלך.
אנחנו יכולים ליצור TenantUser כדלקמן



POST /api/v1/tenant-users/:id/send-login-link 
נתיב זה מספק את היכולת לשלוח קישור התחברות ל-TenantUser יחיד.
שימושי בעת יצירת משתמשים בכמות ללא צורך להנחות אותם כיצד להתחבר ל-FastComments.com. זה פשוט ישלח להם "קישור קסם" להתחברות שפג תוקף
לאחר 30 יום.
ההגבלות הבאות קיימות לשליחת קישור התחברות ל-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 לפי מזהה.
מחיקת התגובות של המשתמש אפשרית באמצעות פרמטר השאילתה deleteComments. שים לב שאם זה true:
- כל התגובות של המשתמש יימחקו בזמן אמת.
- כל התגובות ילדים (עכשיו יתומות) יימחקו או יאונמו בהתבסס על קונפיגורציית העמוד המשויכת לכל תגובה. לדוגמה אם מצב מחיקת שרשור הוא "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 לתגובה. ניתן להתאים אישית אלה דרך ממשק המשתמש של התאמת הווידג'ט.
דוגמאות



מבנה משתמש 
User הוא אובייקט המייצג מכנה משותף של כל המשתמשים.
זכור שב-FastComments יש לנו מספר מקרי שימוש שונים למשתמשים:
- SSO מאובטח
- SSO פשוט
- משתמשי שוכר (לדוגמה: מנהלים)
- מגיבים
API זה מיועד למגיבים ולמשתמשים שנוצרו דרך SSO פשוט. בעצם, כל משתמש שנוצר
דרך האתר שלך ניתן לגישה דרך API זה. ניתן לאחזר גם משתמשי שוכר בדרך זו, אך תקבל מידע נוסף על ידי אינטראקציה עם ה-API /tenant-users/.
עבור SSO מאובטח אנא השתמש ב-API /sso-users/.
לא ניתן לעדכן סוגים אלה של משתמשים. הם יצרו את החשבון שלהם דרך האתר שלך, אז אנו מספקים גישה בסיסית לקריאה בלבד, אבל
לא ניתן לבצע שינויים. אם אתה רוצה לקבל זרימה כזו - אתה צריך להגדיר SSO מאובטח.
המבנה עבור אובייקט User הוא כדלקמן:

GET /api/v1/users/:id 
נתיב זה מחזיר User יחיד לפי מזהה.



מבנה הצבעה 
אובייקט 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.
מזהה זה לא חייב להתאים לאובייקט משתמש בשום מקום (ומכאן אנונימי). זה פשוט מזהה עבור הסשן, כך שתוכל לאחזר הצבעות שוב באותו סשן, כדי לבדוק אם הצביעו על תגובה.
אם אין לך דבר כזה כמו "סשנים אנונימיים" כמו ל-FastComments - אתה יכול פשוט להגדיר זאת למזהה אקראי, כמו UUID (אם כי אנחנו מעריכים מזהים קטנים יותר לחיסכון במקום).
הערות נוספות
- API זה מציית להגדרות ברמת השוכר. לדוגמה, אם אתה משבית הצבעות לעמוד נתון, וניסית ליצור הצבעה דרך ה-API, זה ייכשל עם קוד שגיאה
voting-disabled. - API זה הוא בזמן אמת כברירת מחדל.
- API זה יעדכן את
votesשלCommentהמתאים.
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 UI תסיר כל תצורה מקבילה עבור אותו דומיין שעשויה להיות נוספה דרך ממשק זה.
להתאמה אישית של אימיילים
קישור ההסרה בכותרת התחתונה של המייל, ותכונת 'הסרה בלחיצה אחת' שמוצעת על ידי לקוחות דוא״ל רבים, ניתנים להגדרה דרך ה-API הזה על ידי הגדרת footerUnsubscribeURL ו-emailHeaders, בהתאמה.
לגבי DKIM
לאחר שהגדרתם את רשומות ה-DNS של DKIM שלכם, פשוט עדכנו את 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 יחיד לפי מזהה.
- הערה: הסרת
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 יחיד לפי המזהה שלו.



POST /api/v1/question-configs 
נקודת קצה API זו מספקת את היכולת ליצור QuestionConfig.



PATCH /api/v1/question-configs/:id 
נתיב זה מספק את היכולת לעדכן QuestionConfig יחיד.
המבנה הבא מייצג את כל הערכים שניתן לשנות:




DELETE /api/v1/question-configs/:id 
נתיב זה מספק הסרה של QuestionConfig לפי מזהה.
זה ימחק את כל תוצאות השאלות המתאימות (אך לא את התגובות). זה חלק מעלות הקרדיטים הגבוהה.



מבנה תוצאת שאלה 
כדי לשמור תוצאות לשאלות, אתה יוצר QuestionResult. לאחר מכן תוכל לאגור תוצאות שאלות, וגם
לקשר אותן לתגובות למטרות דיווח.

GET /api/v1/question-results 
נתיב זה מחזיר עד 1000 אובייקטי QuestionResults בכל פעם, מעומדים. העלות היא 1 לכל 100 אובייקטים. הם
ממוינים לפי createdAt, בסדר עולה. אתה יכול לסנן לפי פרמטרים שונים.



GET /api/v1/question-results/:id 
נתיב זה מחזיר QuestionResult יחיד לפי המזהה שלו.



POST /api/v1/question-results 
נקודת קצה API זו מספקת את היכולת ליצור QuestionResult.



PATCH /api/v1/question-results/:id 
נתיב זה מספק את היכולת לעדכן QuestionResult יחיד.
המבנה הבא מייצג את כל הערכים שניתן לשנות:




DELETE /api/v1/question-results/:id 
נתיב זה מספק הסרה של QuestionResult לפי מזהה.



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 
נקודת קצה זו מאפשרת לך לאחזר תג משתמש ספציפי לפי המזהה הייחודי שלו.
דוגמת בקשה:
Run 
דוגמת תגובה:

תגובות שגיאה אפשריות:


POST /api/v1/user-badges 
נקודת קצה זו מאפשרת לך ליצור הקצאת תג משתמש חדשה.
דוגמת בקשה:
Run 
גוף הבקשה חייב להכיל את הפרמטרים הבאים:
userId(נדרש) - מזהה המשתמש להקצאת התג אליוbadgeId(נדרש) - מזהה התג להקצאהdisplayedOnComments(אופציונלי) - האם התג יוצג בתגובות המשתמש (ברירת מחדל true)
הערות חשובות:
- התג חייב להתקיים ולהיות מופעל בקטלוג התגים של השוכר שלך
- אתה יכול להקצות תגים רק למשתמשים השייכים לשוכר שלך או שהגיבו באתר שלך
דוגמת תגובה:

תגובות שגיאה אפשריות:





PUT /api/v1/user-badges/:id 
נקודת קצה זו מאפשרת לך לעדכן הקצאת תג משתמש.
כרגע, המאפיין היחיד שניתן לעדכן הוא displayedOnComments, השולט האם התג מוצג בתגובות המשתמש.
דוגמת בקשה:
Run 
דוגמת תגובה:

תגובות שגיאה אפשריות:



DELETE /api/v1/user-badges/:id 
נקודת קצה זו מאפשרת לך למחוק הקצאת תג משתמש.
דוגמת בקשה:
Run 
דוגמת תגובה:

תגובות שגיאה אפשריות:



מבנה התקדמות תגי משתמש 
UserBadgeProgress הוא אובייקט המייצג את ההתקדמות של משתמש לקראת קבלת תגים שונים במערכת FastComments.
מעקב זה עוזר לקבוע מתי משתמשים צריכים לקבל תגים אוטומטיים בהתבסס על הפעילות וההשתתפות שלהם בקהילה שלך.
המבנה עבור אובייקט UserBadgeProgress הוא כדלקמן:

GET /api/v1/user-badge-progress 
נקודת קצה זו מאפשרת לך לשלוף רשומות של התקדמות תגי משתמש בהתבסס על קריטריונים שונים.
Example Request:
Run 
ניתן להוסיף פרמטרי שאילתה שונים כדי לסנן את התוצאות:
userId- קבל התקדמות עבור משתמש ספציפיlimit- מספר מקסימלי של רשומות להחזרה (ברירת מחדל 30, מקסימום 200)skip- מספר רשומות לדלג (לעימוד)
Example Response:

Possible Error Responses:


GET /api/v1/user-badge-progress/:id 
נקודת קצה זו מאפשרת לך לאחזר רשומת התקדמות תג משתמש ספציפית לפי המזהה הייחודי שלה.
דוגמת בקשה:
Run 
דוגמת תגובה:

תגובות שגיאה אפשריות:


GET /api/v1/user-badge-progress/user/:userId 
נקודת קצה זו מאפשרת לך לאחזר רשומת התקדמות תג של משתמש לפי מזהה המשתמש שלו.
דוגמת בקשה:
Run 
דוגמת תגובה:

תגובות שגיאה אפשריות:



לסיכום
אנו מקווים שמצאתם את תיעוד ה-API שלנו מקיף וקל להבנה. אם מצאתם פערים, אנא עדכנו אותנו למטה.