
भाषा 🇮🇳 हिन्दी
API संसाधन
प्रमाणीकरण
एकत्रीकरण
AuditLogs
बैच जॉब
टिप्पणियाँ
EmailTemplates
फ़ीड पोस्ट
हैशटैग
मैं
मॉडरेटर
सूचना संख्या
सूचनाएँ
पेज रिएक्ट्स
पेज
पोल
पोल वोट
PendingWebhookEvents
SSO उपयोगकर्ता
सदस्यताएँ
टेनेंट दैनिक उपयोग
टेनेंट
टेनेंट पैकेज
टेनेंट उपयोगकर्ता
उपयोगकर्ता
वोट
डोमेन कॉन्फ़िग
प्रश्न कॉन्फ़िग
प्रश्न परिणाम
प्रश्न परिणाम एकत्रीकरण
उपयोगकर्ता बैज
उपयोगकर्ता बैज प्रगति
लाइव टिप्पणी APIs
FastComments API
FastComments कई संसाधनों (resources) के साथ इंटरैक्ट करने के लिए एक API प्रदान करता है। हमारे प्लेटफ़ॉर्म के साथ इंटीग्रेशन बनाएं, या अपने स्वयं के क्लाइंट भी बनाएं!
इस दस्तावेज़ीकरण में, आपको API द्वारा समर्थित सभी संसाधनों का दस्तावेज़ीकरण उनके रिक्वेस्ट और रिस्पॉन्स प्रकारों के साथ मिलेगा।
Enterprise ग्राहकों के लिए, सभी API एक्सेस Audit Log में कैप्चर किया जाता है।
जेनरेट किए गए SDKs
FastComments अब हमारे कोड से एक API Spec जेनरेट करता है (यह अभी पूरा नहीं है, लेकिन इसमें कई APIs शामिल हैं)।
हमारे पास अब लोकप्रिय भाषाओं के लिए 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
प्रमाणीकरण (Authentication)
API आपकी api key को X-API-KEY हेडर या API_KEY क्वेरी पैरामीटर के रूप में पास करके प्रमाणित की जाती है। API कॉल करने के लिए आपको अपनी tenantId भी चाहिए होगी। यह आपकी api key वाले उसी पेज से प्राप्त की जा सकती है।
सुरक्षा नोट
इन रूट्स को सर्वर से कॉल करने के लिए ही है। इन्हें ब्राउज़र से कॉल न करें। ऐसा करने से आपकी API key उजागर हो जाएगी - इससे आपके खाते तक पूर्ण एक्सेस उन सभी को मिल जाएगा जो किसी पेज का सोर्स कोड देख सकते हैं!
प्रमाणीकरण विकल्प एक - Headers
- Header:
X-API-KEY - Header:
X-TENANT-ID
प्रमाणीकरण विकल्प दो - Query Parameters
- Query Param:
API_KEY - Query Param:
tenantId
प्रमाणीकरण विकल्प तीन - OAuth Bearer Token
- Header:
Authorization: Bearer fcat_...
Zapier जैसे थर्ड-पार्टी एप्लिकेशन और MCP server के क्लाइंट API key के बजाय OAuth के माध्यम से एक टोकन प्राप्त करते हैं। वह टोकन यहाँ हर एंडपॉइंट पर काम करता है। टोकन से tenant निहित रहता है, इसलिए tenantId वैकल्पिक है, लेकिन दिया जाने पर यह टोकन से मेल खाना चाहिए। GET रिक्वेस्ट को read स्कोप की आवश्यकता होती है और हर अन्य मेथड को write स्कोप की। पूरा फ़्लो, जिसमें क्लाइंट रजिस्ट्रेशन, PKCE, रिफ्रेश और रिवोकेशन शामिल है, OAuth Authorization के अंतर्गत दस्तावेज़ित है। डिस्कवरी https://fastcomments.com/.well-known/oauth-authorization-server से शुरू होती है।
अपने स्वयं के राइट्स पढ़ना (Reading Your Own Writes)
FastComments Active-Active उपलब्धता प्रदान करता है। आपके डेटासेंटर से रिक्वेस्ट आपके निकटतम पॉइंट ऑफ़ प्रेज़ेंस पर रूट की जाती हैं। यह स्वचालित है, और सामान्यतः आप read-your-write सिमेंटिक्स देख सकते हैं। यदि आप यह सुनिश्चित करना चाहते हैं कि आप अपने स्वयं के राइट्स पढ़ें, तो आप उस क्षेत्र को अपने API होस्ट के रूप में उपयोग करके अपनी रिक्वेस्ट को एक निश्चित क्षेत्र (region) पर पिन कर सकते हैं (हालाँकि अधिकांश इंटीग्रेशन के लिए यह सामान्यतः आवश्यक नहीं है):
- 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
ध्यान दें कि यदि आप ऐसा करते हैं तो आप एक फ़ॉलबैक परिभाषित करना चाह सकते हैं, क्योंकि हमने अतीत में एंट्रीपॉइंट नोड्स को deprecated किया है और स्विचओवर के लिए नए नामों का उपयोग किया है।
API संसाधन 
संसाधन उपयोग
यह ध्यान दिया जाना चाहिए कि API से डेटा प्राप्त करना आपके खाते पर उपयोग के रूप में गिना जाता है।
प्रत्येक संसाधन अपने स्वयं के अनुभाग में यह बताएगा कि वह उपयोग क्या है।
कुछ संसाधनों को सर्व करना अन्य की तुलना में अधिक महंगा होता है। प्रत्येक एंडपॉइंट की प्रति API कॉल क्रेडिट्स की एक निश्चित लागत होती है। कुछ एंडपॉइंट्स के लिए, क्रेडिट्स की संख्या विकल्पों और रिस्पॉन्स साइज़ के आधार पर भिन्न होती है।
API उपयोग की जांच Billing Analytics पेज पर की जा सकती है और यह हर कुछ मिनटों में अपडेट होता है।
ध्यान दें!
हम सुझाव देते हैं कि पहले Pages दस्तावेज़ीकरण पढ़ें, ताकि Comment API में urlId के लिए कौन से मान पास करने हैं, यह निर्धारित करते समय भ्रम को सीमित करने में मदद मिले।
Webhooks
Webhook सब्सक्रिप्शन की अपनी एक गाइड है। POST, GET और DELETE /api/v1/webhooks, तथा GET /api/v1/webhooks/sample-payloads, को Managing Subscriptions via API के अंतर्गत दस्तावेज़ित किया गया है, और इवेंट पेलोड्स को Webhook Structures के अंतर्गत।
OAuth प्राधिकरण 
FastComments एक OAuth 2.1 ऑथराइज़ेशन सर्वर है। एक एप्लिकेशन एक टोकन प्राप्त कर सकता है जो एक FastComments खाते से बंधा होता है और इस गाइड में हर एंडपॉइंट पर API की के स्थान पर उसका उपयोग कर सकता है। Zapier ऐप, MCP सर्वर, और अन्य थर्ड-पार्टी इंटीग्रेशन इसी तरह कनेक्ट होते हैं।
टोकन PKCE के साथ ऑथराइज़ेशन कोड फ्लो के माध्यम से जारी किए जाते हैं। कोई client credentials या implicit grant नहीं है।
डिस्कवरी
एंडपॉइंट के स्थान, समर्थित ग्रांट, और ऑथ मेथड्स मानक मेटाडेटा URL पर प्रकाशित होते हैं:

इसके द्वारा वर्णित एंडपॉइंट:

EU क्षेत्र के खाते https://eu.fastcomments.com को issuer के रूप में उपयोग करते हैं, उसी पाथ के साथ।
क्लाइंट रजिस्टर करना
फ्लो शुरू करने से पहले एक क्लाइंट को client_id और एक रजिस्टर्ड redirect_uri की आवश्यकता होती है। इसे प्राप्त करने के दो तरीके हैं:
- डायनामिक क्लाइंट रजिस्ट्रेशन। RFC 7591 के अनुसार JSON बॉडी के साथ
POST /oauth/register(redirect_uris,client_name,client_uri,logo_uri,token_endpoint_auth_method)। रिस्पॉन्स मेंclient_idऔर, कॉन्फिडेंशियल क्लाइंट्स के लिए,client_secretहोता है। रजिस्ट्रेशन बिना ऑथेंटिकेशन के होता है और प्रति IP रेट लिमिटेड है। - क्लाइंट ID मेटाडेटा डॉक्यूमेंट। क्लाइंट अपने नियंत्रण वाले एक
httpsURL को अपनेclient_idके रूप में उपयोग करता है। FastComments उस URL को फ़ेच करता है और उससे वही मेटाडेटा फ़ील्ड पढ़ता है। किसी रजिस्ट्रेशन कॉल की आवश्यकता नहीं है।
FastComments डैशबोर्ड में सूचीबद्ध पार्टनर एप्लिकेशन, जैसे Zapier, सीधे FastComments द्वारा रजिस्टर किए जाते हैं। यदि आप मार्केटप्लेस लिस्टिंग बना रहे हैं और फर्स्ट-पार्टी क्लाइंट की आवश्यकता है तो सपोर्ट से संपर्क करें।
स्कोप

कोई स्कोप न मांगने वाला रिक्वेस्ट दोनों प्राप्त करता है। उपयोगकर्ता को कंसेंट पेज पर अनुरोधित स्कोप दिखाई देते हैं। इन दो के अलावा किसी अन्य स्कोप का अनुरोध invalid_scope के साथ विफल हो जाता है।
चरण 1 - ऑथराइज़ेशन रिक्वेस्ट
उपयोगकर्ता के ब्राउज़र को authorize एंडपॉइंट पर भेजें। हर क्लाइंट के लिए S256 मेथड के साथ PKCE आवश्यक है।


उपयोगकर्ता आवश्यकता होने पर FastComments में साइन इन करता है और एक कंसेंट पेज देखता है जिसमें आपका एप्लिकेशन, वह खाता जिससे इसे कनेक्ट किया जाएगा, और अनुरोधित स्कोप नामित होते हैं। उपयोगकर्ता के पास उस खाते पर API Admin अनुमति होनी चाहिए; कोई अन्य व्यक्ति कंसेंट फॉर्म के बजाय अनुमति त्रुटि देखता है। स्वीकृति करने पर ब्राउज़र आपके redirect_uri पर code और state के साथ रीडायरेक्ट होता है। अस्वीकृति करने पर error=access_denied के साथ रीडायरेक्ट होता है।
ऑथराइज़ेशन कोड 10 मिनट के लिए मान्य है और इसे एक बार एक्सचेंज किया जा सकता है। उसी कोड का दूसरा एक्सचेंज पहले एक्सचेंज द्वारा उत्पादित हर टोकन को रद्द कर देता है।
चरण 2 - टोकन रिक्वेस्ट
कोड को टोकन के लिए एक्सचेंज करें। बॉडी फॉर्म एनकोडेड है। कॉन्फिडेंशियल क्लाइंट्स client_secret_basic (HTTP Basic) या client_secret_post (बॉडी में सीक्रेट) के साथ ऑथेंटिकेट करते हैं। पब्लिक क्लाइंट्स केवल client_id भेजते हैं।



त्रुटियां RFC 6749 का पालन करती हैं: error और error_description के साथ JSON बॉडी, invalid_request, invalid_grant, invalid_scope, invalid_target और unsupported_grant_type के लिए HTTP 400, invalid_client के लिए HTTP 401, रेट लिमिटेड होने पर HTTP 429।
चरण 3 - API कॉल करना
एक्सेस टोकन को बेयरर टोकन के रूप में भेजें। टेनेंट टोकन द्वारा निहित होता है, इसलिए tenantId वैकल्पिक है। दिया जाने पर इसे टोकन से मेल खाना चाहिए अन्यथा रिक्वेस्ट विफल हो जाती है।

GET /api/v1/me टेनेंट, ऑथराइज़िंग उपयोगकर्ता, और प्रदान किए गए स्कोप लौटाता है, जो इसे कनेक्शन टेस्ट के लिए सही कॉल बनाता है। समाप्त या रद्द किए गए टोकन वाली रिक्वेस्ट को HTTP 401 मिलता है। जिस मेथड को टोकन के पास नहीं है उस स्कोप की आवश्यकता वाली रिक्वेस्ट को HTTP 403 मिलता है।
चरण 4 - रिफ्रेश करना


रिस्पॉन्स की आकृति कोड एक्सचेंज के समान है। रिफ्रेश टोकन रोटेट होते हैं: प्रत्येक रिफ्रेश एक नया refresh_token लौटाता है और समवर्ती रिक्वेस्ट्स के लिए 30 सेकंड की ग्रेस विंडो के बाद पुराने को रद्द कर देता है। 30 सेकंड से अधिक पहले रोटेट किए गए रिफ्रेश टोकन को प्रस्तुत करना रिप्ले माना जाता है और पूरे ग्रांट को रद्द कर देता है। FastComments द्वारा रजिस्टर किए गए पार्टनर एप्लिकेशन रोटेशन से मुक्त हैं और उन्हें वही रिफ्रेश टोकन वापस मिलता है जिसकी समाप्ति अन्य 30 दिनों तक बढ़ा दी जाती है।
एक रिफ्रेश यह भी पुनः जांचता है कि ऑथराइज़िंग उपयोगकर्ता अभी भी खाते पर API Admin है। यदि नहीं, तो ग्रांट रद्द कर दिया जाता है और रिस्पॉन्स invalid_grant होता है।
रद्दीकरण

एक रिफ्रेश टोकन को रद्द करने से उसी ग्रांट से जारी हर एक्सेस टोकन रद्द हो जाता है। एक एक्सेस टोकन को रद्द करने से केवल वही टोकन रद्द होता है। एंडपॉइंट RFC 7009 के अनुसार, टोकन मिले या न मिले, खाली JSON ऑब्जेक्ट के साथ HTTP 200 लौटाता है।
उपयोगकर्ता FastComments डैशबोर्ड में Connected Apps से भी कनेक्शन रद्द कर सकते हैं। उस एप्लिकेशन का हर टोकन तुरंत काम करना बंद कर देता है।
अपना डेटा एकत्रित करें 
यह API दस्तावेज़ों को समूहित करके (यदि groupBy दिया गया है) और कई ऑपरेशन लागू करके एकत्रित करता है। विभिन्न ऑपरेशन (जैसे sum, countDistinct, avg, आदि) समर्थित हैं।
लागत परिवर्तनशील है। स्कैन किए गए प्रत्येक 500 ऑब्जेक्ट पर 1 API क्रेडिट खर्च होता है।
डिफ़ॉल्ट रूप से प्रति API कॉल अधिकतम अनुमत मेमोरी उपयोग 64MB है, और डिफ़ॉल्ट रूप से आप एक समय में केवल एक एग्रीगेशन चला सकते हैं। यदि आप एक साथ कई एग्रीगेशन सबमिट करते हैं, तो उन्हें कतार में रखा जाएगा और सबमिट करने के क्रम में चलाया जाएगा। लंबित एग्रीगेशन अधिकतम 60 सेकंड तक प्रतीक्षा करेंगे, उसके बाद अनुरोध टाइम आउट हो जाएगा। प्रत्येक एग्रीगेशन अधिकतम 5 मिनट तक चल सकता है।
यदि आपके पास managed 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 एक ऐसा ऑब्जेक्ट है जो उन टेनेंट्स के लिए ऑडिट की गई घटना को दर्शाता है जिनके पास इस सुविधा तक पहुँच है।
AuditLog ऑब्जेक्ट की संरचना इस प्रकार है:

targetId और targetLabel यह बताते हैं कि घटना किस पर की गई; userId और username यह बताते हैं कि उसे किसने की। अपडेट के लिए, objectDetails.changes में वास्तव में क्या बदला, इसका एक {field: {from, to}} मैप होता है।
ऑडिट लॉग अपरिवर्तनीय (immutable) है। इसे मैन्युअल रूप से लिखा भी नहीं जा सकता। FastComments.com ही तय कर सकता है कि ऑडिट लॉग में कब लिखा जाए। हालाँकि, आप इस API के माध्यम से इसे पढ़ सकते हैं।
ऑडिट लॉग में घटनाएँ दो साल बाद समाप्त हो जाती हैं।
GET /api/v1/audit-logs 
यह API पेजिनेशन का उपयोग करती है, जो skip, limit, before, और after पैरामीटर द्वारा प्रदान की जाती है। AuditLogs डिफ़ॉल्ट रूप से 1000 के पेजों में लौटाए जाते हैं, अधिकतम limit 10000 तक, when और id के अनुसार क्रमबद्ध। पेज बड़े होते हैं क्योंकि इस एंडपॉइंट का उपयोग आमतौर पर इतिहास को इंटरैक्टिव रूप से पेज करने के बजाय डंप करने के लिए किया जाता है।
हर 100 लॉग लौटाने पर क्रेडिट लागत 1 होती है।
डिफ़ॉल्ट रूप से, आपको सबसे नए आइटम पहले के साथ एक सूची प्राप्त होगी। इस तरह, आप skip=0 से शुरू करके पोल कर सकते हैं और आखिरी उपभोग किए गए रिकॉर्ड को खोजने तक पेजिनेट कर सकते हैं।
वैकल्पिक रूप से, आप सबसे पुराने पहले के क्रम में सॉर्ट कर सकते हैं, और जब तक कोई और रिकॉर्ड न बचे तब तक पेजिनेट कर सकते हैं।
सॉर्टिंग order को ASC या DESC में सेट करके की जा सकती है। डिफ़ॉल्ट DESC है।
तारीख के अनुसार क्वेरी before और after के माध्यम से मिलीसेकंड के साथ टाइमस्टैम्प के रूप में संभव है। before और after समावेशी (inclusive) नहीं हैं, और इनमें से कोई भी अकेले उपयोग किया जा सकता है।
किसी व्यक्ति के साथ क्या हुआ, यह खोजना
हर इवेंट रिकॉर्ड करता है कि उसे किसने किया (username, userId, ip) और, अलग से, वह किस पर किया गया। targetLabel उस ऑब्जेक्ट का एक मानव-पठनीय लेबल है, उदाहरण के लिए jsmith (jsmith@example.com), और targetId उसकी id है। जब आप किसी व्यक्ति का नाम या ईमेल जानते हों लेकिन उनकी id नहीं, तो लेबल पर केस-असंवेदनशील सबस्ट्रिंग मैच के लिए target का उपयोग करें।
डिलीट इवेंट के समय का लेबल कैप्चर करते हैं, इसलिए मूल रिकॉर्ड हट जाने के बाद भी हटाए गए उपयोगकर्ता या मॉडरेटर की पहचान की जा सकती है।
प्रबंधित टेनेंट
यदि आपका टेनेंट अन्य टेनेंट प्रबंधित करता है, तो अपने टेनेंट और उसके द्वारा प्रबंधित हर टेनेंट के इवेंट एक ही प्रतिक्रिया में प्राप्त करने के लिए includeManagedTenants=true सेट करें। प्रत्येक लौटाए गए लॉग की tenantId बताती है कि वह किस टेनेंट से आया।



BatchJob संरचना 
एक BatchJob एक लंबे समय तक चलने वाला कार्य होता है, जैसे कोई import, export, या page migration। Jobs को queue में रखा जाता है, फिर background में उठाया और चलाया जाता है।
processedCount और totalCount प्रगति दिखाते हैं। इनकी इकाई type पर निर्भर करती है:
migrate-pages: पूर्ण हुई migrations, अनुरोधित migrations में से।undo-page-migration: पुनर्स्थापित records। यहाँ कोईtotalCountनहीं होता।import,exportऔर अन्य jobs: प्रोसेस की गई rows।
BatchJob object की संरचना इस प्रकार है:

Retries
यदि page migration job चलाने वाला server restart हो जाता है, तो job वापस queue में चला जाता है और अंतिम पूर्ण हुई migration के बाद से फिर शुरू होता है। एक job को अधिकतम 3 बार try किया जाता है, जिसके बाद उसका status failed हो जाता है।
GET /api/v1/batch-jobs 
यह रूट टेनेंट के सभी प्रकार के बैच जॉब लौटाता है, नवीनतम पहले, प्रति पेज 100। सूची को सीमित करने के लिए type और status का उपयोग करें, और पेजिंग के लिए skip का उपयोग करें।



GET /api/v1/batch-jobs/:id 
यह रूट एक बैच जॉब की स्थिति, प्रगति और, पूरा होने के बाद, उसका परिणाम लौटाता है। इसका उपयोग POST /api/v1/pages/migrations या POST /api/v1/pages/migrations/:undoId/undo द्वारा शुरू किए गए जॉब को ट्रैक करने के लिए करें।
एक जॉब तब पूरा होता है जब उसकी status success या failed हो। प्रत्येक कॉल 1 क्रेडिट की लागत रखता है, इसलिए लगातार पोल करने के बजाय कुछ सेकंड के अंतराल पर पोल करें।




Comment संरचना 
एक Comment ऑब्जेक्ट किसी उपयोगकर्ता द्वारा छोड़ी गई टिप्पणी को दर्शाता है।
पैरेंट और चाइल्ड कमेंट्स के बीच संबंध parentId के माध्यम से परिभाषित होता है।
Comment ऑब्जेक्ट की संरचना इस प्रकार है:

इनमें से कुछ फ़ील्ड READONLY चिह्नित हैं - ये API द्वारा लौटाई जाती हैं लेकिन सेट नहीं की जा सकतीं।
कमेंट टेक्स्ट संरचना
कमेंट्स FastComments के मार्कडाउन फ्लेवर में लिखी जाती हैं, जो मार्कडाउन के साथ इमेज के लिए पारंपरिक bbcode शैली के टैग जैसे [img]path[/img] हैं।
टेक्स्ट दो फ़ील्ड में संग्रहीत होता है। उपयोगकर्ता द्वारा दर्ज किया गया टेक्स्ट बिना बदले comment फ़ील्ड में संग्रहीत होता है। यह रेंडर होकर commentHTML फ़ील्ड में संग्रहीत होता है।
अनुमत HTML टैग हैं: b, u, i, strike, pre, span, code, img, a, strong, ul, ol, li, और br।
HTML रेंडर करने की सिफारिश की जाती है, क्योंकि यह HTML का बहुत छोटा सबसेट है, रेंडरर बनाना काफी सरल है। उदाहरण के लिए, React Native और Flutter के लिए इसमें मदद के लिए कई लाइब्रेरीज़ उपलब्ध हैं।
आप comment फ़ील्ड का अन-नॉर्मलाइज़्ड मान रेंडर करना चुन सकते हैं। एक उदाहरण पार्सर यहाँ है।।
उदाहरण पार्सर को HTML के साथ काम करने के लिए भी समायोजित किया जा सकता है, और HTML टैग को आपके प्लेटफ़ॉर्म के लिए रेंडर करने योग्य अपेक्षित तत्वों में बदला जा सकता है।
टैगिंग
जब कमेंट में उपयोगकर्ताओं को टैग किया जाता है, तो जानकारी mentions नामक सूची में संग्रहीत होती है। उस सूची में प्रत्येक ऑब्जेक्ट की संरचना निम्नलिखित है।
Run 
हैशटैग
जब हैशटैग का उपयोग किया जाता है और सफलतापूर्वक पार्स किया जाता है, तो जानकारी hashTags नामक सूची में संग्रहीत होती है। उस सूची में प्रत्येक ऑब्जेक्ट की संरचना निम्नलिखित है। यदि retain सेट है, तो क्वेरी के लिए हैशटैग को मैन्युअल रूप से कमेंट के hashTags ऐरे में भी जोड़ा जा सकता है।
Run 
GET /api/v1/comments 
यह API उपयोगकर्ता को दिखाने के लिए कमेंट्स प्राप्त करने के लिए उपयोग की जाती है। उदाहरण के लिए, यह स्वचालित रूप से अस्वीकृत या स्पैम कमेंट्स को फ़िल्टर कर देती है।
पेजिनेशन
पेजिनेशन दो तरीकों में से किसी एक से किया जा सकता है, जो परफ़ॉर्मेंस आवश्यकताओं और उपयोग के मामले पर निर्भर करता है:
- सबसे तेज़: Precalculated Pagination:
- जब आप हमारे प्रीबिल्ट विजेट्स और क्लाइंट्स का उपयोग करते हैं, तो FastComments इसी तरह काम करता है।
- "next" पर क्लिक करना केवल पेज काउंट बढ़ाता है।
- आप इसे key-value स्टोर से प्राप्त किए गए डेटा की तरह सोच सकते हैं।
- इस तरह, बस
0से शुरू होने वाला एकpageपैरामीटर औरdirectionके रूप में सॉर्ट दिशा परिभाषित करें। - पेज साइज़ कस्टमाइज़ेशन नियमों के माध्यम से अनुकूलित किया जा सकता है।
- सबसे लचीला: Flexible Pagination:
- इस तरह आप कस्टम
limitऔरskipपैरामीटर परिभाषित कर सकते हैं।pageपास न करें। - सॉर्ट
directionभी समर्थित है। limit,skipलागू होने के बाद लौटाने की कुल संख्या है।- उदाहरण:
page size = 100औरpage = 2होने परskip = 200, limit = 100सेट करें।
- उदाहरण:
- चाइल्ड कमेंट्स भी पेजिनेशन में गिने जाते हैं। आप
asTreeविकल्प का उपयोग करके इससे बच सकते हैं।- आप
limitChildrenऔरskipChildrenके माध्यम से चाइल्ड कमेंट्स को पेजिनेट कर सकते हैं। - आप
maxTreeDepthके माध्यम से लौटाए गए थ्रेड्स की गहराई सीमित कर सकते हैं।
- आप
- इस तरह आप कस्टम
थ्रेड्स
Precalculated Paginationका उपयोग करते समय, कमेंट्स page के अनुसार समूहित होते हैं और थ्रेड्स में कमेंट्स समग्र पेज को प्रभावित करते हैं।- इस तरह, थ्रेड्स को क्लाइंट पर
parentIdके आधार पर निर्धारित किया जा सकता है। - उदाहरण के लिए, एक टॉप-लेवल कमेंट और 29 रिप्लाई वाले पेज के लिए, और API में
page=0सेट करने पर - आपको केवल टॉप-लेवल कमेंट और 29 चाइल्ड मिलेंगे।
- इस तरह, थ्रेड्स को क्लाइंट पर
Flexible Paginationका उपयोग करते समय, आप एकparentIdपैरामीटर परिभाषित कर सकते हैं।- केवल टॉप-लेवल कमेंट्स प्राप्त करने के लिए इसे null सेट करें।
- फिर थ्रेड्स देखने के लिए, API को फिर से कॉल करें और
parentIdपास करें। - एक सामान्य समाधान यह है कि टॉप-लेवल कमेंट्स के लिए एक API कॉल करें और फिर प्रत्येक कमेंट के चाइल्ड के लिए समानांतर API कॉल करें।
- नया - फ़रवरी 2023 से!
&asTree=trueका उपयोग करके ट्री के रूप में प्राप्त करें।- आप इसे
Flexible Pagination as a Treeकी तरह सोच सकते हैं। - पेजिनेशन में केवल टॉप-लेवल कमेंट्स गिने जाते हैं।
- ट्री को रूट से शुरू करने के लिए
parentId=nullसेट करें (आपकोparentIdसेट करना अनिवार्य है)। - पेजिनेशन के लिए
skipऔरlimitसेट करें। asTreeकोtrueसेट करें।- क्रेडिट्स लागत
2xबढ़ जाती है, क्योंकि इस परिदृश्य में हमारे बैकएंड को बहुत अधिक काम करना पड़ता है। maxTreeDepth,limitChildren, औरskipChildrenको आवश्यकतानुसार सेट करें।
- आप इसे
ट्रीज़ की व्याख्या
asTree का उपयोग करते समय, पेजिनेशन को समझना कठिन हो सकता है। यहाँ एक उपयोगी ग्राफ़िक है:
उपयोगकर्ता के संदर्भ में कमेंट्स प्राप्त करना
/comments API को दो संदर्भों में, विभिन्न उपयोग के मामलों के लिए उपयोग किया जा सकता है:
- अपना स्वयं का क्लाइंट बनाने के लिए जानकारी के साथ सॉर्ट और टैग किए गए कमेंट्स लौटाने के लिए।
- इस मामले में, एक
contextUserIdक्वेरी पैरामीटर परिभाषित करें।
- इस मामले में, एक
- कस्टम इंटीग्रेशन के लिए अपने बैकएंड से कमेंट्स प्राप्त करने के लिए।
contextUserIdके बिना प्लेटफ़ॉर्म डिफ़ॉल्ट रूप से इसी का उपयोग करेगा।




कमेंट्स को ट्री के रूप में प्राप्त करें
कमेंट्स को ट्री के रूप में प्राप्त करना संभव है, जिसमें पेजिनेशन केवल टॉप-लेवल कमेंट्स को गिनता है।

केवल टॉप-लेवल कमेंट्स और तुरंत चाइल्ड प्राप्त करना चाहते हैं? यहाँ एक तरीका है:

हालाँकि, अपने UI में आपको यह जानने की आवश्यकता हो सकती है कि प्रत्येक कमेंट पर "show replies" बटन दिखाना है या नहीं। ट्री के माध्यम से कमेंट्स प्राप्त करते समय, जब लागू हो, तो कमेंट्स पर एक hasChildren प्रॉपर्टी टैग की जाती है।
ट्री के रूप में कमेंट्स प्राप्त करें, हैश टैग द्वारा खोज
API का उपयोग करके हैशटैग द्वारा खोज करना संभव है, आपके पूरे टेनेंट में (एक पेज या urlId तक सीमित नहीं)।
इस उदाहरण में, हम urlId को छोड़ देते हैं, और कई हैशटैग द्वारा खोज करते हैं। API केवल वही कमेंट्स लौटाएगा जिनमें सभी अनुरोधित हैशटैग मौजूद हैं।

सभी रिक्वेस्ट पैरामीटर्स

रिस्पॉन्स

उपयोगी टिप्स
URL ID
संभवतः आप Comment API का उपयोग urlId पैरामीटर के साथ करना चाहेंगे। आप पहले Pages API को कॉल कर सकते हैं, यह देखने के लिए कि आपके लिए उपलब्ध urlId मान कैसे दिखते हैं।
अनाम (Anonymous) क्रियाएँ
अनाम कमेंटिंग के लिए संभवतः आप कमेंट्स प्राप्त करते समय, और फ्लैगिंग तथा ब्लॉकिंग करते समय anonUserId पास करना चाहेंगे।
(!) यह कई ऐप स्टोर्स के लिए आवश्यक है क्योंकि उपयोगकर्ताओं को उपयोगकर्ता-निर्मित कंटेंट को फ्लैग करने में सक्षम होना चाहिए जिसे वे देख सकते हैं, भले ही वे लॉग इन न हों। ऐसा न करने पर आपका ऐप उस स्टोर से हटाया जा सकता है।
कमेंट्स लौटाए नहीं जा रहे हैं
जाँचें कि आपके कमेंट्स अप्रूव किए गए हैं, और स्पैम नहीं हैं।
GET /api/v1/comments/:id 
यह API id द्वारा एकल कमेंट प्राप्त करने की क्षमता प्रदान करती है।



POST /api/v1/comments 
यह API एंडपॉइंट कमेंट बनाने की क्षमता प्रदान करता है।
सामान्य उपयोग के मामले कस्टम UI, इंटीग्रेशन, या इंपोर्ट हैं।
नोट्स:
- यह API चाहें तो कमेंट विजेट को "live" अपडेट कर सकता है (इससे
creditsCost1से2हो जाता है)। - यह API ईमेल दिए जाने पर स्वतः हमारे सिस्टम में यूज़र ऑब्जेक्ट बना देगा।
- अलग-अलग ईमेल के साथ लेकिन एक ही यूज़रनेम वाले दो कमेंट सेव करने की कोशिश पर दूसरे कमेंट के लिए एरर आएगा।
- यदि आप
parentIdनिर्दिष्ट कर रहे हैं, और चाइल्ड कमेंट काnotificationSentForParentfalse है, तो हम पैरेंट कमेंट के लिए नोटिफिकेशन भेजेंगे। यह हर घंटे किया जाता है (हम भेजे जाने वाले ईमेल की संख्या कम करने के लिए नोटिफिकेशन को बैच में भेजते हैं)। - यदि आप यूज़र बनाते समय वेलकम ईमेल, या कमेंट वेरिफिकेशन ईमेल भेजना चाहते हैं, तो क्वेरी पैरामीटर में
sendEmailsकोtrueसेट करें। - इस API के माध्यम से बनाए गए कमेंट एडमिन ऐप के Analytics और Moderation पेजों में दिखाई देंगे।
- यदि सेटिंग चालू है, तो "bad words" कमेंटर के नाम और कमेंट टेक्स्ट में अभी भी मास्क रहते हैं।
- इस API के माध्यम से बनाए गए कमेंट को चाहें तो स्पैम के लिए जांचा जा सकता है।
- अधिकतम कमेंट लंबाई जैसी कॉन्फ़िगरेशन, यदि Customization Rule एडमिन पेज के माध्यम से कॉन्फ़िगर की गई है, तो यहाँ लागू होगी।
सबमिट करने के लिए न्यूनतम डेटा जो कमेंट विजेट में दिखाई देगा, वह इस प्रकार है:

एक अधिक वास्तविक रिक्वेस्ट इस तरह दिख सकती है:



PATCH /api/v1/comments/:id 
यह API एंडपॉइंट एक सिंगल कमेंट को अपडेट करने की क्षमता प्रदान करता है।
नोट्स:
- यह API चाहें तो कमेंट विजेट को "live" अपडेट कर सकता है (इससे बेस
creditsCost1से बढ़कर2हो जाता है)।- इससे पेजों के बीच कमेंट्स को "live" माइग्रेट किया जा सकता है (
urlIdबदलकर)। - माइग्रेशन पर अतिरिक्त
2क्रेडिट खर्च होते हैं क्योंकि पेज प्री-कैलकुलेट किए जाते हैं और यह CPU-इंटेंसिव है।
- इससे पेजों के बीच कमेंट्स को "live" माइग्रेट किया जा सकता है (
- क्रिएट API के विपरीत, यह API ईमेल दिए जाने पर भी हमारे सिस्टम में ऑटोमैटिकली यूज़र ऑब्जेक्ट नहीं बनाएगा।
- इस API के माध्यम से अपडेट किए गए कमेंट्स की चाहें तो स्पैम जांच भी की जा सकती है।
- अधिकतम कमेंट लंबाई जैसी कॉन्फ़िगरेशन, यदि Customization Rule एडमिन पेज के माध्यम से कॉन्फ़िगर की गई है, तो यहाँ भी लागू होगी।
- यूज़र्स को उनके कमेंट टेक्स्ट को अपडेट करने की अनुमति देने के लिए, आप बस रिक्वेस्ट बॉडी में
commentस्पेसिफाई कर सकते हैं। हम परिणामीcommentHTMLजनरेट करेंगे।- यदि आप
commentऔरcommentHTMLदोनों डिफाइन करते हैं तो हम HTML ऑटोमैटिकली जनरेट नहीं करेंगे। - यदि यूज़र अपने नए टेक्स्ट में मेंशन्स या हैशटैग जोड़ता है, तो उन्हें अभी भी
POSTAPI की तरह प्रोसेस किया जाएगा।
- यदि आप
- किसी कमेंट पर
commenterEmailअपडेट करते समय,userIdभी स्पेसिफाई करना सबसे अच्छा है। अन्यथा, आपको यह सुनिश्चित करना होगा कि इस ईमेल वाला यूज़र आपके टेनेंट से संबंधित है, नहीं तो रिक्वेस्ट विफल हो जाएगी। - यदि टारगेट कमेंट लॉक है (
isLocked: true), तो रिक्वेस्टcode: 'locked'के साथ रिजेक्ट कर दी जाती है। पहले कमेंट को अनलॉक करें, उसे अपडेट करें, फिर चाहें तो दोबारा लॉक करें।



DELETE /api/v1/comments/:id 
यह API एंडपॉइंट एक कमेंट को डिलीट करने की सुविधा प्रदान करता है।
नोट्स:
- यह API चाहें तो कमेंट विजेट को "live" अपडेट कर सकता है (इससे
creditsCost1से बढ़कर2हो जाता है)। - यह API सभी चाइल्ड कमेंट्स को डिलीट कर देगा।
- यदि टारगेट कमेंट लॉक है (
isLocked: true), तो रिक्वेस्टcode: 'locked'के साथ अस्वीकार कर दी जाती है। पहले कमेंट को अनलॉक करें, फिर डिलीट करें।



POST /api/v1/comments/:id/flag 
यह API एंडपॉइंट किसी विशिष्ट उपयोगकर्ता के लिए एक टिप्पणी को फ्लैग करने की क्षमता प्रदान करता है।
नोट्स:
- यह कॉल हमेशा एक उपयोगकर्ता के संदर्भ में किया जाना चाहिए। उपयोगकर्ता FastComments.com User, SSO User, या Tenant User हो सकता है।
- यदि एक flag-to-hide थ्रेशोल्ड सेट किया गया है, तो टिप्पणी को परिभाषित संख्या में फ्लैग किए जाने के बाद लाइव स्वचालित रूप से छिपा दिया जाएगा।
- स्वचालित रूप से अन-अप्रूव (छिपाए) जाने के बाद - टिप्पणी को केवल व्यवस्थापक या मॉडरेटर द्वारा ही फिर से अप्रूव किया जा सकता है। अन-फ्लैग करने से टिप्पणी फिर से अप्रूव नहीं होगी।

गुमनाम फ्लैगिंग के लिए, हमें एक anonUserId निर्दिष्ट करना होगा। यह गुमनाम सत्र का प्रतिनिधित्व करने वाली एक ID हो सकती है, या एक यादृच्छिक UUID।
यह हमें तब भी टिप्पणियों को फ्लैग और अन-फ्लैग करने की सुविधा देता है जब उपयोगकर्ता लॉग इन न हो। इस तरह, जब उसी anonUserId के साथ टिप्पणियाँ फ़ेच की जाती हैं, तो टिप्पणी को फ्लैग किया गया चिह्नित किया जा सकता है।



POST /api/v1/comments/:id/un-flag 
यह API एंडपॉइंट किसी विशिष्ट उपयोगकर्ता के लिए एक कमेंट को अन-फ्लैग (un-flag) करने की सुविधा प्रदान करता है।
नोट्स:
- यह कॉल हमेशा एक उपयोगकर्ता के संदर्भ में किया जाना चाहिए। उपयोगकर्ता एक FastComments.com User, SSO User, या Tenant User हो सकता है।
- जब कोई कमेंट स्वचालित रूप से अन-अप्रूव (छिपा हुआ) हो जाता है - तो उस कमेंट को केवल एडमिनिस्ट्रेटर या मॉडरेटर द्वारा ही दोबारा अप्रूव किया जा सकता है। अन-फ्लैग करने से कमेंट दोबारा अप्रूव नहीं होगा।

गुमनाम (anonymous) फ्लैगिंग के लिए, हमें एक anonUserId निर्दिष्ट करना होगा। यह गुमनाम सत्र (anonymous session) का प्रतिनिधित्व करने वाली एक ID हो सकती है, या एक रैंडम UUID।



POST /api/v1/comments/:id/block 
यह API एंडपॉइंट किसी दिए गए कमेंट को लिखने वाले यूज़र को ब्लॉक करने की सुविधा प्रदान करता है। यह FastComments.com Users, SSO Users, और Tenant Users द्वारा लिखे गए कमेंट्स से ब्लॉकिंग को सपोर्ट करता है।
यह एक commentIdsToCheck बॉडी पैरामीटर को सपोर्ट करता है, जिससे यह जांचा जा सके कि इस एक्शन के बाद क्लाइंट पर मौजूद कोई अन्य संभावित रूप से दिखाई देने वाले कमेंट्स को ब्लॉक/अनब्लॉक किया जाना चाहिए या नहीं।
नोट्स:
- यह कॉल हमेशा किसी यूज़र के संदर्भ (context) में की जानी चाहिए। यूज़र FastComments.com User, SSO User, या Tenant User हो सकता है।
- रिक्वेस्ट में
userIdवह यूज़र है जो ब्लॉक कर रहा है। उदाहरण के लिए:User A,User Bको ब्लॉक करना चाहता है। तोuserId=User AऔरUser Bद्वारा लिखे गए कमेंट की id पास करें। - पूरी तरह से अनाम (anonymous) कमेंट्स (कोई user id नहीं, कोई email नहीं) को ब्लॉक नहीं किया जा सकता और एक एरर रिटर्न किया जाएगा।

अनाम (anonymous) ब्लॉकिंग के लिए, हमें एक anonUserId निर्दिष्ट करना होगा। यह अनाम सेशन को दर्शाने वाली एक ID हो सकती है, या एक रैंडम UUID।
इससे हम उन कमेंट्स को ब्लॉक करने की सुविधा दे पाते हैं जिन्हें उसी anonUserId से फ़ेच करके तब भी ब्लॉक किया जा सके जब यूज़र लॉग इन न हो।



POST /api/v1/comments/:id/un-block 
यह API एंडपॉइंट किसी दिए गए कमेंट को लिखने वाले यूज़र को अन-ब्लॉक करने की सुविधा प्रदान करता है। यह FastComments.com Users, SSO Users, और Tenant Users द्वारा लिखे गए कमेंट्स से अन-ब्लॉकिंग को सपोर्ट करता है।
यह एक commentIdsToCheck बॉडी पैरामीटर को सपोर्ट करता है, ताकि यह जांचा जा सके कि इस क्रिया के बाद क्लाइंट पर कोई अन्य संभावित रूप से दिखाई देने वाले कमेंट्स को ब्लॉक/अन-ब्लॉक करना चाहिए या नहीं।
नोट्स:
- यह कॉल हमेशा किसी यूज़र के संदर्भ में की जानी चाहिए। यह यूज़र FastComments.com User, SSO User, या Tenant User हो सकता है।
- रिक्वेस्ट में
userIdवह यूज़र है जो अन-ब्लॉकिंग कर रहा है। उदाहरण के लिए:User A,User Bको अन-ब्लॉक करना चाहता है।userId=User Aपास करें और वह कमेंट आईडी दें जोUser Bने लिखा था। - पूरी तरह अनाम कमेंट्स (कोई यूज़र आईडी नहीं, कोई ईमेल नहीं) को ब्लॉक नहीं किया जा सकता और एक एरर रिटर्न किया जाएगा।




ईमेल टेम्पलेट संरचना 
एक EmailTemplate ऑब्जेक्ट किसी tenant के लिए कस्टम ईमेल टेम्पलेट की कॉन्फ़िगरेशन को दर्शाता है।
सिस्टम उपयोग करने के लिए ईमेल टेम्पलेट का चयन इस प्रकार करेगा:
- इसके type identifier द्वारा, जिसे हम
emailTemplateIdकहते हैं। ये constants होते हैं। domainद्वारा। हम पहले संबंधित ऑब्जेक्ट (जैसेComment) से जुड़े domain के लिए टेम्पलेट खोजने का प्रयास करेंगे, और यदि कोई मैच नहीं मिलता है तो हम ऐसा टेम्पलेट खोजने का प्रयास करेंगे जिसमें domain null या*हो।
EmailTemplate ऑब्जेक्ट की संरचना इस प्रकार है:

नोट्स
- आप मान्य
emailTemplateIdvalues/definitionsendpoint से प्राप्त कर सकते हैं। /definitionsendpoint में डिफ़ॉल्ट अनुवाद और test data भी शामिल हैं।- अमान्य संरचना या test data के साथ टेम्पलेट सहेजने में विफल हो जाएंगे।
GET /api/v1/email-templates/:id 
अलग-अलग EmailTemplates को उनके संबंधित id (emailTemplateId नहीं) से प्राप्त किया जा सकता है।



GET /api/v1/email-templates 
यह API पेजिनेशन का उपयोग करता है, जो page क्वेरी पैरामीटर द्वारा प्रदान की जाती है। EmailTemplates 100 के पेजों में लौटाए जाते हैं, createdAt और फिर id के अनुसार क्रमबद्ध।



PATCH /api/v1/email-templates/:id 
यह API एंडपॉइंट केवल id और अपडेट करने के लिए विशेषताओं (attributes) को निर्दिष्ट करके ईमेल टेम्पलेट अपडेट करने की क्षमता प्रदान करता है।
ध्यान दें कि टेम्पलेट बनाने के लिए सभी समान सत्यापन (validations) यहाँ भी लागू होते हैं, उदाहरण के लिए:
- टेम्पलेट रेंडर होना चाहिए। यह प्रत्येक अपडेट के साथ जाँचा जाता है।
- एक ही डोमेन के लिए डुप्लिकेट टेम्पलेट नहीं हो सकते (अन्यथा एक को चुपचाप अनदेखा कर दिया जाएगा)।



POST /api/v1/email-templates 
यह API एंडपॉइंट ईमेल टेम्पलेट बनाने की सुविधा प्रदान करता है।
नोट्स:
- आप एक ही डोमेन के साथ समान
emailTemplateIdवाले कई टेम्पलेट नहीं रख सकते। - लेकिन आप एक वाइल्डकार्ड टेम्पलेट (
domain=*) और उसीemailTemplateIdके लिए एक डोमेन-विशिष्ट टेम्पलेट रख सकते हैं। domainनिर्दिष्ट करना केवल तब प्रासंगिक है जब आपके पास अलग-अलग डोमेन हों, या आप परीक्षण के लिए विशिष्ट टेम्पलेट का उपयोग करना चाहते हों (domainकोlocalhostआदि पर सेट करना)।- यदि आप
domainनिर्दिष्ट करते हैं तो यह एकDomainConfigसे मेल खाना चाहिए। त्रुटि होने पर वैध डोमेन की एक सूची प्रदान की जाती है। - टेम्पलेट सिंटैक्स EJS है और इसे 500ms के टाइमआउट के साथ रेंडर किया जाता है। रेंडरिंग के लिए P99 <5ms है, इसलिए यदि आप 500ms तक पहुँचते हैं तो कुछ गड़बड़ है।
- सहेजने के लिए आपका टेम्पलेट आपके दिए गए
testDataके साथ रेंडर होना चाहिए। रेंडर त्रुटियों को एकत्र कर डैशबोर्ड में रिपोर्ट किया जाता है (जल्द ही API के माध्यम से उपलब्ध होगा)।
टेम्पलेट जोड़ने के लिए आवश्यक न्यूनतम डेटा इस प्रकार है:

आप प्रति-साइट टेम्पलेट रखना चाह सकते हैं, जिस स्थिति में आप domain परिभाषित करते हैं:



POST /api/v1/email-templates/render 
यह API एंडपॉइंट ईमेल टेम्पलेट्स का प्रीव्यू देखने की सुविधा प्रदान करता है।



DELETE /api/v1/email-templates/:id 
यह रूट id द्वारा एकल EmailTemplate को हटाने की सुविधा प्रदान करता है।



FeedPost संरचना 
एक FeedPost ऑब्जेक्ट FastComments फ़ीड में एक पोस्ट को दर्शाता है। फ़ीड एक पोस्ट स्ट्रीम होती है जिसमें प्रत्येक पोस्ट की अपनी कमेंट थ्रेड होती है, और इसे Feed विजेट द्वारा रेंडर किया जाता है। हर पोस्ट का एक लेखक, वैकल्पिक रिच कंटेंट, मीडिया और लिंक होते हैं, और इसे टैग किया जा सकता है ताकि फ़ीड को फ़िल्टर किया जा सके।
FeedPost ऑब्जेक्ट की संरचना इस प्रकार है:

नोट्स:
- इनमें से कुछ फ़ील्ड
READONLYचिह्नित हैं - ये API द्वारा लौटाए जाते हैं लेकिन सेट नहीं किए जा सकते। - किसी पोस्ट पर कमेंट सामान्य कमेंट होते हैं जिनका
urlIdpost:होता है जिसके बाद पोस्ट का_idआता है। किसी पोस्ट पर कमेंट पढ़ने या बनाने के लिए उस मान का उपयोग Comment API के साथ करें।
GET /api/v1/feed-posts 
फ़ीड में पोस्ट प्राप्त करता है, नवीनतम पहले। पेजिनेशन कर्सर आधारित है: अगला पेज प्राप्त करने के लिए आपके द्वारा प्राप्त अंतिम पोस्ट की _id को afterId के रूप में पास करें।
प्रत्येक दस लौटाई गई पोस्ट पर एक क्रेडिट लागत होती है, न्यूनतम एक क्रेडिट।



POST /api/v1/feed-posts 
यह रूट एक सिंगल FeedPost बनाता है। हर पोस्ट का एक लेखक होता है, इसलिए fromUserId आवश्यक है और यह खाते पर मौजूद किसी FastComments या SSO उपयोगकर्ता की id होनी चाहिए।



PATCH /api/v1/feed-posts/:id 
यह रूट एकल FeedPost को अपडेट करता है। केवल वही फ़ील्ड भेजें जिन्हें आप बदलना चाहते हैं।



HashTag संरचना 
एक HashTag ऑब्जेक्ट एक ऐसे टैग को दर्शाता है जिसे उपयोगकर्ता द्वारा छोड़ा जा सकता है। HashTags का उपयोग किसी बाहरी सामग्री से लिंक करने या संबंधित टिप्पणियों को एक साथ जोड़ने के लिए किया जा सकता है।
HashTag ऑब्जेक्ट की संरचना इस प्रकार है:

नोट्स:
- कुछ API endpoints में आप देखेंगे कि हैशटैग का उपयोग URL में किया जाता है। URI-Encoded मानों को याद रखें। उदाहरण के लिए,
#को इसके बजाय%23के रूप में दर्शाया जाना चाहिए। - इनमें से कुछ फ़ील्ड
READONLYचिह्नित हैं - इन्हें API द्वारा लौटाया जाता है लेकिन इन्हें सेट नहीं किया जा सकता।
GET /api/v1/hash-tags 
यह API पेजिनेशन का उपयोग करती है, जो page क्वेरी पैरामीटर द्वारा प्रदान की जाती है। HashTags 100 के पेजों में लौटाए जाते हैं, tag के अनुसार क्रमबद्ध।



PATCH /api/v1/hash-tags/:tag 
यह रूट एकल HashTag को अपडेट करने की क्षमता प्रदान करता है।



POST /api/v1/hash-tags 
यह रूट एक सिंगल HashTag जोड़ने की क्षमता प्रदान करता है।



POST /api/v1/hash-tags/bulk 
यह रूट एक साथ 100 HashTag ऑब्जेक्ट तक जोड़ने की क्षमता प्रदान करता है।



DELETE /api/v1/hash-tags/:tag 
यह रूट दिए गए टैग द्वारा एक HashTag उपयोगकर्ता को हटाने की सुविधा प्रदान करता है।
ध्यान दें कि जब तक स्वचालित HashTag निर्माण अक्षम नहीं किया गया है, टिप्पणी करते समय हैशटैग प्रदान करके उपयोगकर्ता द्वारा हैशटैग को फिर से बनाया जा सकता है।



GET /api/v1/me 
अनुरोध करने वाले क्रेडेंशियल का वर्णन करता है: वह टेनेंट जिसका यह है और, OAuth एक्सेस टोकन के मामले में, वह उपयोगकर्ता जिसने एप्लिकेशन को अधिकृत किया। इंटीग्रेशन इसका उपयोग कनेक्शन का परीक्षण करने और उसे लेबल करने के लिए करते हैं।
API कुंजी के साथ प्रतिक्रिया केवल टेनेंट की पहचान करती है। OAuth बेयरर टोकन के साथ यह अधिकृत करने वाले उपयोगकर्ता और प्रदान किए गए स्कोप भी ले जाता है।


मॉडरेटर संरचना 
एक Moderator ऑब्जेक्ट एक मॉडरेटर के लिए कॉन्फ़िगरेशन का प्रतिनिधित्व करता है।
मॉडरेटर के तीन प्रकार होते हैं:
- वे एडमिनिस्ट्रेटर उपयोगकर्ता जिनके पास
isCommentModeratorAdminफ्लैग होता है। isCommentModeratorAdminफ्लैग वाले SSO उपयोगकर्ता।- सामान्य टिप्पणीकार, या FastComments.com उपयोगकर्ता, जिन्हें मॉडरेटर के रूप में आमंत्रित किया गया हो।
Moderator संरचना का उपयोग उपयोग केस 3 की मॉडरेशन स्थिति (Moderation State) को दर्शाने के लिए किया जाता है।
यदि आप API के माध्यम से किसी उपयोगकर्ता को मॉडरेटर बनने के लिए आमंत्रित करना चाहते हैं, तो एक Moderator बनाकर और उन्हें inviting करके Moderator API का उपयोग करें।
यदि उपयोगकर्ता के पास FastComments.com खाता नहीं है, तो आमंत्रण ईमेल उन्हें सेटअप करने में मदद करेगा। यदि उनके पास पहले से खाता है, तो उन्हें आपके टेनेंट (tenant) तक मॉडरेशन एक्सेस दिया जाएगा और Moderator ऑब्जेक्ट का userId उनके उपयोगकर्ता की ओर इशारा करने के लिए अपडेट कर दिया जाएगा। आपको उनके उपयोगकर्ता तक API एक्सेस नहीं मिलेगा, क्योंकि इस स्थिति में वह उपयोगकर्ता स्वयं का होता है और FastComments.com द्वारा प्रबंधित किया जाता है।
यदि आप उपयोगकर्ता के खाते का पूर्ण प्रबंधन चाहते हैं, तो हम या तो SSO का उपयोग करने, या उन्हें Tenant User के रूप में जोड़ने और फिर उनके आंकड़े ट्रैक करने के लिए एक Moderator ऑब्जेक्ट जोड़ने की सलाह देते हैं।
Moderator संरचना का उपयोग उपयोग केस 1 और 2 के लिए आंकड़े ट्रैकिंग तंत्र के रूप में किया जा सकता है। उपयोगकर्ता बनाने के बाद, उनका userId निर्दिष्ट करते हुए एक Moderator ऑब्जेक्ट जोड़ें और उनके आंकड़े Comment Moderators Page पर ट्रैक किए जाएंगे।
Moderator ऑब्जेक्ट की संरचना इस प्रकार है:

GET /api/v1/moderators/:id 
यह रूट id द्वारा एक मॉडरेटर को लौटाता है।



GET /api/v1/moderators 
यह API पेजिनेशन का उपयोग करती है, जो skip क्वेरी पैरामीटर द्वारा प्रदान की जाती है। मॉडरेटर 100 के पृष्ठों में लौटाए जाते हैं, createdAt और id के अनुसार क्रमबद्ध।
लागत लौटाए गए मॉडरेटर की संख्या पर आधारित है, प्रत्येक 10 मॉडरेटर पर 1 क्रेडिट की दर से।



PATCH /api/v1/moderators/:id 
यह API एंडपॉइंट id द्वारा एक Moderator को अपडेट करने की क्षमता प्रदान करता है।
एक Moderator को अपडेट करने की निम्नलिखित सीमाएँ हैं:
Moderatorको अपडेट करते समय निम्नलिखित मान प्रदान नहीं किए जा सकते:acceptedInvitemarkReviewedCountdeletedCountmarkedSpamCountapprovedCounteditedCountbannedCountverificationIdcreatedAt
- जब एक
userIdनिर्दिष्ट किया जाता है, तो वह उपयोगकर्ता मौजूद होना चाहिए। - जब एक
userIdनिर्दिष्ट किया जाता है, तो वह क्वेरी पैरामीटर में निर्दिष्ट उसीtenantIdसे संबंधित होना चाहिए। - एक ही टेनेंट में दो मॉडरेटर एक ही
emailके साथ नहीं जोड़े जा सकते। - आप एक
Moderatorसे जुड़ेtenantIdको नहीं बदल सकते।



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पहले से मौजूद होना चाहिए।fromName100 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 के माध्यम से नहीं बनाए जा सकते। ये एक वर्ष बाद समाप्त (expire) हो जाते हैं।
आप उपयोगकर्ता का 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 के माध्यम से नहीं बनाया जा सकता। ये एक वर्ष बाद समाप्त (expire) भी हो जाते हैं।
नोटिफिकेशन को डिलीट नहीं किया जा सकता। हालाँकि, इन्हें अपडेट करके viewed को false सेट किया जा सकता है, और आप viewed के आधार पर क्वेरी कर सकते हैं।
एक उपयोगकर्ता किसी विशेष कमेंट के लिए नोटिफिकेशन से ऑप्ट आउट भी कर सकता है, नोटिफिकेशन में optedOut को true सेट करके। आप इसे false सेट करके दोबारा ऑप्ट इन कर सकते हैं।
विभिन्न नोटिफिकेशन प्रकार होते हैं - relatedObjectType और type देखें।
नोटिफिकेशन बनाने के तरीके काफी लचीले हैं और इन्हें कई परिदृश्यों द्वारा ट्रिगर किया जा सकता है (NotificationType देखें)।
आज की तारीख तक, एक Notification का अस्तित्व वास्तव में यह नहीं दर्शाता कि कोई ईमेल भेजा गया है या भेजा जाना चाहिए। बल्कि, नोटिफिकेशन का उपयोग नोटिफिकेशन फ़ीड और संबंधित इंटीग्रेशन के लिए किया जाता है।
Notification ऑब्जेक्ट की संरचना इस प्रकार है:

GET /api/v1/notifications 
यह रूट createdAt के अनुसार क्रमबद्ध, नवीनतम पहले, 30 Notification ऑब्जेक्ट तक लौटाता है।
आप 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 एंडपॉइंट id द्वारा एक Notification को अपडेट करने की क्षमता प्रदान करता है।
एक Notification को अपडेट करने की निम्नलिखित सीमाएँ हैं:
- आप केवल निम्नलिखित फ़ील्ड अपडेट कर सकते हैं:
viewedoptedOut



पेज रिएक्ट्स सार्वजनिक API 
Page Reacts आपके उपयोगकर्ताओं को किसी पेज को लाइक करने, या आपके अपने रिएक्शन इमेज के सेट के साथ उस पर प्रतिक्रिया देने की सुविधा देते हैं। Page Reacts widget और Floating Likes widget इन endpoints पर बने हैं, और आप इन्हें स्वयं कॉल करके अपना लाइक बटन बना सकते हैं।
इस गाइड के बाकी हिस्सों के विपरीत, Page Reacts endpoints सार्वजनिक (public) हैं। इन्हें आपके उपयोगकर्ताओं के ब्राउज़र से कॉल किया जाता है, इनमें कोई API key नहीं लगती, और ये कोई API credits खर्च नहीं करते। हर react अनुरोध करने वाले उपयोगकर्ता से जुड़ा होता है, इसलिए कोई उपयोगकर्ता केवल अपना ही react जोड़ या हटा सकता है।
Endpoints के दो सेट हैं:
/page-reacts/v1/likes/:tenantId- प्रति उपयोगकर्ता प्रति पेज एक "like"। इन्हें लाइक बटन के लिए उपयोग करें।/page-reacts/v2/:tenantId- प्रति पेज एकाधिक reactions, प्रत्येक आपके चुने हुए एक छोटेidसे पहचाना जाता है (उदाहरण के लिएheartयाlaugh)।
दोनों हमारे SDKs में PublicApi के हिस्से के रूप में भी उपलब्ध हैं, उदाहरण के लिए JavaScript SDK में getV1PageLikes, createV1PageReact, और deleteV1PageReact।
किसने प्रतिक्रिया दी यह दिखाना
जिन उपयोगकर्ताओं ने लाइक या प्रतिक्रिया दी है उन्हें उनके usernames और avatars के साथ, सबसे हालिया पहले, प्राप्त करने के लिए GET endpoints को includeUserInfo=public पास करें। जिन उपयोगकर्ताओं ने अपनी profile activity private कर रखी है वे छोड़ दिए जाते हैं, जैसे anonymous users भी। अधिकतम 100 reacts लौटाए जाते हैं।
SSO users आपका SSO payload isProfileActivityPrivate को false सेट न करे तो private profile activity के साथ बनाए जाते हैं, इसलिए जिन उपयोगकर्ताओं को आप इन सूचियों में दिखाना चाहते हैं उनके लिए इसे सेट करें।
SSO आवश्यक करने वाले पेजों पर, केवल वे SSO users जो पेज देख सकते हैं, वे ही यह सूचीबद्ध कर सकते हैं कि किसने प्रतिक्रिया दी। अन्य लोगों को sso-required या page-forbidden कोड के साथ 403 मिलता है।
अपने सर्वर से, GET /api/v1/pages/likes और GET /api/v1/pages/reacts API key के साथ वही सूचियाँ लौटाते हैं, और private profiles वाले उपयोगकर्ताओं को शामिल करने के लिए includeUserInfo=include-private भी स्वीकार करते हैं।
उपयोगकर्ता की पहचान करना
Reacts अनुरोध करने वाले उपयोगकर्ता से जुड़े होते हैं:
- SSO users:
ssoquery parameter पास करें, जो उसी SSO object के URI encoded JSON पर सेट हो जो आप comment widget को देते हैं। SSO देखें। - Anonymous users: जब
ssoparameter न हो और कोई FastComments लॉगिन न हो, तो सर्वर ब्राउज़र को FastComments session cookie में संग्रहीत एक anonymous id असाइन करता है। अनुरोधcredentials: 'include'के साथ भेजें ताकि अनुरोधों के बीच cookie बना रहे। जो ब्राउज़र third-party cookies को ब्लॉक करते हैं वे anonymous id को बनाए नहीं रखेंगे, इसलिए जब प्रत्येक उपयोगकर्ता को विश्वसनीय रूप से पहचाना जाना आवश्यक हो तो SSO का उपयोग करें।
urlId
urlId पेज की पहचान करता है, ठीक उसी तरह जैसे यह comments के लिए करता है। वही urlId उपयोग करें जो आप comment widget को देते हैं ताकि likes और comments एक ही पेज पर गिने जाएँ। इसे URI encode करना न भूलें।

GET /page-reacts/v1/likes/:tenantId 
किसी पेज पर लाइक की संख्या लौटाता है, और यह भी कि क्या वर्तमान उपयोगकर्ता ने उसे लाइक किया है। जो पेज अभी तक मौजूद नहीं हैं, वे likeCount के रूप में 0 लौटाते हैं।
पेज को लाइक करने वाले उपयोगकर्ताओं को भी पाने के लिए, नवीनतम पहले, includeUserInfo=public पास करें। निजी प्रोफ़ाइल गतिविधि वाले उपयोगकर्ताओं और गुमनाम उपयोगकर्ताओं को छोड़ दिया जाता है, और अधिकतम 100 लाइक देखे जाते हैं। यहाँ केवल public स्वीकार किया जाता है; include-private एक 422 लौटाता है और यह API कुंजी के साथ GET /api/v1/pages/likes से उपलब्ध है। जिन पेजों पर SSO आवश्यक है, वहाँ includeUserInfo उन उपयोगकर्ताओं के लिए 403 लौटाता है जो पेज नहीं देख सकते।



POST /page-reacts/v1/likes/:tenantId 
वर्तमान उपयोगकर्ता के रूप में पेज को लाइक करता है। प्रत्येक उपयोगकर्ता किसी पेज को एक बार लाइक कर सकता है: दोबारा लाइक करने पर already-liked कोड के साथ सफलता मिलती है और गिनती नहीं बदलती।
यदि पेज अभी तक मौजूद नहीं है तो उसे बनाया जाता है। पेज का टाइटल सेट या अपडेट करने के लिए title पास करें।



DELETE /page-reacts/v1/likes/:tenantId 
वर्तमान उपयोगकर्ता का लाइक पेज से हटाता है। यदि उपयोगकर्ता ने पेज को लाइक नहीं किया है, तो अनुरोध not-liked कोड के साथ सफल होता है और गिनती नहीं बदलती।



GET /page-reacts/v2/:tenantId 
किसी पेज पर प्रत्येक रिएक्शन की संख्या, और वर्तमान उपयोगकर्ता द्वारा जोड़े गए रिएक्शन लौटाता है।
रिएक्ट करने वाले उपयोगकर्ताओं को भी पाने के लिए includeUserInfo=public पास करें, जिसमें प्रत्येक रिएक्ट के लिए एक प्रविष्टि उसके रिएक्शन id के साथ होती है, सबसे हालिया पहले। निजी प्रोफ़ाइल गतिविधि वाले उपयोगकर्ता और गुमनाम उपयोगकर्ता छोड़ दिए जाते हैं, और अधिकतम 100 रिएक्ट देखे जाते हैं। यहाँ केवल public स्वीकार किया जाता है; include-private एक 422 लौटाता है और API कुंजी के साथ GET /api/v1/pages/reacts से उपलब्ध है। उन पेजों पर जिन्हें SSO की आवश्यकता होती है, includeUserInfo उन उपयोगकर्ताओं के लिए 403 लौटाता है जो पेज नहीं देख सकते।



GET /page-reacts/v2/:tenantId/list 
किसी पेज पर रिएक्शन जोड़ने वाले उपयोगकर्ताओं के नाम, वर्णानुक्रम में क्रमबद्ध करके लौटाता है। 100 तक रिएक्ट देखे जाते हैं, और गुमनाम उपयोगकर्ता तथा निजी प्रोफ़ाइल गतिविधि वाले उपयोगकर्ता शामिल नहीं होते। SSO आवश्यक वाले पेजों पर, जो उपयोगकर्ता पेज नहीं देख सकते उन्हें sso-required या page-forbidden कोड के साथ 403 मिलता है।
अवतार और उपयोगकर्ता ids भी प्राप्त करने के लिए, includeUserInfo=public के साथ GET /page-reacts/v2/:tenantId का उपयोग करें।



POST /page-reacts/v2/:tenantId 
वर्तमान उपयोगकर्ता के रूप में किसी पेज पर एक रिएक्शन जोड़ता है। एक उपयोगकर्ता प्रत्येक रिएक्शन id को केवल एक बार जोड़ सकता है: इसे दोबारा जोड़ने पर already-reacted कोड के साथ सफलता मिलती है और काउंट नहीं बदलता। एक उपयोगकर्ता एक ही पेज पर कई अलग-अलग रिएक्शन जोड़ सकता है।
रिएक्शन ids आपके द्वारा चुने जाते हैं और 36 वर्णों तक के हो सकते हैं। यदि पेज अभी तक मौजूद नहीं है तो उसे बना दिया जाता है। पेज का शीर्षक सेट या अपडेट करने के लिए title पास करें।



DELETE /page-reacts/v2/:tenantId 
वर्तमान उपयोगकर्ता की एक प्रतिक्रिया को पेज से हटाता है। यदि उपयोगकर्ता ने वह प्रतिक्रिया नहीं जोड़ी है, तो अनुरोध no-react कोड के साथ सफल होता है और काउंट को नहीं बदलता।



पेज संरचना 
एक Page ऑब्जेक्ट उस पेज को दर्शाता है जिससे कई कमेंट्स संबंधित हो सकते हैं। यह संबंध
urlId द्वारा परिभाषित होता है।
एक Page पेज का शीर्षक, कमेंट काउंट और urlId जैसी जानकारी संग्रहीत करता है।
Page ऑब्जेक्ट की संरचना इस प्रकार है:

GET /api/v1/pages 
वर्तमान में आप केवल अपने खाते से जुड़े सभी पेज (या /by-url-id के माध्यम से एकल पेज) प्राप्त कर सकते हैं। यदि आप अधिक सूक्ष्म खोज चाहते हैं, तो हमसे संपर्क करें।



उपयोगी सुझाव
Comment API को एक urlId की आवश्यकता होती है। आप पहले Pages API को कॉल कर सकते हैं, यह देखने के लिए कि आपके लिए उपलब्ध urlId मान कैसे दिखते हैं।
GET /api/v1/pages/by-url-id 
अलग-अलग पेजों को उनके संबंधित urlId के आधार पर प्राप्त किया जा सकता है। यह पेज शीर्षक या कमेंट की संख्या देखने के लिए उपयोगी हो सकता है।



उपयोगी सुझाव
urlId जैसे मानों को URI Encode करना न भूलें।
GET /api/v1/pages/likes 
किसी पेज पर लाइक की संख्या, और वैकल्पिक रूप से उन उपयोगकर्ताओं की सूची लौटाता है जिन्होंने उसे लाइक किया, सबसे हालिया पहले। यह GET /page-reacts/v1/likes/:tenantId का सर्वर-साइड संस्करण है।
includeUserInfo नियंत्रित करता है कि कौन से उपयोगकर्ता लौटाए जाते हैं:
publicउन उपयोगकर्ताओं को छोड़ देता है जिन्होंने अपनी प्रोफ़ाइल गतिविधि निजी कर रखी है।include-privateउन्हें शामिल करता है। इसका उपयोग केवल तब करें जब सूची सार्वजनिक रूप से न दिखाई जा रही हो।
गुमनाम (Anonymous) उपयोगकर्ता कभी शामिल नहीं किए जाते, और अधिकतम 100 लाइक ही देखे जाते हैं। जो पेज मौजूद नहीं हैं वे likeCount के रूप में 0 और खाली users सूची लौटाते हैं।



उपयोगी सुझाव
urlId जैसे मानों को URI Encode करना न भूलें।
GET /api/v1/pages/reacts 
किसी पेज पर प्रत्येक रिएक्शन की संख्या लौटाता है, और वैकल्पिक रूप से उन उपयोगकर्ताओं को भी जिन्होंने रिएक्ट किया, प्रत्येक रिएक्ट के लिए एक एंट्री के रूप में उसके रिएक्शन आईडी के साथ, सबसे हालिया पहले। यह GET /page-reacts/v2/:tenantId का सर्वर-साइड संस्करण है।
includeUserInfo नियंत्रित करता है कि कौन से उपयोगकर्ता लौटाए जाते हैं:
publicउन उपयोगकर्ताओं को छोड़ देता है जिन्होंने अपनी प्रोफ़ाइल गतिविधि निजी रखी है।include-privateउन्हें शामिल करता है। इसका उपयोग केवल तब करें जब सूची सार्वजनिक रूप से न दिखाई जा रही हो।
गुमनाम (Anonymous) उपयोगकर्ता कभी शामिल नहीं किए जाते, और अधिकतम 100 रिएक्ट देखे जाते हैं। जो पेज मौजूद नहीं हैं वे कोई counts नहीं और खाली users सूची लौटाते हैं।



उपयोगी सुझाव
urlId जैसे मानों को URI Encode करना न भूलें।
PATCH /api/v1/pages/:id 
यह रूट एक सिंगल Page को अपडेट करने की सुविधा प्रदान करता है। संबंधित कमेंट्स भी अपडेट हो जाएंगे।



नोट
Page ऑब्जेक्ट के कुछ पैरामीटर स्वचालित रूप से अपडेट हो जाते हैं। ये counts और title एट्रिब्यूट्स हैं। Counts को API के माध्यम से अपडेट नहीं किया जा सकता क्योंकि वे गणना किए गए मान हैं। पेज का title API के माध्यम से सेट किया जा सकता है, लेकिन यदि उसी urlId वाले पेज पर कमेंट विजेट का उपयोग किया जाता है और पेज का टाइटल अलग है, तो यह ओवरराइट हो जाएगा।
POST /api/v1/pages 
यह API एंडपॉइंट पेज बनाने की क्षमता प्रदान करता है।
एक सामान्य उपयोग का मामला एक्सेस कंट्रोल है।
नोट्स:
- यदि आपने किसी कमेंट थ्रेड पर कमेंट किया है, या
Commentबनाने के लिए API को कॉल किया है, तो आप पहले से ही एकPageऑब्जेक्ट बना चुके हैं! आप इसे/by-url-idPageरूट के माध्यम से फ़ेच करने का प्रयास कर सकते हैं, जिसमें कमेंट विजेट को दिया गया वहीurlIdपास करें। Pageसंरचना में कुछ गणना किए गए मान होते हैं। वर्तमान में, येcommentCountऔरrootCommentCountहैं। इन्हें स्वचालित रूप से पॉपुलेट किया जाता है और API द्वारा सेट नहीं किया जा सकता। ऐसा करने का प्रयास करने पर API एक त्रुटि लौटाएगा।



DELETE /api/v1/pages/:id 
यह रूट id द्वारा एकल पेज को हटाने की सुविधा प्रदान करता है।
ध्यान दें कि उसी urlId वाले पेज के लिए कमेंट विजेट के साथ इंटरैक्ट करने पर Page बिना किसी बाधा के सहजता से फिर से बन जाएगा।



POST /api/v1/pages/migrations 
यह रूट कमेंट्स और पेजों को एक urlId या डोमेन से दूसरे में स्थानांतरित करता है, ठीक वैसे ही जैसे डैशबोर्ड में Domain Migration tool काम करता है। प्रति रिक्वेस्ट अधिकतम 100 माइग्रेशन भेजे जा सकते हैं। ये दिए गए क्रम में चलते हैं, इसलिए a से b के बाद b से c करना काम करता है।
प्रत्येक माइग्रेशन का एक type होता है:
urlIdउस पेज को स्थानांतरित करता है जिसकाurlIdबिल्कुलfromके बराबर हो।post-1,post-10से मेल नहीं खाता।domainहरurlIdऔरurlके अंदरfromको खोजकर बदलता है, और प्रत्येक कमेंट काdomainअपडेट करता है। दोनों मान एक डोमेन होने चाहिए, जैसेold.example.com।
कमेंट्स, पेज, पेज रिएक्ट्स, वोट्स, नोटिफिकेशन और सब्सक्रिप्शन — सब स्थानांतरित हो जाते हैं। यदि to पर पहले से कोई पेज मौजूद है, तो दोनों पेज मर्ज हो जाते हैं।
माइग्रेशन एक बैच जॉब के रूप में चलता है। रिस्पॉन्स में एक batchJobId होता है। इसकी प्रगति देखने के लिए GET /api/v1/batch-jobs/:id को पोल करें। जॉब पूरा होने पर प्रत्येक माइग्रेशन के लिए एक रिज़ल्ट और एक undoId होता है, जिसे आप 90 दिनों के भीतर POST /api/v1/pages/migrations/:undoId/undo को पास कर सकते हैं।
रिक्वेस्ट कतार में जोड़े जाने से पहले वैलिडेट की जाती है। यदि कोई भी माइग्रेशन अमान्य है, तो पूरी रिक्वेस्ट 422 के साथ विफल हो जाती है और कुछ भी नहीं चलता।
माइग्रेशन कतार में जोड़ने पर कुछ खर्च नहीं होता। जॉब पूरा होने पर प्रति 1000 माइग्रेट किए गए कमेंट्स पर 1 क्रेडिट खर्च होता है, न्यूनतम 1।



नोट्स
- एक ही टेनेंट के जॉब्स एक समय में एक ही चलते हैं, सबसे पुराना पहले। दूसरा माइग्रेशन पहले के पूरा होने की प्रतीक्षा करता है।
- नए
urlIdके साथPATCH /api/v1/pages/:idकेवल पेज को बदलता है, उसके कमेंट्स को नहीं। किसी पेज के कमेंट्स को स्थानांतरित करने के लिए इस रूट का उपयोग करें।
POST /api/v1/pages/migrations/:undoId/undo 
यह रूट एक POST /api/v1/pages/migrations जॉब से हुए हर माइग्रेशन को वापस ले लेता है। undoId पूरे हुए माइग्रेशन जॉब से GET /api/v1/batch-jobs/:id के ज़रिए प्राप्त करें। एक undoId का उपयोग 90 दिनों तक, और केवल एक बार किया जा सकता है।
अनडू एक बैच जॉब के रूप में चलता है, उसी तरह जैसे माइग्रेशन चलता है, और रिस्पॉन्स में उसका batchJobId होता है। जॉब पूरा होने पर, उसका pageMigrationUndoResult रिपोर्ट करता है:
restored: रिकॉर्ड्स जो माइग्रेशन से पहले की उनकी वैल्यू में वापस रख दिए गए।skipped: रिकॉर्ड्स जिन्हें छोड़ दिया गया क्योंकि वे माइग्रेशन के बाद बदल गए थे, या अब मौजूद नहीं हैं। बाद में किया गया कोई एडिट कभी ओवरराइट नहीं होता।notRestorable: रिकॉर्ड्स जिन्हें माइग्रेशन ने दो पेजों को मर्ज करते समय, या डुप्लिकेट पेज रिएक्ट्स हटाते समय डिलीट कर दिया था। इन्हें वापस लाया नहीं जा सकता।
माइग्रेशन सबसे नए वाले से पहले रिवर्स किए जाते हैं, इसलिए a से b और फिर b से c जैसी श्रृंखला वापस a तक अनवाउंड हो जाती है। बीच में विफल हुआ माइग्रेशन जॉब भी अनडू किया जा सकता है, जो विफल होने से पहले किए गए उसके बदलावों को रिवर्स कर देता है।
अनडू को क्यू में लगाने पर कुछ खर्च नहीं होता। जॉब पूरा होने पर प्रत्येक 1000 रिस्टोर किए गए रिकॉर्ड्स पर 1 क्रेडिट लगता है, न्यूनतम 1।



पोल संरचना 
एक Poll किसी कमेंट से जुड़ा होता है, न कि अपने आप में एक अलग ऑब्जेक्ट होता है। यह कमेंट के साथ बनाया जाता है
(POST /api/v1/comments देखें), या बाद में PUT /api/v1/polls/:commentId के ज़रिए किसी मौजूदा कमेंट में जोड़ा जाता है।
वोट की गिनती पोल पर ही रखी जाती है, इसलिए पोल पढ़ने पर आपको कुछ जोड़े बिना ही परिणाम मिल जाते हैं।
इन गिनतियों के पीछे के अलग-अलग वोट PollVote ऑब्जेक्ट होते हैं।
प्रत्येक विकल्प का एक id होता है जो पोल बनाते समय जनरेट होता है। वही id आप वोट डालने के लिए,
किसी विकल्प का लेबल बदलने के लिए, और पोल को PUT करते समय विकल्प जोड़ने या हटाने पर किसी विकल्प
(और उसके वोटों) को बनाए रखने के लिए उपयोग करते हैं। किसी विकल्प को संदर्भित करने का यही एकमात्र सुरक्षित तरीका है -
कभी भी सूची में उसकी स्थिति का उपयोग न करें।

सीमाएँ
- एक प्रश्न आवश्यक है, और अधिकतम 200 वर्णों का हो सकता है।
- एक पोल में 2 से 10 विकल्प हो सकते हैं।
- एक विकल्प का लेबल आवश्यक है, अधिकतम 100 वर्णों का हो सकता है, और पोल के भीतर अद्वितीय होना चाहिए (केस को अनदेखा करते हुए)।
closesAtपोल बनाते समय भविष्य की तारीख होनी चाहिए। किसी पोल को तुरंत बंद करने के लिए, उसे भूतकाल की तारीख के साथPATCHकरें।
साइट सेटिंग्स
पोल आपकी साइट कॉन्फ़िगरेशन का पालन करते हैं, जिसे आप Customize Widget के अंतर्गत बदल सकते हैं:
- पोल बनाने से पहले पोल सक्षम होने चाहिए, अन्यथा API
polls-disabledके साथ प्रतिक्रिया देता है। - वोटिंग केवल लॉग-इन उपयोगकर्ताओं तक सीमित की जा सकती है, जिस स्थिति में केवल
anonUserIdके साथ भेजा गया वोटpoll-login-requiredके साथ अस्वीकार कर दिया जाता है।
GET /api/v1/polls/:commentId 
किसी कमेंट से जुड़े पोल को उसकी वर्तमान वोट संख्या के साथ पढ़ता है।
पोल कमेंट APIs द्वारा कमेंट पर ही भी लौटाए जाते हैं, इसलिए इसका उपयोग तब करें जब आप केवल परिणाम चाहते हों और पूरा कमेंट नहीं।



बिना पोल वाला कमेंट, डिलीट किया गया कमेंट, और कोई मौजूद न होने वाला कमेंट id — तीनों एक ही तरीके से
poll-not-found के साथ प्रतिक्रिया देते हैं।
PUT /api/v1/polls/:commentId 
किसी मौजूदा कमेंट पर एक पोल जोड़ता है, या उस पोल की पूरी स्थिति सेट करता है जो पहले से मौजूद है।
बॉडी पूरा पोल होता है, और आपके द्वारा भेजे गए विकल्प उसी क्रम में पोल के विकल्प बन जाते हैं। प्रत्येक विकल्प
उसके id से मैच किया जाता है:
- किसी मौजूदा विकल्प के
idके साथ भेजा गया विकल्प उस विकल्प और उसके वोटों को बनाए रखता है। उसका लेबल और स्थान आपके द्वारा भेजे गए मानों में अपडेट हो जाता है। - बिना
idके भेजा गया विकल्प जोड़ा जाता है, बिना किसी वोट के। - कोई मौजूदा विकल्प जिसे आप छोड़ देते हैं, वह हटा दिया जाता है, उस पर डाले गए वोटों सहित।
totalVotesउतनी ही मात्रा से घट जाता है।
इसलिए एक विकल्प जोड़ने के लिए, मौजूदा विकल्पों को उनके ids के साथ भेजें और नए विकल्प को बिना id के भेजें। एक को
हटाने के लिए, सूची उसे छोड़कर भेजें। विकल्प ids GET /api/v1/polls/:commentId द्वारा लौटाए गए पोल पर होते हैं।
बिल्कुल भी ids न भेजने पर हर विकल्प बदल जाता है और पोल पर पहले से डाले गए हर वोट को हटा दिया जाता है। यदि पोल पर
वोट हैं, तो इसके लिए replaceVotes=true आवश्यक है, और इसके बिना API replace-votes-required के साथ प्रतिक्रिया देता है।
अन्य फ़ील्ड भी बदल दिए जाते हैं: closesAt, privacy या requireVoteToSeeResults को छोड़ने पर वे उनके डिफ़ॉल्ट पर
रीसेट हो जाते हैं। केवल एक फ़ील्ड बदलने और बाकी को वैसे ही छोड़ने के लिए, PATCH /api/v1/polls/:commentId का उपयोग करें।



अन्य नोट्स
- ऐसा
idजो पोल पर नहीं है, या एक हीidदो बार देना,poll-invalidके साथ विफल होता है। बिना पोल वाले कमेंट के पास अभी कोई विकल्प id नहीं होता, इसलिए उसे भेजे गए हर विकल्प मेंidछोड़ना होगा। - पोल की प्राइवेसी को संकुचित किया जा सकता है लेकिन वोट होने के बाद उसे बढ़ाया नहीं जा सकता।
- यह API आपकी साइट सेटिंग्स का पालन करता है। यदि साइट या पेज के लिए पोल सक्षम नहीं हैं, तो यह
polls-disabledके साथ विफल होता है। - लॉक किए गए कमेंट का पोल नहीं बदला जा सकता, और यह
lockedके साथ विफल होता है। - कनेक्टेड विजेट लाइव अपडेट होते हैं, इसलिए दर्शक रीलोड किए बिना नया पोल देख सकते हैं।
PATCH /api/v1/polls/:commentId 
वोट को बिना बाधित किए पोल को संपादित करता है। इसका उपयोग प्रश्न या किसी विकल्प में टाइपो ठीक करने, पोल को बंद या फिर से खोलने, या यह बदलने के लिए करें कि कौन देख सकता है कि किसने वोट दिया।
विकल्पों को उनके id से संबोधित किया जाता है, और PATCH उन विकल्पों का नाम बदल देता है जिन्हें आप नामित करते हैं। विकल्प जोड़ने, हटाने या क्रम बदलने के लिए, पूरी विकल्प सूची PUT /api/v1/polls/:commentId पर भेजें: जिन विकल्पों को आप उनकी ids के साथ भेजते हैं, वे वहीं अपने वोट बरकरार रखते हैं।
हर फ़ील्ड वैकल्पिक है, लेकिन कम से कम एक देना अनिवार्य है।




अन्य नोट्स
- पोल पर मौजूद नहीं किसी विकल्प की id नामित करने पर चुपचाप कुछ न करने के बजाय
poll-invalidके साथ विफल होता है। - लेबल पोल के भीतर अद्वितीय रहने चाहिए, जिन विकल्पों को आप नहीं बदल रहे हैं उन्हें भी गिनते हुए।
- पोल बनाने के विपरीत, यहाँ
closesAtअतीत में हो सकता है - इसी तरह आप पोल को तुरंत बंद करते हैं। - पोल की गोपनीयता को संकुचित किया जा सकता है लेकिन वोट होने के बाद बढ़ाया नहीं जा सकता।
- लॉक किए गए कमेंट का पोल नहीं बदला जा सकता, और यह
lockedके साथ विफल होता है।
DELETE /api/v1/polls/:commentId 
किसी पोल को उसके कमेंट से हटा देता है, साथ ही उस पर डाले गए सभी वोट भी हटा देता है। कमेंट खुद वैसा ही रहता है।
कमेंट को डिलीट करने से भी उसका पोल और वोट हट जाते हैं, इसलिए यह केवल तब ज़रूरी है जब आप कमेंट को बनाए रखना चाहते हैं।



पोल वोट संरचना 
एक PollVote किसी पोल पर एक व्यक्ति का उत्तर होता है। पोल पर दिखाए जाने वाले काउंट इनके साथ सिंक में रखे जाते हैं,
इसलिए आपको ये केवल तब चाहिए जब आप यह जानना चाहें कि किसने किस विकल्प के लिए वोट दिया, न कि कुल संख्या।
एक वोटर का प्रति पोल अधिकतम एक वोट होता है। दोबारा वोट देने पर दूसरा वोट जोड़ने के बजाय उनका मौजूदा वोट नए विकल्प पर चला जाता है,
और updatedAt यह रिकॉर्ड करता है कि वह कब हुआ।
voterId वह userId होता है जब वोटर लॉग इन था, अन्यथा वह anonUserId होता है।

गोपनीयता
पोल की privacy सेटिंग इस API पर उसी तरह लागू होती है जिस तरह वह कमेंट विजेट में लागू होती है:
- Anonymous (डिफ़ॉल्ट): कोई भी नहीं देख सकता कि किसी ने कैसे वोट दिया, इसलिए वोट पढ़े नहीं जा सकते।
GET /api/v1/poll-votesऔरGET /api/v1/poll-votes/:idpoll-anonymousके साथ प्रतिक्रिया देते हैं। पोल के काउंट अभी भीGET /api/v1/polls/:commentIdसे उपलब्ध हैं। - Admins और moderators: आपकी API key आपकी साइट के एडमिन की होती है, इसलिए यह वोट पढ़ सकती है।
- Everyone: वोट पढ़े जा सकते हैं।
पोल की गोपनीयता वोट होने के बाद संकुचित की जा सकती है लेकिन बढ़ाई नहीं जा सकती।
GET /api/v1/poll-votes 
एक पोल की गिनती के पीछे के व्यक्तिगत वोटों की सूची देता है, सबसे पुराने पहले। प्रत्येक 100 वोट लौटाने पर एक क्रेडिट।
एक पोल एक कमेंट से संबंधित होता है, इसलिए वोट एक समय में एक पोल के लिए पढ़े जाते हैं और commentId आवश्यक है। इसे और सीमित करें
voterId से यह जांचने के लिए कि एक व्यक्ति ने कैसे वोट किया, या optionId से यह सूचीबद्ध करने के लिए कि किसने किसी दिए गए विकल्प को चुना।
प्रति कॉल अधिकतम 1000 वोट लौटाए जाते हैं। अधिक के लिए पेज करने के लिए skip का उपयोग करें।
पोल की privacy सेटिंग का सम्मान किया जाता है: गुमनाम पोल पर वोट नहीं पढ़े जा सकते, और अनुरोध
poll-anonymous के साथ विफल हो जाता है। विवरण के लिए PollVote संरचना देखें।



प्रति विकल्प वोट गिनना
परिणाम प्राप्त करने के लिए आपको इन्हें जोड़ने की आवश्यकता नहीं है - पोल अपनी गिनती रखता है। पोल को पढ़ें
GET /api/v1/polls/:commentId से, और इस API का उपयोग तब करें जब आपको यह जानने की आवश्यकता हो कि किसने वोट किया।
एक पेज पर हर पोल
पूरे पेज की वोट सूची नहीं है। पूरे पेज पर रिपोर्ट करने के लिए, उसके कमेंट्स प्राप्त करें
GET /api/v1/comments से, जो प्रत्येक कमेंट का पोल और उसकी गिनती लौटाता है, और फिर उन पोल्स के वोट पढ़ें
जिनमें आपकी रुचि है।
GET /api/v1/poll-votes/:id 
अपनी id द्वारा एकल पोल वोट पढ़ता है।
गुमनाम पोल पर दिया गया वोट नहीं पढ़ा जा सकता, और अनुरोध poll-anonymous के साथ विफल हो जाता है। पोल की privacy सेटिंग कैसे लागू होती है, यह देखने के लिए PollVote
संरचना देखें।



POST /api/v1/poll-votes 
पोल पर एक वोट रिकॉर्ड करता है।
एक वोटर के पास प्रति पोल अधिकतम एक वोट होता है। उसी वोटर के लिए इसे दोबारा कॉल करने पर दूसरा वोट जोड़ने के बजाय उनका वोट नए विकल्प पर चला जाता है, और उसी विकल्प के लिए वोट करने पर कुछ नहीं होता।
प्रतिक्रिया में पोल शामिल होता है, इसलिए आपको दूसरा अनुरोध किए बिना अपडेट की गई गिनती मिल जाती है।




गुमनाम वोट
userId के स्थान पर anonUserId सेट करें ताकि किसी ऐसे व्यक्ति के लिए वोट रिकॉर्ड किया जा सके जो लॉग इन नहीं है। वह आईडी कहीं भी किसी उपयोगकर्ता से मेल खाना ज़रूरी नहीं है - यह केवल सत्र की पहचान करता है, ताकि एक ही व्यक्ति दो बार गिना न जाए।
गुमनाम वोटिंग आपकी साइट के लिए सक्षम होनी चाहिए। यदि वोटिंग केवल लॉग इन उपयोगकर्ताओं तक सीमित है, तो केवल anonUserId वाला वोट poll-login-required के साथ विफल हो जाता है।
गुमनाम वोट भी प्रति IP प्रति पोल रेट सीमित होते हैं, ताकि कोई व्यक्ति अपना सत्र साफ़ करके पोल को भर न सके। अंतिम उपयोगकर्ता का ip भेजें ताकि वह सीमा आपके सर्वर के बजाय उस पर लागू हो।
अन्य नोट्स
userIdआपकी साइट पर मौजूद किसी उपयोगकर्ता का होना चाहिए। दूसरी साइट के उपयोगकर्ता के लिए वोट अस्वीकार कर दिए जाते हैं।- बंद पोल पर वोट करना
poll-closedके साथ विफल हो जाता है। - यह API पोल पर गिनती अपडेट करता है और उन्हें कनेक्टेड विजेट्स पर लाइव भेजता है।
DELETE /api/v1/poll-votes/:id 
एक वोट वापस लेता है। जिस विकल्प पर वोट दिया गया था वह अपनी गिनती वापस प्राप्त कर लेता है, और मतदाता दोबारा वोट देने के लिए स्वतंत्र होता है।



अन्य नोट्स
- एक ही वोट को दो बार डिलीट करने पर दूसरी बार
not-foundप्रतिक्रिया मिलती है, और गिनती में कोई बदलाव नहीं होता। - यदि वोट देने के बाद पोल बदल दिया गया है, तो वोट हटा दिया जाता है लेकिन गिनती में कोई बदलाव नहीं होता, क्योंकि बदले गए पोल की गिनती शून्य से शुरू होती है।
PendingWebhookEvent संरचना 
एक PendingWebhookEvent ऑब्जेक्ट एक कतार में लंबित (pending) वेबहुक इवेंट का प्रतिनिधित्व करता है।
PendingWebhookEvent ऑब्जेक्ट स्वचालित रूप से बनाए जाते हैं और इन्हें API के माध्यम से मैन्युअल रूप से नहीं बनाया जा सकता। ये एक वर्ष के बाद समाप्त (expire) भी हो जाते हैं।
इन्हें डिलीट किया जा सकता है, जिससे यह कार्य कतार से हट जाता है।
अलग-अलग इवेंट प्रकार होते हैं - 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 
यह रूट एक ऑब्जेक्ट लौटाता है जिसमें count पैरामीटर के अंतर्गत लंबित वेबहुक इवेंट्स की संख्या होती है।
आप /pending-webhook-events एंडपॉइंट के समान पैरामीटर्स से फ़िल्टर कर सकते हैं।



DELETE /api/v1/pending-webhook-events/:id 
यह रूट एक सिंगल PendingWebhookEvent को डिलीट करने की अनुमति देता है।
यदि आपको बल्क डिलीट करने की आवश्यकता है, तो GET API को पेजिनेशन के साथ कॉल करें और फिर इस API को क्रमिक रूप से कॉल करें।



SSO उपयोगकर्ता संरचना 
FastComments एक उपयोग में आसान SSO समाधान प्रदान करता है। HMAC-आधारित इंटीग्रेशन के साथ उपयोगकर्ता की जानकारी अपडेट करना उतना ही सरल है जितना उपयोगकर्ता को अपडेटेड पेलोड के साथ पेज लोड करवाना।
हालाँकि, अपने एप्लिकेशन की निरंतरता (consistency) सुधारने के लिए उस फ्लो के बाहर उपयोगकर्ता को प्रबंधित करना वांछनीय हो सकता है।
SSO User API उन ऑब्जेक्ट्स को CRUD करने का एक तरीका प्रदान करती है जिन्हें हम SSOUsers कहते हैं। ये ऑब्जेक्ट्स सामान्य Users से अलग होते हैं और टाइप सेफ्टी के लिए अलग रखे जाते हैं।
SSOUser ऑब्जेक्ट की संरचना इस प्रकार है:

SSO उपयोगकर्ताओं के लिए बिलिंग
SSO उपयोगकर्ताओं की बिलिंग उनके परमिशन फ्लैग्स के आधार पर अलग-अलग होती है:
- सामान्य SSO उपयोगकर्ता: बिना एडमिन या मॉडरेटर परमिशन वाले उपयोगकर्ता सामान्य SSO उपयोगकर्ताओं के रूप में बिल किए जाते हैं
- SSO एडमिन:
isAccountOwnerयाisAdminAdminफ्लैग्स वाले उपयोगकर्ता SSO एडमिन के रूप में अलग से बिल किए जाते हैं (सामान्य टेनेंट एडमिन के समान दर पर) - SSO मॉडरेटर:
isCommentModeratorAdminफ्लैग वाले उपयोगकर्ता SSO मॉडरेटर के रूप में अलग से बिल किए जाते हैं (सामान्य मॉडरेटर के समान दर पर)
महत्वपूर्ण: दोहरी बिलिंग रोकने के लिए, सिस्टम ईमेल पते के आधार पर SSO उपयोगकर्ताओं को सामान्य टेनेंट उपयोगकर्ताओं और मॉडरेटर्स के विरुद्ध स्वचालित रूप से डीडुप्लिकेट करता है। यदि किसी SSO उपयोगकर्ता का ईमेल किसी सामान्य टेनेंट उपयोगकर्ता या मॉडरेटर के समान है, तो उनसे दो बार बिल नहीं किया जाएगा।
एक्सेस कंट्रोल
उपयोगकर्ताओं को समूहों में विभाजित किया जा सकता है। groupIds फ़ील्ड इसी काम के लिए है, और यह वैकल्पिक (optional) है।
@Mentions
डिफ़ॉल्ट रूप से, जब @ कैरेक्टर टाइप किया जाता है तो @mentions अन्य SSO उपयोगकर्ताओं को खोजने के लिए username का उपयोग करेगा। यदि displayName का उपयोग किया जाता है, तो जब displayName के लिए मैच होता है, username से मैच होने वाले परिणामों को अनदेखा कर दिया जाएगा, और @mention खोज परिणाम displayName का उपयोग करेंगे।
सब्सक्रिप्शन
FastComments के साथ, उपयोगकर्ता कमेंट विजेट में घंटी आइकन पर क्लिक करके और Subscribe पर क्लिक करके किसी पेज की सदस्यता ले सकते हैं।
सामान्य उपयोगकर्ता के साथ, हम उन्हें उनकी नोटिफिकेशन सेटिंग्स के आधार पर नोटिफिकेशन ईमेल भेजते हैं।
SSO उपयोगकर्ताओं के साथ, हम इसे पिछली संगतता (backwards compatibility) के लिए विभाजित करते हैं। उपयोगकर्ताओं को ये अतिरिक्त सब्सक्रिप्शन नोटिफिकेशन ईमेल तभी भेजे जाएंगे जब आप optedInSubscriptionNotifications को true पर सेट करें।
बैज
आप badgeConfig प्रॉपर्टी का उपयोग करके SSO उपयोगकर्ताओं को बैज असाइन कर सकते हैं। बैज विज़ुअल इंडिकेटर होते हैं जो कमेंट्स में उपयोगकर्ता के नाम के बगल में दिखाई देते हैं।
badgeIds- उपयोगकर्ता को असाइन करने के लिए बैज ID की एक सरणी। ये सभी पेजों पर दिखाई देने वाले ग्लोबल बैज हैं। आपके FastComments खाते में बनाई गई वैध बैज ID होनी चाहिए। अधिकतम 30 बैज।pageBadgeIds- वर्तमान पेज (urlId) तक सीमित बैज ID की एक वैकल्पिक सरणी। ये बैज केवल उस पेज पर प्रदर्शित होते हैं जहाँ उन्हें असाइन किया गया था। एक ही उपयोगकर्ता के लिए अलग-अलग पेजों पर अलग-अलग पेज-स्कोप्ड बैज हो सकते हैं।override- यदि true है, तो सभी मौजूदा प्रदर्शित बैज प्रदान किए गए बैजों से बदल दिए जाएंगे। ग्लोबल और पेज-स्कोप्ड बैज स्वतंत्र रूप से ओवरराइड किए जाते हैं — ग्लोबल बैज को ओवरराइड करना पेज-स्कोप्ड बैज को प्रभावित नहीं करता, और इसके विपरीत भी। यदि false या छोड़ा गया हो, तो प्रदान किए गए बैज किसी भी मौजूदा बैज में जोड़ दिए जाएंगे।update- यदि true है, तो जब भी उपयोगकर्ता लॉग इन करेगा, बैज डिस्प्ले प्रॉपर्टीज़ टेनेंट कॉन्फ़िगरेशन से अपडेट कर दी जाएंगी।
GET /api/v1/sso-users 
यह रूट SSO यूज़र्स को 100 के पेजों में लौटाता है। पेजिनेशन skip पैरामीटर द्वारा प्रदान की जाती है। यूज़र्स को उनके signUpDate और id के अनुसार सॉर्ट किया जाता है।



GET /api/v1/sso-users/by-id/: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 यूज़र के निर्माण की सुविधा देता है।
समान ID वाले दो यूज़र बनाने की कोशिश करने पर त्रुटि (error) मिलेगी।

इस उदाहरण में हम एक्सेस कंट्रोल के लिए groupIds निर्दिष्ट करते हैं, लेकिन यह वैकल्पिक (optional) है।


इंटीग्रेशन नोट
API द्वारा पास किया गया डेटा केवल एक अलग SSO User HMAC पेलोड पास करके ओवरराइड किया जा सकता है। उदाहरण के लिए, यदि आप API के माध्यम से एक username सेट करते हैं, लेकिन फिर पेज लोड पर SSO फ्लो के माध्यम से एक अलग username पास करते हैं, तो हम उनका username स्वचालित रूप से अपडेट कर देंगे।
हम इस फ्लो में यूज़र पैरामीटर अपडेट नहीं करेंगे जब तक कि आप उन्हें स्पष्ट रूप से निर्दिष्ट न करें या उन्हें null (undefined नहीं) पर सेट न करें।
PUT /api/v1/sso-users/:id 
यह रूट एक सिंगल SSO यूज़र को अपडेट करने की सुविधा प्रदान करता है।

इस उदाहरण में हम एक्सेस कंट्रोल के लिए groupIds निर्दिष्ट करते हैं, लेकिन यह वैकल्पिक है।


DELETE /api/v1/sso-users/:id 
यह रूट एक SSO यूज़र को उनकी id के आधार पर हटाने की सुविधा प्रदान करता है।
ध्यान दें कि इस यूज़र के लिए पेलोड के साथ कमेंट विजेट को दोबारा लोड करने पर यूज़र बिना किसी बाधा के आसानी से फिर से बन जाएगा।
deleteComments क्वेरी पैरामीटर के माध्यम से यूज़र के कमेंट्स को हटाना संभव है। ध्यान दें कि यदि यह true है:
- यूज़र के सभी कमेंट्स लाइव हटा दिए जाएंगे।
- सभी child (अब अनाथ) कमेंट्स प्रत्येक कमेंट से जुड़े पेज कॉन्फ़िगरेशन के आधार पर हटा दिए जाएंगे या गुमनाम (anonymize) कर दिए जाएंगे। उदाहरण के लिए यदि थ्रेड डिलीशन मोड "anonymize" है, तो रिप्लाई बने रहेंगे, और यूज़र के कमेंट्स गुमनाम कर दिए जाएंगे। यह केवल तब लागू होता है जब
commentDeleteModeRemoveहो (डिफ़ॉल्ट मान)। creditsCost2हो जाता है।
गुमनाम किए गए कमेंट्स
आप यूज़र के कमेंट्स को बनाए रख सकते हैं लेकिन commentDeleteMode=1 सेट करके उन्हें केवल गुमनाम कर सकते हैं।
यदि यूज़र के कमेंट्स गुमनाम कर दिए गए हैं तो निम्नलिखित मान null सेट कर दिए जाते हैं:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badges
isDeleted और isDeletedUser को true सेट कर दिया जाता है।
रेंडरिंग के समय, कमेंट विजेट यूज़र के नाम के लिए DELETED_USER_PLACEHOLDER (डिफ़ॉल्ट: "[deleted]") और कमेंट के लिए DELETED_CONTENT_PLACEHOLDER का उपयोग करेगा। इन्हें Widget Customization UI के माध्यम से कस्टमाइज़ किया जा सकता है।
उदाहरण



सदस्यता संरचना 
एक Subscription ऑब्जेक्ट किसी उपयोगकर्ता की सदस्यता (subscription) को दर्शाता है।
Subscription ऑब्जेक्ट तब बनाए जाते हैं जब कोई उपयोगकर्ता कमेंट विजेट में नोटिफिकेशन बेल पर क्लिक करता है और "Subscribe to this page" पर क्लिक करता है।
सदस्यताएँ API के माध्यम से भी बनाई जा सकती हैं।
एक Subscription ऑब्जेक्ट होने से, संबंधित पेज के रूट पर नए कमेंट छोड़े जाने पर, उस Subscription के लिए Notification ऑब्जेक्ट बनते हैं और ईमेल भेजे जाते हैं। ईमेल भेजना उपयोगकर्ता के प्रकार पर निर्भर करता है। सामान्य उपयोगकर्ताओं के लिए यह optedInNotifications पर निर्भर करता है। SSO उपयोगकर्ताओं के लिए यह optedInSubscriptionNotifications पर निर्भर करता है। ध्यान दें कि कुछ एप्लिकेशन में वेब-एक्सेसिबल पेज की अवधारणा नहीं हो सकती, ऐसे में बस urlId को उस आइटम की id पर सेट करें जिसकी आप सदस्यता ले रहे हैं (कमेंट विजेट को जो urlId पास करेंगे, वही मान)।
Subscription ऑब्जेक्ट की संरचना इस प्रकार है:

GET /api/v1/subscriptions/:id 
यह रूट createdAt के अनुसार क्रमबद्ध, नवीनतम पहले, अधिकतम 30 Subscription ऑब्जेक्ट लौटाता है।
आप userId द्वारा फ़िल्टर कर सकते हैं। SSO के साथ, यूज़र आईडी <tenant id>:<user id> प्रारूप में होती है।



POST /api/v1/subscriptions 
यह API एंडपॉइंट एक Subscription बनाने की क्षमता प्रदान करता है। ध्यान दें कि एक उपयोगकर्ता के पास प्रति पेज केवल एक सब्सक्रिप्शन हो सकता है, क्योंकि अधिक होना निरर्थक है, और उसी उपयोगकर्ता के लिए उसी पेज पर एक से अधिक सब्सक्रिप्शन बनाने की कोशिश करने पर त्रुटि होगी।
सब्सक्रिप्शन बनाने पर, सब्सक्राइब किए गए urlId के रूट पर नया कमेंट आने पर (जब कमेंट का parentId null हो) Notification ऑब्जेक्ट्स बनाए जाएंगे।



DELETE /api/v1/subscriptions/:id 
यह रूट id द्वारा एकल Subscription ऑब्जेक्ट को डिलीट करता है।



TenantDailyUsage संरचना 
एक TenantDailyUsage ऑब्जेक्ट किसी टेनेंट के लिए किसी दिए गए दिन के उपयोग को दर्शाता है। यदि किसी दिए गए दिन में किसी टेनेंट की कोई गतिविधि नहीं थी, तो उस दिन के लिए कोई TenantDailyUsage ऑब्जेक्ट नहीं होगा।
TenantDailyUsage ऑब्जेक्ट रीयल टाइम नहीं है और वास्तविक उपयोग से कुछ मिनट पीछे हो सकता है।
TenantDailyUsage ऑब्जेक्ट की संरचना इस प्रकार है:

GET /api/v1/tenant-daily-usage 
यह रूट किसी टेनेंट के उपयोग को वर्ष, माह और दिन के आधार पर खोजने की सुविधा देता है। अधिकतम 365 ऑब्जेक्ट लौटाए जा सकते हैं, और लागत प्रति 10 ऑब्जेक्ट पर 1 API क्रेडिट है।
रिस्पॉन्स ऑब्जेक्ट उनकी निर्माण तिथि के अनुसार क्रमबद्ध होते हैं (सबसे पुराना पहले)।



टेनेंट संरचना 
Tenant एक FastComments.com ग्राहक (customer) को परिभाषित करता है। इन्हें API के माध्यम से उन tenants द्वारा बनाया जा सकता है जिनके पास white labeling एक्सेस है। White labeled tenants अन्य white labeled tenants नहीं बना सकते (केवल एक स्तर की nesting की अनुमति है)।
Tenant ऑब्जेक्ट की संरचना इस प्रकार है:

GET /api/v1/tenants/:id 
यह रूट id द्वारा एकल Tenant लौटाता है।



GET /api/v1/tenants 
यह API उन tenants को लौटाती है जो आपके tenant द्वारा प्रबंधित हैं।
पेजिनेशन skip क्वेरी पैरामीटर द्वारा प्रदान की जाती है। Tenants 100 के पेजों में लौटाए जाते हैं, जो signUpDate और id के अनुसार क्रमबद्ध होते हैं।
लागत लौटाए गए tenants की संख्या पर आधारित है, जो 1 credit per 10 लौटाए गए tenants के अनुसार है।

आप Tenant ऑब्जेक्ट्स पर meta पैरामीटर परिभाषित कर सकते हैं और मेल खाते tenants के लिए क्वेरी कर सकते हैं। उदाहरण के लिए, कुंजी someKey और meta मान some-value के लिए, हम इस कुंजी/मान जोड़ी के साथ एक JSON ऑब्जेक्ट बना सकते हैं और फिर इसे फ़िल्टर करने के लिए एक क्वेरी पैरामीटर के रूप में URI एनकोड कर सकते हैं:



POST /api/v1/tenants 
यह रूट एकल Tenant जोड़ने की क्षमता प्रदान करता है।
Tenant बनाने के लिए निम्नलिखित प्रतिबंध हैं:
- एक
nameआवश्यक है। domainConfigurationआवश्यक है।Tenantबनाते समय निम्नलिखित मान प्रदान नहीं किए जा सकते:hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmount
signUpDateभविष्य की तारीख नहीं हो सकती।name200 charactersसे लंबा नहीं हो सकता।email300 charactersसे लंबा नहीं हो सकता।emailFastComments.com के सभी tenants में अद्वितीय होना चाहिए।- यदि पैरेंट tenant के पास मान्य
TenantPackageपरिभाषित नहीं है, तो आप tenants नहीं बना सकते।- यदि आपका tenant FastComments.com के माध्यम से बनाया गया था, तो यह कोई समस्या नहीं होनी चाहिए।
- आप अपने पैकेज में
maxWhiteLabeledTenantsके अंतर्गत परिभाषित से अधिक tenants नहीं बना सकते। - आपको
tenantIdक्वेरी पैरामीटर निर्दिष्ट करना होगा, जो आपके white labeling सक्षमparent tenantकी id है।
हम कुछ ही पैरामीटर के साथ एक Tenant बना सकते हैं:



PATCH /api/v1/tenants/:id 
यह API एंडपॉइंट id द्वारा एक Tenant को अपडेट करने की क्षमता प्रदान करता है।
एक Tenant को अपडेट करने की निम्नलिखित सीमाएँ हैं:
- निम्नलिखित मान अपडेट नहीं किए जा सकते:
hasFlexPricinglastBillingIssueReminderDateflexLastBilledAmountmanagedByTenantId
signUpDateभविष्य में नहीं हो सकता।name200 charactersसे लंबा नहीं हो सकता।email300 charactersसे लंबा नहीं हो सकता।emailFastComments.com के सभी tenants में अद्वितीय होना चाहिए।billingInfoValidकोtrueपर सेट करते समय, उसी अनुरोध मेंbillingInfoप्रदान किया जाना चाहिए।- आप अपने स्वयं के tenant से जुड़े
packageIdको अपडेट नहीं कर सकते। - आप अपने स्वयं के tenant से जुड़े
paymentFrequencyको अपडेट नहीं कर सकते।



DELETE /api/v1/tenants/:id 
यह रूट id द्वारा एक Tenant और उससे जुड़े सभी डेटा (users, comments, आदि) को हटाने की सुविधा प्रदान करता है।
Tenants को हटाने के लिए निम्नलिखित प्रतिबंध लागू हैं:
- Tenant आपका अपना होना चाहिए, या ऐसा white labeled tenant होना चाहिए जिसे आप प्रबंधित करते हैं।
surequery parameter कोtrueपर सेट होना चाहिए।



टेनेंट पैकेज संरचना 
TenantPackage एक Tenant के लिए उपलब्ध पैकेज की जानकारी परिभाषित करता है। एक टेनेंट के पास कई पैकेज उपलब्ध हो सकते हैं, लेकिन किसी दिए गए समय पर केवल एक ही उपयोग में होता है।
जब तक एक Tenant का packageId किसी मान्य TenantPackage की ओर इंगित नहीं करता, तब तक उसे किसी भी प्रोडक्ट के लिए उपयोग नहीं किया जा सकता।
TenantPackage ऑब्जेक्ट दो प्रकार के होते हैं:
- निश्चित मूल्य वाले पैकेज - जहाँ
hasFlexPricingfalse होता है। - लचीला मूल्य निर्धारण (Flexible pricing) - जहाँ
hasFlexPricingtrue होता है।
दोनों स्थितियों में, पैकेज का उपयोग करने वाले खाते पर सीमाएँ परिभाषित की जाती हैं, हालाँकि Flex के साथ टेनेंट से एक आधार मूल्य के साथ-साथ उनके उपयोग के अनुसार शुल्क लिया जाता है, जो flex* पैरामीटर द्वारा परिभाषित होता है।
एक टेनेंट के पास कई टेनेंट पैकेज हो सकते हैं और वह Billing Info Page. से स्वयं पैकेज बदलने में सक्षम हो सकता है।
यदि आप स्वयं टेनेंट्स के लिए बिलिंग संभालेंगे, तो भी आपको प्रत्येक टेनेंट के लिए उनकी सीमाएँ परिभाषित करने हेतु एक पैकेज परिभाषित करना होगा। बस Tenant पर billingHandledExternally को true सेट करें और वे स्वयं अपनी बिलिंग जानकारी, या सक्रिय पैकेज, बदलने में सक्षम नहीं होंगे।
आप पैरेंट टेनेंट से अधिक सीमाओं वाले पैकेज नहीं बना सकते।
TenantPackage ऑब्जेक्ट की संरचना इस प्रकार है:

GET /api/v1/tenant-packages/:id 
यह रूट id द्वारा एकल Tenant Package लौटाता है।



GET /api/v1/tenant-packages 
यह API पेजिनेशन का उपयोग करती है, जो skip क्वेरी पैरामीटर द्वारा प्रदान की जाती है। TenantPackages 100 के पृष्ठों में लौटाए जाते हैं, createdAt और id के अनुसार क्रमबद्ध।
लागत लौटाए गए टेनेंट पैकेजों की संख्या पर आधारित है, जिसमें प्रत्येक 10 टेनेंट पैकेजों पर 1 क्रेडिट लगता है।



POST /api/v1/tenant-packages 
यह रूट एक सिंगल TenantPackage जोड़ने की सुविधा प्रदान करता है।
एक TenantPackage बनाने के लिए निम्नलिखित प्रतिबंध हैं:
- निम्नलिखित पैरामीटर आवश्यक हैं:
nametenantIdmonthlyCostUSD- null हो सकता है।yearlyCostUSD- null हो सकता है।maxMonthlyPageLoadsmaxMonthlyAPICreditsmaxMonthlyCommentsmaxConcurrentUsersmaxTenantUsersmaxSSOUsersmaxModeratorsmaxDomainshasDebrandingforWhoTextfeatureTaglineshasFlexPricing- यदि true है, तो सभीflex*पैरामीटर आवश्यक हैं।
nameकी लंबाई50 charactersसे अधिक नहीं हो सकती।- प्रत्येक
forWhoTextआइटम की लंबाई200 charactersसे अधिक नहीं हो सकती। - प्रत्येक
featureTaglinesआइटम की लंबाई100 charactersसे अधिक नहीं हो सकती। TenantPackageपैरेंट टेनेंट से "छोटा" होना चाहिए। उदाहरण के लिए, सभीmax*पैरामीटर के मान पैरेंट टेनेंट से कम होने चाहिए।- एक व्हाइट लेबल वाले टेनेंट में अधिकतम पाँच पैकेज हो सकते हैं।
- केवल व्हाइट लेबलिंग एक्सेस वाले टेनेंट ही
TenantPackageबना सकते हैं। - आप अपने ही टेनेंट में पैकेज नहीं जोड़ सकते। :)
हम एक TenantPackage इस प्रकार बना सकते हैं:



PATCH /api/v1/tenant-packages/:id 
यह API एंडपॉइंट id द्वारा एक TenantPackage को अपडेट करने की क्षमता प्रदान करता है।
एक TenantPackage को अपडेट करने की निम्नलिखित पाबंदियाँ हैं:
- यदि आप
hasFlexPricingको true सेट कर रहे हैं, तो उसी अनुरोध में सभीflex*पैरामीटर आवश्यक हैं। nameकी लंबाई50 charactersसे अधिक नहीं हो सकती।- प्रत्येक
forWhoTextआइटम की लंबाई200 charactersसे अधिक नहीं हो सकती। - प्रत्येक
featureTaglinesआइटम की लंबाई100 charactersसे अधिक नहीं हो सकती। TenantPackageपैरेंट टेनेंट से "छोटा" होना चाहिए। उदाहरण के लिए, सभीmax*पैरामीटर के मान पैरेंट टेनेंट से कम होने चाहिए।- आप
TenantPackageसे जुड़ेtenantIdको नहीं बदल सकते।



DELETE /api/v1/tenant-packages/:id 
यह रूट एक TenantPackage को id द्वारा हटाने की सुविधा प्रदान करता है।
आप उस TenantPackage को हटा नहीं सकते जो उपयोग में है (किसी tenant का packageId उस पैकेज की ओर इशारा करता है)। पहले Tenant को अपडेट करें।



टेनेंट उपयोगकर्ता संरचना 
TenantUser एक User को परिभाषित करता है जो एक विशिष्ट टेनेंट द्वारा प्रबंधित होता है। उनका खाता उस टेनेंट पर पूर्ण नियंत्रण रखता है जिससे वे संबद्ध हैं, और उनके खाते को UI या API के माध्यम से अपडेट या डिलीट किया जा सकता है।
टेनेंट उपयोगकर्ता Tenant तक सभी अनुमतियों और पहुँच वाले व्यवस्थापक हो सकते हैं, या उन्हें टिप्पणियों के संचालन, API कुंजियों तक पहुँच, आदि जैसी विशिष्ट अनुमतियों तक सीमित किया जा सकता है।
TenantUser ऑब्जेक्ट की संरचना इस प्रकार है:

GET /api/v1/tenant-users/:id 
यह रूट id द्वारा एकल TenantUser लौटाता है।



GET /api/v1/tenant-users 
यह API पेजिनेशन का उपयोग करती है, जो skip क्वेरी पैरामीटर द्वारा प्रदान की जाती है। TenantUsers 100 के पृष्ठों में लौटाए जाते हैं, जो signUpDate, username और id के अनुसार क्रमबद्ध होते हैं।
लागत लौटाए गए tenant users की संख्या पर आधारित है, जो प्रति 10 लौटाए गए tenant users पर 1 credit है।



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 पर लॉगिन करने का तरीका न बताना पड़े। यह उन्हें लॉगिन के लिए एक "magic link" भेज देगा जो 30 days के बाद समाप्त हो जाता है।
किसी TenantUser को लॉगिन लिंक भेजने के लिए निम्नलिखित प्रतिबंध मौजूद हैं:
TenantUserपहले से मौजूद होना चाहिए।- आपके पास उस
Tenantको प्रबंधित करने की पहुँच होनी चाहिए जिससेTenantUserसंबंधित है।
हम किसी TenantUser को लॉगिन लिंक इस प्रकार भेज सकते हैं:

इससे Bob at TenantName is inviting you to be a moderator... जैसा एक ईमेल भेजा जाएगा।


PATCH /api/v1/tenant-users/:id 
यह रूट एकल TenantUser को अपडेट करने की क्षमता प्रदान करता है।
एक TenantUser को अपडेट करने की निम्नलिखित पाबंदियाँ हैं:
signUpDateभविष्य में नहीं हो सकता।localeसमर्थित लोकेल की सूची में होना चाहिए।usernameपूरे FastComments.com पर अद्वितीय होना चाहिए। यदि यह समस्या है, तो हम SSO का उपयोग करने का सुझाव देते हैं।emailपूरे FastComments.com पर अद्वितीय होना चाहिए। यदि यह समस्या है, तो हम SSO का उपयोग करने का सुझाव देते हैं।- आप किसी उपयोगकर्ता का
tenantIdअपडेट नहीं कर सकते।
हम एक TenantUser इस प्रकार अपडेट कर सकते हैं:



DELETE /api/v1/tenant-users/:id 
यह रूट TenantUser को id द्वारा हटाने की सुविधा प्रदान करता है।
deleteComments क्वेरी पैरामीटर के माध्यम से यूज़र की टिप्पणियों को हटाना संभव है। ध्यान दें कि यदि यह true है:
- यूज़र की सभी टिप्पणियाँ लाइव हटा दी जाएँगी।
- सभी child (अब अनाथ) टिप्पणियाँ प्रत्येक टिप्पणी से संबंधित पेज कॉन्फ़िगरेशन के आधार पर हटाई या गुमनाम कर दी जाएँगी। उदाहरण के लिए यदि थ्रेड डिलीशन मोड "anonymize" है, तो रिप्लाई बने रहेंगे, और यूज़र की टिप्पणियाँ गुमनाम कर दी जाएँगी। यह केवल तब लागू होता है जब
commentDeleteModeRemoveहो (डिफ़ॉल्ट मान)। creditsCost2हो जाता है।
गुमनाम की गई टिप्पणियाँ
आप यूज़र की टिप्पणियों को बनाए रख सकते हैं लेकिन commentDeleteMode=1 सेट करके उन्हें केवल गुमनाम कर सकते हैं।
यदि यूज़र की टिप्पणियाँ गुमनाम कर दी जाती हैं तो निम्नलिखित मान null सेट कर दिए जाते हैं:
- commenterName
- commenterEmail
- avatarSrc
- userId
- anonUserId
- mentions
- badges
isDeleted और isDeletedUser को true सेट कर दिया जाता है।
रेंडरिंग के समय, कमेंट विजेट यूज़र के नाम के लिए DELETED_USER_PLACEHOLDER (डिफ़ॉल्ट: "[deleted]") और टिप्पणी के लिए DELETED_CONTENT_PLACEHOLDER का उपयोग करेगा। इन्हें Widget Customization UI के माध्यम से अनुकूलित किया जा सकता है।
उदाहरण



उपयोगकर्ता संरचना 
User एक ऑब्जेक्ट है जो सभी उपयोगकर्ताओं के सबसे सामान्य गुणों को दर्शाता है।
ध्यान रखें कि FastComments पर उपयोगकर्ताओं के लिए हमारे पास कई अलग-अलग उपयोग के मामले हैं:
- Secure SSO
- Simple SSO
- Tenant Users (उदाहरण के लिए: Administrators)
- Commenters
यह API Commenters और Simple SSO के माध्यम से बनाए गए उपयोगकर्ताओं के लिए है। मूल रूप से, आपकी साइट के माध्यम से बनाया गया कोई भी उपयोगकर्ता इस API के माध्यम से एक्सेस किया जा सकता है। Tenant Users को भी इस तरह प्राप्त किया जा सकता है, लेकिन /tenant-users/ API के साथ इंटरैक्ट करने पर आपको अधिक जानकारी मिलेगी।
Secure SSO के लिए कृपया /sso-users/ API का उपयोग करें।
आप इन प्रकार के उपयोगकर्ताओं को अपडेट नहीं कर सकते। उन्होंने अपना खाता आपकी साइट के माध्यम से बनाया है, इसलिए हम कुछ बुनियादी केवल-पढ़ने योग्य (read-only) एक्सेस प्रदान करते हैं, लेकिन
आप बदलाव नहीं कर सकते। यदि आप इस प्रकार का फ्लो चाहते हैं - तो आपको Secure SSO सेटअप करना होगा।
User ऑब्जेक्ट की संरचना इस प्रकार है:

GET /api/v1/users/:id 
यह रूट id द्वारा एकल User लौटाता है।



वोट संरचना 
एक Vote ऑब्जेक्ट किसी उपयोगकर्ता द्वारा दिए गए वोट को दर्शाता है।
कमेंट्स और वोट के बीच संबंध commentId के माध्यम से परिभाषित होता है।
Vote ऑब्जेक्ट की संरचना इस प्रकार है:

GET /api/v1/votes 
वोट को urlId द्वारा फ़ेच किया जाना चाहिए।
वोट के प्रकार
तीन प्रकार के वोट होते हैं:
- प्रमाणित वोट (Authenticated Votes), जो संबंधित कमेंट पर लागू होते हैं। आप इन्हें इस API के माध्यम से बना सकते हैं।
- प्रमाणित वोट, जो सत्यापन के लिए लंबित (pending) हैं, और इस प्रकार अभी तक कमेंट पर लागू नहीं हुए हैं। ये तब बनाए जाते हैं जब कोई उपयोगकर्ता FastComments.com के login to vote तंत्र का उपयोग करता है।
- अनाम वोट (Anonymous Votes), जो संबंधित कमेंट पर लागू होते हैं। ये अनाम कमेंटिंग के साथ बनाए जाते हैं।
भ्रम को कम करने के लिए इन्हें API में अलग-अलग सूचियों में लौटाया जाता है।



अनाम वोट संबंधी नोट्स
ध्यान दें कि इस API के माध्यम से बनाए गए अनाम वोट appliedAuthorizedVotes सूची में दिखाई देंगे। उन्हें प्राधिकृत माना जाता है क्योंकि उन्हें API के माध्यम से API कुंजी के साथ बनाया गया था।
appliedAnonymousVotes संरचना उन वोटों के लिए है जो बिना ईमेल, API कुंजी आदि के बनाए गए थे।
GET /api/v1/votes/for-user 
किसी दिए गए urlId पर एक उपयोगकर्ता द्वारा छोड़े गए वोट प्राप्त करने की सुविधा देता है। यह एक userId लेता है जो कोई भी FastComments.com या SSO User हो सकता है।
यह तब उपयोगी है जब आप यह दिखाना चाहें कि उपयोगकर्ता ने किसी कमेंट पर वोट किया है या नहीं। कमेंट प्राप्त करते समय, बस उसी समय उसी urlId के लिए उपयोगकर्ता के लिए इस API को कॉल करें।
यदि आप गुमनाम (anonymous) वोटिंग का उपयोग कर रहे हैं, तो आप userId के स्थान पर anonUserId पास करना चाहेंगे।


ध्यान दें कि गुमनाम वोट appliedAuthorizedVotes सूची में दिखाई देंगे। उन्हें अधिकृत माना जाता है क्योंकि उन्हें API के माध्यम से API कुंजी के साथ बनाया गया था।


POST /api/v1/votes 
यह रूट एकल अधिकृत Vote जोड़ने की क्षमता प्रदान करता है। वोट up (+1) या down (-1) हो सकते हैं।




गुमनाम वोट बनाना
गुमनाम वोट userId के स्थान पर क्वेरी पैरामीटर में anonUserId सेट करके बनाए जा सकते हैं।
यह id को कहीं भी किसी user ऑब्जेक्ट से मेल खाना ज़रूरी नहीं है (इसीलिए यह गुमनाम है)। यह केवल सेशन के लिए एक पहचानकर्ता है, ताकि आप उसी सेशन में वोट को फिर से प्राप्त कर सकें और जांच सकें कि किसी कमेंट पर वोट किया गया है या नहीं।
यदि आपके पास FastComments की तरह "गुमनाम सेशन" जैसी कोई चीज़ नहीं है - तो आप इसे बस एक यादृच्छिक ID, जैसे UUID पर सेट कर सकते हैं (हालाँकि स्थान बचाने के लिए हम छोटे पहचानकर्ताओं को प्राथमिकता देते हैं)।
अन्य नोट्स
- यह API टेनेंट-स्तरीय सेटिंग्स का पालन करता है। उदाहरण के लिए, यदि आप किसी दिए गए पेज के लिए वोटिंग अक्षम करते हैं, और API के माध्यम से वोट बनाने का प्रयास करते हैं, तो यह त्रुटि कोड
voting-disabledके साथ विफल हो जाएगा। - यह API डिफ़ॉल्ट रूप से लाइव है।
- यह API संबंधित
Commentकेvotesको अपडेट करेगा।
DELETE /api/v1/votes/:id 
यह रूट एकल Vote को डिलीट करने की सुविधा प्रदान करता है।



नोट्स:
- यह API टेनेंट-स्तरीय सेटिंग्स का पालन करता है। उदाहरण के लिए, यदि आप किसी दिए गए पेज के लिए वोटिंग अक्षम करते हैं और API के माध्यम से वोट बनाने का प्रयास करते हैं, तो यह
voting-disabledत्रुटि कोड के साथ विफल हो जाएगा। - यह API डिफ़ॉल्ट रूप से लाइव है।
- यह API संबंधित
Commentकेvotesको अपडेट करेगा।
DomainConfig संरचना 
एक DomainConfig ऑब्जेक्ट किसी टेनेंट के लिए एक डोमेन की कॉन्फ़िगरेशन दर्शाता है।
DomainConfig ऑब्जेक्ट की संरचना इस प्रकार है:


प्रमाणीकरण के लिए
डोमेन कॉन्फ़िगरेशन का उपयोग यह निर्धारित करने के लिए किया जाता है कि कौन सी साइटें आपके खाते के लिए FastComments विजेट होस्ट कर सकती हैं। यह प्रमाणीकरण का एक बुनियादी रूप है, जिसका अर्थ है कि किसी भी डोमेन कॉन्फ़िगरेशन को जोड़ने या हटाने से प्रोडक्शन में आपकी FastComments इंस्टॉलेशन की उपलब्धता प्रभावित हो सकती है।
किसी ऐसे डोमेन के लिए Domain Config की domain प्रॉपर्टी को हटाएं या अपडेट न करें जो वर्तमान में उपयोग में है, जब तक कि उस डोमेन को अक्षम करना इरादा न हो।
इसका व्यवहार /auth/my-account/configure-domains से डोमेन हटाने जैसा ही है।
यह भी ध्यान दें कि My Domains UI से डोमेन हटाने से उस डोमेन के लिए इस UI के माध्यम से जोड़ी गई कोई भी संबंधित कॉन्फ़िगरेशन हट जाएगी।
ईमेल अनुकूलन के लिए
ईमेल फुटर में अनसब्सक्राइब लिंक, और कई ईमेल क्लाइंट द्वारा प्रदान की जाने वाली वन-क्लिक-अनसब्सक्राइब सुविधा, को इस API के माध्यम से क्रमशः footerUnsubscribeURL और emailHeaders को परिभाषित करके कॉन्फ़िगर किया जा सकता है।
DKIM के लिए
अपने DKIM DNS रिकॉर्ड परिभाषित करने के बाद, परिभाषित संरचना का उपयोग करके अपने DKIM कॉन्फ़िगरेशन के साथ DomainConfig को बस अपडेट करें।
GET /api/v1/domain-configs 
यह API एक tenant के लिए सभी DomainConfig ऑब्जेक्ट्स प्राप्त करने की क्षमता प्रदान करता है।



GET /api/v1/domain-configs/:domain 
अलग-अलग DomainConfigs को उनके संबंधित domain के आधार पर प्राप्त (fetch) किया जा सकता है।



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 
यह रूट id द्वारा एकल DomainConfig को हटाने की सुविधा प्रदान करता है।
- नोट:
DomainConfigको हटाने से उस डोमेन का FastComments उपयोग करने का अधिकार समाप्त हो जाएगा। - नोट: UI के माध्यम से डोमेन को दोबारा जोड़ने पर ऑब्जेक्ट फिर से बन जाएगा (केवल
domainपॉपुलेटेड के साथ)।



QuestionConfig संरचना 
FastComments प्रश्न बनाने और उनके परिणामों को संग्रहित (aggregate) करने का एक तरीका प्रदान करता है। एक प्रश्न (आगे इसे QuestionConfig कहा जाएगा) का उदाहरण
एक स्टार रेटिंग, एक स्लाइडर, या एक NPS प्रश्न हो सकता है (type के माध्यम से निर्धारित)।
प्रश्न डेटा को अलग-अलग, साथ में, समय के साथ, समग्र रूप से, पेज के अनुसार आदि तरीकों से संग्रहित किया जा सकता है।
इस फ्रेमवर्क में क्लाइंट-साइड विजेट (इस API के सामने आपके सर्वर के साथ), एडमिन डैशबोर्ड, और रिपोर्टिंग टूल बनाने के लिए आवश्यक सभी क्षमताएं मौजूद हैं।
सबसे पहले, हमें एक QuestionConfig परिभाषित करना होगा। इसकी संरचना इस प्रकार है:

GET /api/v1/question-configs 
यह रूट एक बार में 100 तक QuestionConfig ऑब्जेक्ट लौटाता है, पृष्ठांकित (paginated) रूप में। प्रत्येक 100 ऑब्जेक्ट की लागत 1 है। इन्हें प्रश्न पाठ के आरोही क्रम (question फ़ील्ड) में क्रमबद्ध किया जाता है।



GET /api/v1/question-configs/:id 
यह रूट अपनी id के आधार पर एकल QuestionConfig लौटाता है।



POST /api/v1/question-configs 
यह API एंडपॉइंट एक QuestionConfig बनाने की क्षमता प्रदान करता है।



PATCH /api/v1/question-configs/:id 
यह रूट एक सिंगल QuestionConfig को अपडेट करने की क्षमता प्रदान करता है।
निम्नलिखित संरचना उन सभी मानों को दर्शाती है जिन्हें बदला जा सकता है:




DELETE /api/v1/question-configs/:id 
यह रूट QuestionConfig को id द्वारा हटाने की सुविधा प्रदान करता है।
यह सभी संबंधित question results को हटा देगा (लेकिन comments नहीं)। यह उच्च credit लागत का एक हिस्सा है।



QuestionResult संरचना 
प्रश्नों के परिणाम सहेजने के लिए, आप एक QuestionResult बनाते हैं। इसके बाद आप प्रश्न परिणामों को एग्रीगेट कर सकते हैं, और रिपोर्टिंग उद्देश्यों के लिए उन्हें टिप्पणियों से भी जोड़ सकते हैं।

GET /api/v1/question-results 
यह रूट एक बार में 1000 तक QuestionResults ऑब्जेक्ट लौटाता है, पृष्ठांकित (paginated) रूप में। प्रत्येक 100 ऑब्जेक्ट पर लागत 1 है। इन्हें createdAt के अनुसार आरोही क्रम में सॉर्ट किया जाता है। आप विभिन्न पैरामीटर के आधार पर फ़िल्टर कर सकते हैं।



GET /api/v1/question-results/:id 
यह रूट अपनी id द्वारा एकल QuestionResult लौटाता है।



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 
यहीं पर परिणामों का समुच्चयन (aggregation) होता है।
समुच्चयन प्रतिक्रिया की संरचना इस प्रकार है:

समुच्चयन के लिए उपलब्ध क्वेरी पैरामीटर यहाँ दिए गए हैं:

एक उदाहरण रिक्वेस्ट यहाँ है:

उदाहरण प्रतिक्रिया:


परफ़ॉर्मेंस नोट्स
- कैश मिस की स्थिति में समुच्चयन में आमतौर पर प्रति मिलियन परिणाम पाँच सेकंड लगते हैं।
- अन्यथा, रिक्वेस्ट स्थिर-समय (constant-time) में होती हैं।
कैशिंग और लागत नोट्स
- जब
forceRecalculateनिर्दिष्ट किया जाता है, तो लागत सामान्य2के बजाय हमेशा10होती है। - यदि कैश समाप्त हो जाता है और डेटा पुनः गणना किया जाता है, तो भी लागत एक स्थिर
2रहती है यदिforceRecalculateनिर्दिष्ट नहीं किया गया है। कैश समुच्चयित किए गए डेटा सेट के आकार के आधार पर समाप्त होता है (30 सेकंड से 5 मिनट के बीच भिन्न हो सकता है)। - यह कैश के उपयोग को प्रोत्साहित करने के लिए है।
GET /api/v1/question-results-aggregate/combine/comments 
यहीं पर परिणामों और टिप्पणियों का संयोजन होता है। उदाहरण के लिए, किसी उत्पाद के लिए "हाल की सकारात्मक और नकारात्मक टिप्पणियों" का चार्ट बनाने के लिए उपयोगी।
आप मानों की एक श्रेणी (समावेशी), एक या अधिक प्रश्नों, और एक प्रारंभ तिथि (समावेशी) के आधार पर खोज कर सकते हैं।
प्रतिक्रिया की संरचना इस प्रकार है:

एग्रीगेशन के लिए उपलब्ध क्वेरी पैरामीटर यहाँ दिए गए हैं:

एक उदाहरण रिक्वेस्ट यहाँ है:

उदाहरण प्रतिक्रिया:


कैशिंग और लागत संबंधी नोट्स
- जब
forceRecalculateनिर्दिष्ट किया जाता है, तो लागत सामान्य2के बजाय हमेशा10होती है। - यदि कैश समाप्त हो जाता है और डेटा पुनर्गणना की जाती है, तो भी लागत स्थिर
2रहती है यदिforceRecalculateनिर्दिष्ट नहीं किया गया हो। - यह कैश के उपयोग को प्रोत्साहित करने के लिए है।
UserBadge संरचना 
UserBadge एक ऑब्जेक्ट है जो FastComments सिस्टम में किसी उपयोगकर्ता को सौंपे गए बैज को दर्शाता है।
बैज उपयोगकर्ताओं को उनकी गतिविधि (जैसे कमेंट संख्या, रिप्लाई समय, वेटेरन स्थिति) के आधार पर स्वचालित रूप से या साइट व्यवस्थापकों द्वारा मैन्युअल रूप से सौंपे जा सकते हैं।
UserBadge ऑब्जेक्ट की संरचना इस प्रकार है:

GET /api/v1/user-badges 
यह एंडपॉइंट आपको विभिन्न मानदंडों के आधार पर यूज़र बैज प्राप्त करने की सुविधा देता है।
उदाहरण रिक्वेस्ट:
Run 
आप परिणामों को फ़िल्टर करने के लिए विभिन्न क्वेरी पैरामीटर जोड़ सकते हैं:
userId- किसी विशिष्ट यूज़र के बैज प्राप्त करेंbadgeId- किसी विशिष्ट बैज के इंस्टेंस प्राप्त करेंtype- बैज टाइप के अनुसार फ़िल्टर करें (0=CommentCount, 1=CommentUpVotes, 2=CommentReplies, आदि। पूरी सूची के लिए UserBadge संरचना देखें)displayedOnComments- बैज कमेंट्स पर दिखाया जाता है या नहीं, इसके अनुसार फ़िल्टर करें (true/false)limit- लौटाए जाने वाले बैज की अधिकतम संख्या (डिफ़ॉल्ट 30, अधिकतम 200)skip- छोड़े जाने वाले बैज की संख्या (पेजिनेशन के लिए)
उदाहरण रिस्पॉन्स:

संभावित त्रुटि रिस्पॉन्स:


GET /api/v1/user-badges/:id 
यह एंडपॉइंट आपको अपनी अद्वितीय ID द्वारा एक विशिष्ट यूज़र बैज प्राप्त करने की अनुमति देता है।
उदाहरण रिक्वेस्ट:
Run 
उदाहरण रिस्पॉन्स:

संभावित त्रुटि रिस्पॉन्स:


POST /api/v1/user-badges 
यह एंडपॉइंट आपको एक नया यूज़र बैज असाइनमेंट बनाने की अनुमति देता है।
अनुरोध उदाहरण:
Run 
अनुरोध बॉडी में निम्नलिखित पैरामीटर होने चाहिए:
userId(आवश्यक) - उस यूज़र की ID जिसे बैज असाइन किया जाना हैbadgeId(आवश्यक) - असाइन किए जाने वाले बैज की IDdisplayedOnComments(वैकल्पिक) - क्या बैज यूज़र की टिप्पणियों पर प्रदर्शित होना चाहिए (डिफ़ॉल्ट true)
महत्वपूर्ण नोट्स:
- बैज आपके टेनेंट के बैज कैटलॉग में मौजूद और सक्रिय होना चाहिए
- आप केवल उन यूज़र्स को बैज असाइन कर सकते हैं जो आपके टेनेंट से संबंधित हैं या जिन्होंने आपकी साइट पर टिप्पणी की है
प्रतिक्रिया उदाहरण:

संभावित त्रुटि प्रतिक्रियाएँ:





PUT /api/v1/user-badges/:id 
यह एंडपॉइंट आपको यूज़र बैज असाइनमेंट अपडेट करने की अनुमति देता है।
वर्तमान में, केवल displayedOnComments प्रॉपर्टी अपडेट की जा सकती है, जो यह नियंत्रित करती है कि बैज यूज़र की कमेंट्स पर दिखाया जाए या नहीं।
उदाहरण रिक्वेस्ट:
Run 
उदाहरण रिस्पॉन्स:

संभावित एरर रिस्पॉन्स:



DELETE /api/v1/user-badges/:id 
यह एंडपॉइंट आपको एक यूज़र बैज असाइनमेंट डिलीट करने की सुविधा देता है।
उदाहरण रिक्वेस्ट:
Run 
उदाहरण रिस्पॉन्स:

संभावित एरर रिस्पॉन्स:



UserBadgeProgress संरचना 
UserBadgeProgress एक ऑब्जेक्ट है जो FastComments सिस्टम में विभिन्न बैज अर्जित करने की दिशा में उपयोगकर्ता की प्रगति को दर्शाता है।
यह ट्रैकिंग यह निर्धारित करने में मदद करती है कि उपयोगकर्ताओं को आपके समुदाय में उनकी गतिविधि और भागीदारी के आधार पर स्वचालित बैज कब प्राप्त होने चाहिए।
UserBadgeProgress ऑब्जेक्ट की संरचना इस प्रकार है:

GET /api/v1/user-badge-progress 
यह एंडपॉइंट आपको विभिन्न मानदंडों के आधार पर यूज़र बैज प्रोग्रेस रिकॉर्ड्स प्राप्त करने की अनुमति देता है।
उदाहरण रिक्वेस्ट:
Run 
आप परिणामों को फ़िल्टर करने के लिए विभिन्न क्वेरी पैरामीटर जोड़ सकते हैं:
userId- किसी विशिष्ट यूज़र की प्रोग्रेस प्राप्त करेंlimit- लौटाए जाने वाले रिकॉर्ड्स की अधिकतम संख्या (डिफ़ॉल्ट 30, अधिकतम 200)skip- छोड़े जाने वाले रिकॉर्ड्स की संख्या (पेजिनेशन के लिए)
उदाहरण रिस्पॉन्स:

संभावित त्रुटि रिस्पॉन्स:


GET /api/v1/user-badge-progress/:id 
यह एंडपॉइंट आपको अपनी यूनिक ID द्वारा किसी विशिष्ट यूज़र बैज प्रोग्रेस रिकॉर्ड को फ़ेच करने की अनुमति देता है।
उदाहरण रिक्वेस्ट:
Run 
उदाहरण रिस्पॉन्स:

संभावित त्रुटि रिस्पॉन्स:


GET /api/v1/user-badge-progress/user/:userId 
यह एंडपॉइंट आपको यूज़र ID द्वारा किसी यूज़र का बैज प्रोग्रेस रिकॉर्ड प्राप्त करने की अनुमति देता है।
उदाहरण रिक्वेस्ट:
Run 
उदाहरण रिस्पॉन्स:

संभावित एरर रिस्पॉन्स:



निष्कर्ष में
हमें उम्मीद है कि आपको हमारा API दस्तावेज़ीकरण विस्तृत और समझने में आसान लगा होगा। यदि आपको कोई कमी मिलती है, तो हमें नीचे बताएं।