अकाउंट एक्टिविटी API: Enterprise

इस endpoint को पोस्ट edit metadata शामिल करने के लिए अपडेट किया गया है। इस metadata के बारे में अधिक जानने के लिए “पोस्ट्स संपादित करें” के मूलभूत सिद्धांत पेज देखें। इस endpoint का उपयोग अक्सर Direct Messages endpoints के साथ किया जाता है। हमने नए v2 Direct Messages endpoints लॉन्च किए हैं। ध्यान दें कि Enterprise और Premium Account Activity APIs, v2 one-to-one messages का समर्थन करते हैं, लेकिन अभी तक group conversations का समर्थन नहीं करते हैं।

अवलोकन Enterprise Account Activity API आपको webhooks के ज़रिए किसी उपयोगकर्ता खाते से संबंधित realtime गतिविधियों की सदस्यता लेने की सुविधा देता है। इसका अर्थ है कि आप एक ही कनेक्शन के माध्यम से अपने एक या अधिक स्वामित्व वाले या subscribed खातों से realtime पोस्ट्स, Direct Messages और अन्य खाता events प्राप्त कर सकते हैं। आपको अपने webhook registration पर प्रत्येक उपयोगकर्ता subscription के लिए नीचे दी गई सभी संबंधित गतिविधियां प्राप्त होंगी:

गतिविधि प्रकार
* पोस्ट्स (उपयोगकर्ता द्वारा) * पोस्ट deletion (उपयोगकर्ता द्वारा) * @mentions (उपयोगकर्ता के) * जवाब (उपयोगकर्ता को या उपयोगकर्ता से) * Retweets (उपयोगकर्ता द्वारा या उपयोगकर्ता के) * Quote Tweets (उपयोगकर्ता द्वारा या उपयोगकर्ता के) * Quoted Tweets के Retweets (उपयोगकर्ता द्वारा या उपयोगकर्ता के) * Likes (उपयोगकर्ता द्वारा या उपयोगकर्ता के) * Follows (उपयोगकर्ता द्वारा या उपयोगकर्ता के) * Unfollows (उपयोगकर्ता द्वारा)	* Blocks (उपयोगकर्ता द्वारा) * Unblocks (उपयोगकर्ता द्वारा) * Mutes (उपयोगकर्ता द्वारा) * Unmutes (उपयोगकर्ता द्वारा) * भेजे गए Direct Messages (उपयोगकर्ता द्वारा) * प्राप्त Direct Messages (उपयोगकर्ता द्वारा) * Typing indicators (उपयोगकर्ता को) * Read receipts (उपयोगकर्ता को) * Subscription revokes (उपयोगकर्ता द्वारा)

कृपया ध्यान दें - हम Account Activity API के माध्यम से home timeline data उपलब्ध नहीं कराते हैं। इस डेटा को प्राप्त करने के लिए कृपया GET statuses/home_timeline का उपयोग करें।

वीडियो श्रृंखला

Account Activity API के बारे में जल्दी से जानकारी पाने के लिए हमारी चार-भाग वाली वीडियो श्रृंखला देखें!

सुविधा सारांश

स्तर	मूल्य	अद्वितीय सदस्यताओं की संख्या	वेबहुक की संख्या	विश्वसनीयता और गतिविधि रिकवरी
Enterprise	सेल्स से संपर्क करें	500+ तक	3+	पुनर्प्रयास और Replay

कोई प्रश्न हैं? त्रुटियाँ आ रही हैं?
- हमारे अक्सर पूछे जाने वाले प्रश्न या त्रुटि समस्या-निवारण मार्गदर्शिका पढ़ें.
हमारा सैंपल कोड देखें:
- Enterprise Account Activity API डैशबोर्ड, एक Node वेब ऐप जो Account Activity API के Enterprise स्तर का उपयोग करके वेबहुक इवेंट दिखाता है और इसमें Replay की कार्यक्षमता भी शामिल है।
- SnowBot chatbot, Enterprise Account Activity और Direct Message APIs पर बना एक Ruby वेब ऐप।

वेबहुक और सब्स्क्राइब किए गए उपयोगकर्ताओं को प्रबंधित करें

⏱ 10 मिनट का पठन Enterprise Account Activity API आपकी सेवा को सब्स्क्राइब किए गए X खातों से जुड़ी कोई भी घटना होने पर वेबहुक-आधारित JSON संदेश भेजता है। X उन गतिविधियों को आपके पंजीकृत वेबहुक पर डिलीवर करता है। अगले चरणों में, आप जानेंगे कि वेबहुक और सब्स्क्राइब किए गए उपयोगकर्ताओं को कैसे प्रबंधित किया जाता है। आप सीखेंगे कि वेबहुक और सब्स्क्राइब किए गए उपयोगकर्ताओं, दोनों को कैसे रजिस्टर करें, देखें और हटाएँ। अलग-अलग API endpoints पर अनुरोध करने के लिए हम सरल cURL कमांड का उपयोग करेंगे। cURL, URL सिंटैक्स का उपयोग करके अनुरोध प्राप्त करने या भेजने के लिए एक कमांड-लाइन टूल है। आपको इनकी आवश्यकता होगी:

एक पंजीकृत X ऐप - यहाँ रजिस्टर करें
एक बेयरर टोकन - और जानें
ऐसा वेबहुक जो Challenge-Response Check (CRC) पास करता हो - और जानें
एक Enterprise खाता - [यहाँ आवेदन करें]https://developer.x.com/en/products/x-api/enterprise

शुरू करने से पहले, हम सुझाव देते हैं कि आप हमारा GitHub repo यहाँ देखें, जिसमें X के Account Activity API के साथ शुरुआत करने के लिए एक सैंपल वेब ऐप और सहायक स्क्रिप्ट दी गई हैं

वेबहुक का प्रबंधन:

वेबहुक का उपयोग करने से आप एक ही कनेक्शन के माध्यम से किसी उपयोगकर्ता खाते से संबंधित रीयल-टाइम गतिविधियों की सदस्यता ले सकते हैं।

वेबहुक जोड़ना
वेबहुक देखना
वेबहुक हटाना

आइए, दिए गए ऐप संदर्भ के लिए एक नया वेबहुक URL पंजीकृत करके शुरू करें।सहेजने से पहले URL को CRC अनुरोध के माध्यम से सत्यापित किया जाएगा। वेबहुक पंजीकृत करने के बाद, उसकी ID नोट कर लें, क्योंकि बाद में इसकी आवश्यकता होगी।निम्नलिखित में बदलाव करने के बाद, नीचे दिया गया cURL अनुरोध अपनी कमांड लाइन में कॉपी करें:

URL <URL> उदा. https://yourdomain.com/webhooks/twitter/
Consumer key <CONSUMER_KEY> उदा. xvz1evFS4wEEPTGEFPHBog

Access token <ACCESS_TOKEN> उदा. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb

curl --request POST --url 'https://api.x.com/1.1/account_activity/webhooks.json?url=<URL>' --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<ACCESS_TOKEN>", oauth_version="1.0"'

दिए गए ऐप के लिए सभी पंजीकृत वेबहुक URL और उनकी स्थिति देखने के लिए, हम निम्न कमांड चलाएँगे।निम्नलिखित में बदलाव करने के बाद, नीचे दिया गया cURL अनुरोध अपनी कमांड लाइन में कॉपी करें:

बेयरर टोकन <BEARER_TOKEN> उदा. AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...
--request GET --url https://api.x.com/1.1/account_activity/webhooks.json --header

दिए गए ऐप के कॉन्फ़िगरेशन से वेबहुक हटाने के लिए, निम्नलिखित में बदलाव करने के बाद नीचे दिया गया cURL अनुरोध अपनी कमांड लाइन में कॉपी करें:

Webhook ID <:WEBHOOK_ID> उदा. 1234567890
Consumer key <CONSUMER_KEY> उदा. xvz1evFS4wEEPTGEFPHBog
Access token <ACCESS_TOKEN> उदा. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
--request DELETE --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>.json --header

सब्सक्राइब किए गए उपयोगकर्ताओं का प्रबंधन:

वेबहुक रजिस्टर करने के बाद, आप किसी सब्सक्राइब किए गए उपयोगकर्ता को Account Activity API में जोड़ सकते हैं, ताकि उसकी खाता गतिविधियां मिलनी शुरू हो जाएं।

सदस्यता जोड़ना
सदस्यताएँ देखना
सदस्यता हटाना

हम शुरुआत किसी उपयोगकर्ता को सब्सक्राइब करने से करेंगे, ताकि आपको सभी इवेंट प्रकार प्राप्त हों।निम्नलिखित मानों में बदलाव करने के बाद, नीचे दिए गए cURL अनुरोध को अपनी कमांड लाइन में कॉपी करें:

Webhook ID <:WEBHOOK_ID> उदा. 1234567890
Consumer key name <CONSUMER_KEY> उदा. xvz1evFS4wEEPTGEFPHBog

सब्सक्राइब करने वाले उपयोगकर्ता का access token <SUBSCRIBING_USER'S_ACCESS_TOKEN> उदा. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb

curl --request POST --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>/subscriptions/all.json --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<SUBSCRIBING_USER'S_ACCESS_TOKEN>", oauth_version="1.0"'

किसी निर्दिष्ट वेबहुक के लिए सभी गतिविधि-प्रकार सदस्यताओं की सूची देखने हेतु, निम्नलिखित मानों में बदलाव करने के बाद नीचे दिए गए cURL अनुरोध को अपनी कमांड लाइन में कॉपी करें:

Webhook ID <:WEBHOOK_ID> उदा. 1234567890

बेयरर टोकन <BEARER_TOKEN> उदा. AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...

curl --request GET --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>/subscriptions/all/list.json --header 'authorization: Bearer <BEARER_TOKEN>'

निष्क्रिय करने के बाद, अनुरोध करने वाले उपयोगकर्ता के लिए सभी इवेंट अब वेबहुक URL पर नहीं भेजे जाएंगे।दिए गए उपयोगकर्ता context और ऐप से किसी सदस्यता को निष्क्रिय करने के लिए, निम्नलिखित मानों में बदलाव करने के बाद नीचे दिए गए cURL अनुरोध को अपनी कमांड लाइन में कॉपी करें:

Webhook ID <:WEBHOOK_ID> उदा. 1234567890
Consumer key <CONSUMER_KEY> उदा. xvz1evFS4wEEPTGEFPHBog

curl --request DELETE --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBED_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

बहुत बढ़िया! अब आप अपने वेबहुक और सब्सक्राइब किए गए उपयोगकर्ताओं का प्रबंधन कर सकेंगे।

संदर्भित लेख

Challenge-Response Check (CRC) का अवलोकन
[Account Activity डेटा types](/x-api/enterprise-gnip-2.0/fundamentals/account-activity#account-activity-data-object-structure
वेबहुक और Subscriptions को प्रबंधित करना

Account Activity API का वीडियो वॉकथ्रू

इस वीडियो वॉकथ्रू में, आप Account Activity API के premium और enterprise tiers की क्षमताओं के बारे में जानेंगे। इस वीडियो के अंत तक, आप निम्नलिखित क्षमताओं के बारे में जान चुके होंगे।

वेबहुक पंजीकृत करना
user subscription जोड़ना
user subscription हटाना
account activities प्राप्त करना
account activities को replay करना

कोई सवाल हैं? त्रुटियाँ आ रही हैं?
- हमारे अक्सर पूछे जाने वाले सवाल या त्रुटि समस्या-निवारण मार्गदर्शिका पढ़ें.
हमारा नमूना कोड देखें:
- Enterprise Account Activity API dashboard, एक Node वेब ऐप जो Account Activity API के Enterprise tier का उपयोग करके webhook इवेंट दिखाता है और इसमें Replay की कार्यक्षमता भी शामिल है।
- SnowBot chatbot, एक Ruby वेब ऐप है, जिसे Enterprise Account Activity और Direct Message APIs पर बनाया गया है।

Enterprise

वेबहुक्स के साथ शुरुआत करना

Account Activity API एक वेबहुक-आधारित API है, जो अकाउंट इवेंट्स उस वेब ऐप पर भेजती है जिसे आप विकसित, डिप्लॉय और होस्ट करते हैं। आपके इवेंट कंज़्यूमर ऐप्लिकेशन में वेबहुक इवेंट्स मिलना शुरू होने से पहले कई ‘बुनियादी सेटअप’ संबंधी विवरणों पर ध्यान देना ज़रूरी है। जैसा कि नीचे बताया गया है, आपको एक X ऐप बनाना होगा, Account Activity API का एक्सेस प्राप्त करना होगा, और एक ऐसा वेब ऐप विकसित करना होगा जो वेबहुक इवेंट्स को कंज़्यूम करे।

1. एक X ऐप बनाएँ।

स्वीकृत डेवलपर खाते के साथ डेवलपर कंसोल में एक X ऐप बनाएँ। अगर आप अपनी कंपनी की ओर से ऐप बना रहे हैं, तो सुझाव है कि आप इसे किसी कॉर्पोरेट X खाते से बनाएँ। डेवलपर खाते के लिए आवेदन करने हेतु, यहाँ क्लिक करें।
अपने ऐप पेज के permissions टैब में “Read, Write and Access direct messages” सक्षम करें।
“Keys and Access Tokens” टैब में अपने ऐप की Consumer Key (API Key) और Consumer Token (API Secret) नोट कर लें।
इसी टैब में अपने ऐप के Access Token and Access Token Secret जनरेट करें। अपने webhook URL को रजिस्टर करने के लिए आपको इन Access Tokens की आवश्यकता होगी, जहाँ X अकाउंट इवेंट भेजेगा।
अगर आप X Sign-in और X API के साथ user context के काम करने के तरीके से परिचित नहीं हैं, तो Obtaining Access Tokens देखें। जिन खातों के लिए आप इवेंट प्राप्त करना चाहते हैं, उन्हें जोड़ते समय आप उस खाते के access tokens का उपयोग करके उन्हें subscribe करेंगे।
अपने ऐप की संख्यात्मक ID नोट कर लें, जैसा कि डेवलपर कंसोल के “Apps” पेज पर दिखाई देता है। Account Activity API access के लिए आवेदन करते समय, आपको इस app ID की आवश्यकता होगी।

2. Account Activity API एक्सेस प्राप्त करें

X ऐप बनाने के बाद, अगला चरण Account Activity API एक्सेस के लिए आवेदन करना है। Account Activity API केवल Enterprise पर उपलब्ध है, इसलिए आपको नीचे दिए गए लिंक का उपयोग करके आवेदन सबमिट करना होगा।

3. वेबहुक कंज़्यूमर ऐप विकसित करें

जब आपको Account Activity API का एक्सेस मिल जाए, तो आपको एक वेब ऐप विकसित, डिप्लॉय और होस्ट करना होगा, जो X वेबहुक इवेंट प्राप्त करेगा।

इवेंट प्राप्त करने के लिए अपने वेबहुक के रूप में इस्तेमाल करने हेतु URL वाला एक वेब ऐप बनाएं। यह आपके सर्वर पर डिप्लॉय किया गया endpoint है, जो आने वाले X वेबहुक इवेंट को सुनता है।
- URI path पूरी तरह आपकी पसंद पर निर्भर करता है। उदाहरण के लिए, यह मान्य होगा: https://mydomain.com_/service/listen_
- अगर आप कई स्रोतों से आने वाले वेबहुक सुन रहे हैं, तो एक सामान्य पैटर्न यह है: https://mydomain.com/webhook/twitter
- ध्यान दें कि दिए गए URL में port specification शामिल नहीं हो सकती (https://mydomain.com:5000/NoWorkie).
जैसा कि हमारी Securing Webhooks गाइड में बताया गया है, पहला कदम ऐसा कोड लिखना है जो X Challenge Response Check (CRC) GET अनुरोध प्राप्त करे और सही फ़ॉर्मैट में JSON रिस्पॉन्स लौटाए।
अपना वेबहुक URL रजिस्टर करें। आप /webhooks.json?url= endpoint पर एक POST अनुरोध करेंगे। जब आप यह अनुरोध करेंगे, तो X आपके वेब ऐप को एक CRC अनुरोध भेजेगा। जब कोई वेबहुक सफलतापूर्वक रजिस्टर हो जाता है, तो रिस्पॉन्स में एक वेबहुक id शामिल होगा। बाद में Account Activity API के कुछ अनुरोध करते समय इस वेबहुक id की आवश्यकता पड़ेगी।
X आपके द्वारा रजिस्टर किए गए URL पर account वेबहुक इवेंट भेजेगा। सुनिश्चित करें कि आपका वेब ऐप आने वाले इवेंट के लिए POST अनुरोधों को सपोर्ट करता है। ये इवेंट JSON में एन्कोड किए जाएंगे। उदाहरण वेबहुक JSON payloads के लिए HERE देखें।
आपका वेब ऐप तैयार हो जाने के बाद, अगला कदम उन accounts को जोड़ना है जिनके लिए गतिविधियां प्राप्त करनी हैं। accounts जोड़ते समय (या हटाते समय) आप account id का संदर्भ देते हुए POST अनुरोध करेंगे। अधिक जानकारी के लिए हमारी guide on adding subscriptions देखें।

4. सेटअप सत्यापित करें

यह सत्यापित करने के लिए कि आपका ऐप और वेबहुक सही तरीके से कॉन्फ़िगर किए गए हैं, उन X खातों में से किसी एक द्वारा किए गए किसी पोस्ट को पसंद करें जिनकी सदस्यता आपके ऐप ने ली है। आपके सब्सक्राइबर को मिलने वाले प्रत्येक Favorite के लिए आपको अपने वेबहुक URL पर POST अनुरोध के माध्यम से एक favorite_events मिलना चाहिए।
ध्यान दें कि सदस्यता जोड़े जाने के बाद इवेंट डिलीवर होना शुरू होने में 10 सेकंड तक लग सकते हैं।

महत्वपूर्ण नोट्स

अपना वेबहुक URL रजिस्टर करते समय, आपके वेब ऐप को अपने consumer token और secret साथ ही ऐप के मालिक के user access token और secret के साथ प्रमाणित होना चाहिए।
सभी आने वाले Direct Messages वेबहुक के माध्यम से डिलीवर किए जाएंगे। POST direct_messages/events/new (message_create) के माध्यम से भेजे गए सभी Direct Messages भी वेबहुक के माध्यम से डिलीवर किए जाएंगे। ऐसा इसलिए है ताकि आपका वेब ऐप किसी दूसरे client के माध्यम से भेजे गए Direct Messages से अवगत रह सके।
ध्यान दें कि हर वेबहुक इवेंट में एक for_user_id user ID शामिल होती है, जो यह बताती है कि इवेंट किस सदस्यता के लिए डिलीवर किया गया था।
यदि एक ही बातचीत में दो उपयोगकर्ता Direct Messages के लिए आपके वेब ऐप का उपयोग कर रहे हैं, तो आपके वेबहुक को दो डुप्लिकेट इवेंट प्राप्त होंगे (प्रत्येक उपयोगकर्ता के लिए एक)। आपके वेब ऐप को इसे ध्यान में रखना चाहिए।
यदि एक से अधिक वेब ऐप एक ही वेबहुक URL साझा कर रहे हैं और प्रत्येक ऐप से वही उपयोगकर्ता मैप किया गया है, तो वही इवेंट आपके वेबहुक को कई बार भेजा जाएगा (प्रत्येक वेब ऐप के लिए एक बार)।
कुछ मामलों में, आपके वेबहुक को डुप्लिकेट इवेंट मिल सकते हैं। आपके वेबहुक ऐप को इसके प्रति सहनशील होना चाहिए और इवेंट ID के आधार पर डुप्लिकेट हटाने चाहिए।
यह अपेक्षा न करें कि Quick Reply का रिस्पॉन्स किसी अनुरोध के तुरंत बाद आएगा। उपयोगकर्ता Quick Reply अनुरोध को अनदेखा कर सकता है और पारंपरिक Direct Message के माध्यम से जवाब दे सकता है। उपयोगकर्ता संदेश थ्रेड में किसी ऐसे अनुरोध के लिए भी Quick Reply रिस्पॉन्स दे सकता है, जिसका उसने पहले उत्तर नहीं दिया हो。
उदाहरण कोड देखें:
- Enterprise Account Activity API डैशबोर्ड, एक node वेब ऐप जो Account Activity API के enterprise tier का उपयोग करके वेबहुक इवेंट दिखाता है और इसमें Replay कार्यक्षमता भी शामिल है।
- SnowBot chatbot, एक Ruby वेब ऐप जो Account Activity और Direct Message APIs पर बनाया गया है। इस code base में Account Activity API वेबहुक सेट अप करने में मदद के लिए एक script शामिल है।

वेबहुक को सुरक्षित बनाना

X के वेबहुक-आधारित API आपके वेबहुक सर्वर की सुरक्षा की पुष्टि करने के लिए दो तरीके प्रदान करते हैं:

चैलेंज-रिस्पॉन्स जाँचें X को उस वेब ऐप के स्वामित्व की पुष्टि करने में सक्षम बनाती हैं, जो वेबहुक इवेंट प्राप्त कर रहा है।
प्रत्येक POST अनुरोध में मौजूद सिग्नेचर हेडर आपको यह पुष्टि करने में सक्षम बनाता है कि आने वाले वेबहुक का स्रोत X ही है।

Challenge-Response Checks

यह सत्यापित करने के लिए कि आप ऐप और वेबहुक URL, दोनों के स्वामी हैं, X एक Challenge-Response Check (CRC) करेगा, जिसे cyclic redundancy check के साथ भ्रमित नहीं किया जाना चाहिए। जब CRC भेजा जाता है, तो X आपके web app को ;crc_token पैरामीटर के साथ एक GET अनुरोध भेजेगा। यह अनुरोध प्राप्त होने पर, आपके web app को crc_token पैरामीटर और आपके ऐप के Consumer Secret (विवरण नीचे) के आधार पर एक एन्क्रिप्टेड response_token बनाना होगा। response_token को JSON में एन्कोड किया जाना चाहिए (नीचे उदाहरण देखें) और तीन सेकंड के भीतर लौटाया जाना चाहिए। सफल होने पर, एक वेबहुक id लौटाया जाएगा। जब आप अपना वेबहुक URL पंजीकृत करते हैं, तब एक CRC भेजा जाएगा, इसलिए अपने CRC रिस्पॉन्स कोड को लागू करना एक बुनियादी पहला कदम है। एक बार आपका वेबहुक स्थापित हो जाने पर, X हमारे द्वारा अंतिम सफल रिस्पॉन्स प्राप्त करने के समय से लगभग हर 24 घंटे में CRC ट्रिगर करेगा। आवश्यकता पड़ने पर आपका ऐप अपने वेबहुक id के साथ PUT अनुरोध भेजकर भी CRC ट्रिगर कर सकता है। CRC ट्रिगर करना आपके वेबहुक application को विकसित करते समय, नया कोड परिनियोजित करने के बाद, और अपनी सेवा को पुनः आरंभ करने के बाद उपयोगी होता है। आने वाले हर CRC अनुरोध के लिए crc_token के बदलने की अपेक्षा की जानी चाहिए, और गणना में इसे संदेश के रूप में इस्तेमाल किया जाना चाहिए, जहाँ आपका Consumer Secret कुंजी होता है। यदि रिस्पॉन्स 3 सेकंड के भीतर पोस्ट नहीं किया जाता है या अमान्य हो जाता है, तो पंजीकृत वेबहुक पर ईवेंट भेजे जाना बंद हो जाएगा।

CRC अनुरोध इन स्थितियों में होगा:

जब कोई वेबहुक URL पंजीकृत किया जाता है।
आपके वेबहुक URL को सत्यापित करने के लिए लगभग हर घंटे।
आप PUT अनुरोध करके CRC को मैन्युअल रूप से ट्रिगर कर सकते हैं। जैसे-जैसे आप अपना वेबहुक क्लाइंट विकसित करते हैं, वैसे-वैसे CRC रिस्पॉन्स विकसित करते समय CRC को मैन्युअल रूप से ट्रिगर करने की योजना बनानी चाहिए।

रिस्पॉन्स आवश्यकताएँ:

crc_token और आपके ऐप के Consumer Secret से बनाया गया base64-एन्कोडेड HMAC SHA-256 हैश
मान्य response_token और JSON फ़ॉर्मैट।
3 सेकंड से कम विलंबता।
200 HTTP रिस्पॉन्स कोड।

भाषा के अनुसार HMAC लाइब्रेरी:

Python में उदाहरण रिस्पॉन्स टोकन जनरेशन:

निम्नलिखित Python 2.7 Flask webapp में एक route परिभाषित करता है, जो challenge response check का सही ढंग से रिस्पॉन्स देगा।

import base64
import hashlib
import hmac
import json


\# GET अनुरोध के लिए एक रूट परिभाषित करता है
@app.route('/webhooks/twitter', methods=\['GET'\])
def webhook_challenge():

  # आने वाले टोकन और आपके consumer secret से HMAC SHA-256 हैश बनाता है
  sha256\_hash\_digest = hmac.new(TWITTER\_CONSUMER\_SECRET, msg=request.args.get('crc_token'), digestmod=hashlib.sha256).digest()

  # base64 एन्कोडेड हैश के साथ रिस्पॉन्स डेटा तैयार करता है
  response = {
    'response\_token': 'sha256=' + base64.b64encode(sha256\_hash_digest)
  }

  # सही तरीके से फ़ॉर्मेट किया गया json रिस्पॉन्स रिटर्न करता है
  return json.dumps(response)

उदाहरण JSON रिस्पॉन्स:

ऊपर बताए अनुसार route परिभाषित होने पर, अपने वेब ब्राउज़र में https://your-app-domain/webhooks/twitter?crc_token=foo पर जाने पर आपका webapp नीचे दिए गए जैसा एक रिस्पॉन्स लौटाना चाहिए।

{
  "response_token": "sha256=x0mYd8hz2goCTfcNAaMqENy2BFgJJfJOb4PdvTffpwg="
}

अन्य उदाहरण:

यहाँ Node/JS में लिखी गई CRC रिस्पॉन्स मेथड का एक उदाहरण है।
यहाँ Ruby में लिखी गई CRC रिस्पॉन्स मेथड का एक उदाहरण है (generate_crc_response और CRC ईवेंट प्राप्त करने वाला /GET रूट देखें)।

वैकल्पिक सिग्नेचर हेडर सत्यापन

जब X से कोई POST अनुरोध प्राप्त होता है, webhook बनाने के लिए GET अनुरोध भेजा जाता है, या मैन्युअल CRC करने के लिए GET अनुरोध भेजा जाता है, तो हेडर में x-twitter-webhooks-signature के रूप में एक हैश सिग्नेचर भेजा जाता है। इस सिग्नेचर का उपयोग यह सत्यापित करने के लिए किया जा सकता है कि डेटा का स्रोत X है। POST हैश सिग्नेचर sha256= से शुरू होता है, जो यह दर्शाता है कि आपके X ऐप Consumer Secret और payload को एन्क्रिप्ट करने के लिए HMAC SHA-256 का उपयोग किया गया है। GET हैश की गणना query parameter string crc_token=

token&amp;nonce=

nonce से की जाती है। किसी अनुरोध को सत्यापित करने के चरण

अपने consumer secret और आने वाली payload body का उपयोग करके एक hash बनाएं।
बनाए गए hash की तुलना base64-encoded x-twitter-webhooks-signature मान से करें। timing attack के जोखिम को कम करने के लिए compare_digest जैसी विधि का उपयोग करें।

अतिरिक्त सुरक्षा दिशानिर्देश

आपके वेब अनुप्रयोग के लिए ध्यान में रखने योग्य कुछ अतिरिक्त सुरक्षा दिशानिर्देश नीचे दिए गए हैं। इन दिशानिर्देशों को लागू न करने पर भी आपका webhook काम करना बंद नहीं करेगा, लेकिन X Information Security टीम इन्हें दृढ़ता से अनुशंसित करती है। यदि आप नीचे दी गई सिफारिशों से परिचित नहीं हैं, तो अपने सर्वर प्रशासक से परामर्श करें।

X समेकित नेटवर्क ब्लॉक

अतिरिक्त सुरक्षा के लिए, आप निम्नलिखित समेकित नेटवर्क ब्लॉकों को अनुमति सूची में जोड़ सकते हैं:

199.59.148.0/22
199.16.156.0/22
192.133.77.0/26
64.63.15.0/24
64.63.31.0/24
64.63.47.0/24
202.160.128.0/24
202.160.129.0/24
202.160.130.0/24

अनुशंसित सर्वर कॉन्फ़िगरेशन

ssllabs.com परीक्षण में “A” रेटिंग
TLS 1.2 सक्षम करें
Forward Secrecy सक्षम करें
SSLv2 बंद करें
SSLv3 बंद करें (POODLE के कारण)
TLS 1.0 बंद करें
TLS 1.1 बंद करें
TLS Compression बंद करें
Session Tickets बंद करें, जब तक कि आप session ticket keys को रोटेट नहीं करते।
SSL Configuration में “ssl_prefer_server_ciphers” या “SSLHonorCipherOrder” विकल्प को “on” पर सेट करें।
सुनिश्चित करें कि ciphers की सूची आधुनिक हो, जैसे: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA

webhook और सदस्यताओं का प्रबंधन

Webhook बनाना और बदलना

Webhook URL बदलने के लिए, आपको पहले अपना मौजूदा webhook हटाना होगा और फिर एक नया बनाना होगा। ध्यान दें कि ऐसा करने पर आपको नए webhook के लिए उपयोगकर्ता सदस्यताएँ फिर से जोड़नी होंगी।

Webhook कॉन्फ़िगरेशन प्रबंधन एंडपॉइंट:


Method	Enterprise
एक webhook URL पंजीकृत करता है / एक webhook_id जनरेट करता है	POST webhooks
सभी webhook URL और उनकी स्थिति लौटाता है	GET webhooks
ऐप का मौजूदा webhook कॉन्फ़िगरेशन हटाएँ	DELETE webhooks/:webhook_id
CRC अनुरोध को मैन्युअल रूप से ट्रिगर करें	PUT webhooks/:webhook_id

मैं webhook URL को सीधे अपडेट क्यों नहीं कर सकता?

webhook कॉन्फ़िगरेशन अपरिवर्तनीय क्यों हैं? X सुरक्षा को बहुत गंभीरता से लेता है। अगर आपका webhook URL बदल दिया जाता है, तो संभव है कि आपकी ऐप की consumer key और consumer secret से समझौता हो गया हो। जब आपसे नया webhook कॉन्फ़िगरेशन बनाने के लिए कहा जाता है, तो आपको अपने उपयोगकर्ता के इवेंट्स के लिए फिर से सदस्यता भी लेनी पड़ती है। इसके लिए access tokens का उपयोग करना आवश्यक होता है, जिनके किसी दुर्भावनापूर्ण पक्ष के पास होने की संभावना कम होती है। परिणामस्वरूप, इस बात की संभावना कम हो जाती है कि कोई अन्य पक्ष आपके उपयोगकर्ता की निजी जानकारी प्राप्त कर सके।

User सदस्यताएँ जोड़ना और हटाना

एंटरप्राइज़ टियर के साथ हज़ारों सदस्यताओं के लिए सहायता उपलब्ध है। यदि आपके पास पहले से कोई अकाउंट मैनेजर है, तो प्रश्नों के लिए कृपया उनसे संपर्क करें। एंटरप्राइज़ API की पहुँच के लिए आवेदन करने हेतु, यहाँ क्लिक करें.

सदस्यता प्रबंधन एंडपॉइंट्स


विधि	एंटरप्राइज़
नई उपयोगकर्ता सदस्यता जोड़ें	POST webhooks/:webhook_id/subscriptions/all
उपयोगकर्ता सदस्यता प्राप्त करें	GET webhooks/:webhook_id/subscriptions/all
सभी सक्रिय सदस्यताओं की सूची लौटाता है	GET webhooks/:webhook_id/subscriptions/all/list
केवल ऐप OAuth का उपयोग करके उपयोगकर्ता सदस्यता निष्क्रिय करता है	DELETE webhooks/:webhook_id/subscriptions/:user_id/all.json

Account Activity API: एंटरप्राइज़

कृपया ध्यान दें: API का उपयोग शुरू करने से पहले, X को आपके डेवलपर ऐप के लिए Account Activity API की पहुँच सक्षम करनी होगी। इसके लिए, यह सुनिश्चित करें कि आप प्रमाणीकरण के लिए जिस ऐप ID का उपयोग करना चाहते हैं, उसे अपने अकाउंट मैनेजर या तकनीकी सहायता टीम के साथ साझा करें।

Account Activity API एंडपॉइंट्स का एक समूह है, जो आपको एक ही कनेक्शन के माध्यम से अपने सभी सब्स्क्राइब किए गए अकाउंट्स की रीयल-टाइम अकाउंट गतिविधियाँ प्राप्त करने के लिए उपयोगकर्ता सदस्यताएँ बनाने और प्रबंधित करने की सुविधा देता है। Account Activity API के साथ दो प्रमाणीकरण विधियाँ उपलब्ध हैं (OAuth 1.0a और OAuth 2.0 बेयरर टोकन)। आपको कौन-सी प्रमाणीकरण विधि उपयोग करनी चाहिए, यह इस बात पर निर्भर करेगा कि आप कौन-सा एंडपॉइंट उपयोग कर रहे हैं।


विवरण	एंडपॉइंट	OAuth 1.0a (उपयोगकर्ता संदर्भ)	OAuth 2.0 बेयरर टोकन (केवल-ऐप)
दिए गए ऐप संदर्भ के लिए नया webhook URL रजिस्टर करें	POST account_activity/webhooks	✓
दिए गए ऐप के लिए सभी URL और उनकी स्थिति लौटाएँ	GET account_activity/webhooks		✓
दिए गए webhook के URL के लिए challenge response check (CRC) ट्रिगर करें	PUT account_activity/webhooks/:webhook_id	✓
ऐप को किसी उपयोगकर्ता के अकाउंट इवेंट्स के लिए सब्सक्राइब करें	POST account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
वर्तमान में सक्रिय सदस्यताओं की संख्या लौटाएँ	GET account_activity/subscriptions/count		✓
जाँचें कि कोई webhook कॉन्फ़िगरेशन किसी उपयोगकर्ता के इवेंट्स के लिए सब्सक्राइब है या नहीं	GET account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
वर्तमान में सक्रिय सदस्यताओं की सूची लौटाएँ	GET account_activity/webhooks/:webhook_id/subscriptions/all/list		✓
कोई webhook हटाएँ	DELETE account_activity/webhooks/:webhook_id	✓
[अप्रचलित] दिए गए उपयोगकर्ता संदर्भ और ऐप के लिए किसी सदस्यता को निष्क्रिय करें	DELETE account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
केवल-ऐप OAuth का उपयोग करके किसी सदस्यता को निष्क्रिय करें	DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json		✓
गतिविधियों को किसी webhook पर फिर से डिलीवर करता है	POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json		✓

*_ प्रमाणीकरण के लिए सब्सक्राइब करने वाले उपयोगकर्ता के access tokens आवश्यक हैं। _ जिन एंडपॉइंट्स के लिए OAuth 1.0a उपयोगकर्ता-संदर्भ प्रमाणीकरण आवश्यक है, उनमें अनुरोध को प्रमाणित करने के लिए आपको निम्नलिखित क्रेडेंशियल देने होंगे:

Consumer Keys (API Key और Secret)
Access Tokens (Access Token और Secret)

निम्नलिखित तीन एंडपॉइंट्स के मामले में, आप अपने ऐप के संदर्भ में write actions करते हैं (इनमें कोई X उपयोगकर्ता शामिल नहीं होता)। इसलिए, आपको जो Access Tokens देने हैं, वे आपके डेवलपर ऐप के होने चाहिए। इन्हें सीधे डेवलपर कंसोल में, आपके ऐप के “Keys and tokens” टैब के अंतर्गत जनरेट किया जा सकता है।

POST account_activity/webhooks: दिए गए application context के लिए नया webhook URL रजिस्टर करें
PUT account_activity/webhooks/:webhook_id: दिए गए webhook URL के लिए challenge response check (CRC) ट्रिगर करें
DELETE account_activity/webhooks/:webhook_id: webhook हटाएँ

दूसरी ओर, नीचे दिए गए तीन endpoints के मामले में आप ऐसा अनुरोध कर रहे होते हैं, जो आपके application को किसी X उपयोगकर्ता की ओर से संरक्षित डेटा (उदाहरण के लिए, Direct Messages) तक पहुँचने की अनुमति देता है। इसलिए आपको संबंधित subscribing उपयोगकर्ता के Access Tokens देने होंगे। आवश्यक Access Tokens, 3-legged OAuth flow का उपयोग करके प्राप्त किए जा सकते हैं (देखें OAuth 1.0a: किसी उपयोगकर्ता के Access Tokens कैसे प्राप्त करें)। ऊपर दी गई तालिका में इन endpoints को तारांकन चिह्न (*) से चिह्नित किया गया है।

POST account_activity/webhooks/:webhook_id/subscriptions/all: application को किसी उपयोगकर्ता के account events के लिए subscribe करें
GET account_activity/webhooks/:webhook_id/subscriptions/all: जाँचें कि कोई webhook configuration किसी उपयोगकर्ता के events के लिए subscribed है या नहीं
DELETE account_activity/webhooks/:webhook_id/subscriptions/all: दिए गए उपयोगकर्ता context और application के लिए subscription निष्क्रिय करें [DEPRECATED]

कृपया ध्यान दें: सुनिश्चित करें कि आपका developer App “Read, Write, and Direct Messages” के लिए enabled हो। आप इस setting को अपने डेवलपर खाते के Projects & Apps section में, चुने गए developer App के “App permissions” के अंतर्गत बदल सकते हैं। permissions settings बदलने के बाद आपको अपने App credentials फिर से generate करने होंगे।

Account Activity API के साथ उपलब्ध सभी endpoints की सूची, जिसमें संबंधित विवरण और authentication implementation examples के साथ उदाहरण cURL requests शामिल हैं, API संदर्भ दस्तावेज़ में देखी जा सकती है। अतिरिक्त जानकारी के लिए, Enterprise Account Activity API के साथ शुरुआत करने हेतु XDev के sample web app and helper scripts देखें।

कृपया ध्यान दें: API का उपयोग शुरू करने से पहले X को आपके developer App के लिए Account Activity API access enable करना होगा। इसके लिए, authentication के उद्देश्य से जिस App ID का आप उपयोग करना चाहते हैं, उसे अपने account manager या technical support team के साथ साझा करना सुनिश्चित करें।

Account Activity API endpoints का एक ऐसा सेट है, जो आपको एक ही connection के माध्यम से अपने सभी subscribed accounts के लिए real-time account activities प्राप्त करने हेतु उपयोगकर्ता subscriptions बनाने और प्रबंधित करने की अनुमति देता है। Account Activity API के साथ दो authentication methods उपलब्ध हैं (OAuth 1.0a और OAuth 2.0 बेयरर टोकन)। आपको कौन-सी authentication method इस्तेमाल करनी चाहिए, यह इस बात पर निर्भर करेगा कि आप कौन-सा endpoint उपयोग कर रहे हैं।


विवरण	एंडपॉइंट	OAuth 1.0a (उपयोगकर्ता संदर्भ)	OAuth 2.0 बेयरर टोकन (केवल-ऐप)
दिए गए ऐप संदर्भ के लिए नया webhook URL रजिस्टर करें	POST account_activity/webhooks	✓
दिए गए ऐप के लिए सभी URL और उनकी स्थितियाँ लौटाएँ	GET account_activity/webhooks		✓
दिए गए webhook URL के लिए challenge response check (CRC) ट्रिगर करें	PUT account_activity/webhooks/:webhook_id	✓
ऐप को किसी उपयोगकर्ता के अकाउंट इवेंट के लिए सब्सक्राइब करें	POST account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
वर्तमान में सक्रिय सदस्यता की संख्या लौटाएँ	GET account_activity/subscriptions/count		✓
जाँचें कि कोई webhook कॉन्फ़िगरेशन किसी उपयोगकर्ता के इवेंट के लिए सब्सक्राइब है या नहीं	GET account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
वर्तमान में सक्रिय सदस्यता की सूची लौटाएँ	GET account_activity/webhooks/:webhook_id/subscriptions/all/list		✓
webhook हटाएँ	DELETE account_activity/webhooks/:webhook_id	✓
[अप्रचलित] दिए गए उपयोगकर्ता संदर्भ और ऐप के लिए किसी सदस्यता को निष्क्रिय करें	DELETE account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
केवल-ऐप OAuth का उपयोग करके किसी सदस्यता को निष्क्रिय करें	DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json		✓
webhook पर गतिविधियाँ फिर से डिलीवर करता है	POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json		✓

*_ प्रमाणीकरण के लिए सब्सक्राइब करने वाले उपयोगकर्ता के access token आवश्यक हैं। _ उन एंडपॉइंट्स के लिए जिनमें OAuth 1.0a उपयोगकर्ता-संदर्भ प्रमाणीकरण आवश्यक है, आपको रिक्वेस्ट को प्रमाणित करने के लिए ये क्रेडेंशियल्स देने होंगे:

Consumer Keys (API Key और Secret)
Access Tokens (Access Token और Secret)

निम्नलिखित तीन एंडपॉइंट्स के मामले में, आप अपने ऐप के संदर्भ में write actions करते हैं (इसमें कोई X उपयोगकर्ता शामिल नहीं होता)। इसलिए, जिन Access Tokens की आपको आवश्यकता है, वे आपके डेवलपर ऐप के होने चाहिए। इन्हें सीधे डेवलपर कंसोल में, आपके ऐप के “Keys and tokens” टैब के अंतर्गत जनरेट किया जा सकता है।

POST account_activity/webhooks: दिए गए application context के लिए एक नया webhook URL रजिस्टर करें
PUT account_activity/webhooks/:webhook_id: दिए गए webhook URL के लिए challenge-response check (CRC) ट्रिगर करें
DELETE account_activity/webhooks/:webhook_id: एक webhook हटाएँ

दूसरी ओर, निम्नलिखित तीन endpoints के मामले में, आप ऐसा अनुरोध कर रहे हैं जो आपके application को किसी X उपयोगकर्ता की ओर से संरक्षित डेटा (उदाहरण के लिए, Direct Messages) तक पहुँचने की अनुमति देता है। इसलिए, आपको संबंधित subscribing उपयोगकर्ता के Access Tokens देने होंगे। आवश्यक Access Tokens, 3-legged OAuth flow का उपयोग करके प्राप्त किए जा सकते हैं (देखें OAuth 1.0a: किसी उपयोगकर्ता के Access Tokens कैसे प्राप्त करें)। इन endpoints को ऊपर दी गई तालिका में तारांकन चिह्न (*) से चिह्नित किया गया है।

POST account_activity/webhooks/:webhook_id/subscriptions/all: application को किसी उपयोगकर्ता के account events के लिए subscribe करें
GET account_activity/webhooks/:webhook_id/subscriptions/all: जाँचें कि कोई webhook configuration किसी उपयोगकर्ता के events के लिए subscribed है या नहीं
DELETE account_activity/webhooks/:webhook_id/subscriptions/all: दिए गए उपयोगकर्ता context और application के लिए subscription निष्क्रिय करें [DEPRECATED]

कृपया ध्यान दें: सुनिश्चित करें कि आपका डेवलपर ऐप “Read, Write, and Direct Messages” के लिए enabled है। आप इस setting को अपने डेवलपर खाते के Projects & Apps section में, चुने गए डेवलपर ऐप के “App permissions” के अंतर्गत बदल सकते हैं। permissions setting बदलने के बाद आपको अपने ऐप credentials फिर से generate करने होंगे।

Account Activity API के साथ उपलब्ध सभी endpoints की सूची, जिसमें संबंधित विवरण और authentication implementation examples के साथ उदाहरण cURL requests शामिल हैं, API संदर्भ documentation में मिल सकती है। अतिरिक्त जानकारी के लिए, Enterprise Account Activity API के साथ शुरुआत करने हेतु XDev के sample web app and helper scripts देखें।

पुनः प्रयास

Enterprise Account Activity API के enterprise tier का एक लाभ webhook इवेंट के लिए पुनः प्रयास तंत्र है। यदि ‘success’ 200 HTTP रिस्पॉन्स कोड प्राप्त नहीं होता, तो X सर्वर पुनः प्रयास तंत्र शुरू करता है और webhook इवेंट को पाँच मिनट की अवधि में अधिकतम तीन बार फिर से भेजता है। यह webhook इवेंट पुनः प्रयास सेवा नेटवर्क समस्याएँ होने पर, तथा client-side सेवा रुकावटों और डिप्लॉयमेंट के दौरान, विश्वसनीयता और इवेंट रिकवरी प्रदान करने में मदद करती है।

पुनः प्रयास क्या हैं?

जब क्लाइंट का वेब ऐप किसी अकाउंट एक्टिविटी webhook event के लिए ‘success’ 200 रिस्पॉन्स नहीं लौटाता है, तो Account Activity API पुनः प्रयास की सुविधा देता है। जब क्लाइंट-साइड किसी event की सफल प्राप्ति की पुष्टि नहीं करता, तो X मान लेता है कि event प्राप्त नहीं हुआ। अगर non-200 रिस्पॉन्स मिलता है, तीन सेकंड के भीतर कोई रिस्पॉन्स नहीं मिलता, या हमें बिल्कुल भी कोई रिस्पॉन्स नहीं मिलता, तो हम अनुरोध दोबारा भेजते हैं और उसे तीन सेकंड तक खुला रखते हैं। इसका मतलब है कि जिस activity को हम आपके webhook URL पर भेजने की कोशिश कर रहे हैं, उसे प्राप्त करने के लिए आपके पास दो प्रयासों में कुल मिलाकर लगभग पाँच सेकंड होते हैं। अगर आपका सर्वर रिस्पॉन्स नहीं देता या कोई अस्थायी त्रुटि लौटाता है, तो हम पाँच मिनट तक पुनः प्रयास करते रहेंगे। वैलिडेशन की पुष्टि के लिए कुल तीन पुनः प्रयास किए जाएंगे। इससे अतिरिक्त विश्वसनीयता मिलती है और यह सुनिश्चित करने में मदद मिलती है कि आपको सभी webhook events मिलें। ध्यान दें कि जिन subscriptions पर पुनः प्रयास लागू होते हैं, उन्हें अपने webhook पर सभी subscribed users की किसी भी/सभी activities के लिए पुनः प्रयास किए गए events मिलेंगे। अगर आप इन आठ प्रयासों के भीतर वैलिडेशन की पुष्टि नहीं करते हैं, तो activity फिर Account Activity API के माध्यम से उपलब्ध नहीं रहेगी।

पुनः प्रयास समयरेखा

200 रिस्पॉन्स मिलने तक Account Activity API पाँच मिनट की अवधि में अधिकतम तीन बार पुनः प्रयास करेगा। अधिक जानकारी के लिए नीचे दी गई तालिका देखें। लगभग पाँच मिनट बाद, गतिविधि को Account Activity API के माध्यम से फिर से नहीं भेजा जा सकता। छूटे हुए डेटा को एकत्र करने के लिए आपको X के अन्य endpoints का उपयोग करना होगा। उदाहरण के लिए, प्रासंगिक पोस्ट्स, Retweets, Quote Tweets, Mentions, और Replies प्राप्त करने के लिए search APIs का उपयोग किया जा सकता है। छूटे हुए Direct Messages को this endpoint का उपयोग करके प्राप्त किया जा सकता है।

पुनः प्रयास समयरेखा


गतिविधि बनाई जाती है, Account Activity API webhook URL पर POST करता है, और तीन सेकंड में टाइम आउट हो जाता है।
पिछले टाइम आउट के समाप्त होने के तीन सेकंड बाद प्रतीक्षा करें, फिर Account Activity API webhook URL पर POST करता है, और तीन सेकंड में टाइम आउट हो जाता है।
पिछले टाइम आउट के समाप्त होने के 27 सेकंड बाद प्रतीक्षा करें, फिर Account Activity API webhook URL पर POST करता है, और तीन सेकंड में टाइम आउट हो जाता है।
पिछले टाइम आउट के समाप्त होने के 242 सेकंड बाद प्रतीक्षा करें, फिर Account Activity API webhook URL पर POST करता है, और तीन सेकंड में टाइम आउट हो जाता है।
इसके बाद Account Activity API POST करने का प्रयास बंद कर देगा। डेटा पुनर्प्राप्त करने के लिए Client को X के अन्य endpoints का उपयोग करना होगा।

Account Activity डेटा ऑब्जेक्ट की संरचना

ऑब्जेक्ट	विवरण
for_user_id	उस उपयोगकर्ता सदस्यता की पहचान करता है जिससे यह इवेंट संबंधित है।
is_blocked_by	(सशर्त) केवल तब दिखाया जाता है जब कोई अन्य उपयोगकर्ता आपके सब्सक्राइब किए गए उपयोगकर्ता का उल्लेख करता है। केवल पोस्ट mention इवेंट्स के लिए, true होने पर शामिल किया जाता है।
source	वह उपयोगकर्ता जो गतिविधि कर रहा है। उदाहरण के लिए, जो उपयोगकर्ता follow, block, या mute कर रहा है, वही source उपयोगकर्ता है।
target	वह उपयोगकर्ता जिस पर गतिविधि लागू होती है। उदाहरण के लिए, जिस उपयोगकर्ता को follow, block, या mute किया जा रहा है, वह target उपयोगकर्ता है।

उपलब्ध गतिविधियाँ

संदेश प्रकार	विवरण
tweet_create_events	पोस्ट status payload, जब निम्न में से कोई भी कार्रवाई सदस्यता वाले उपयोगकर्ता द्वारा की जाती है या उस पर की जाती है: पोस्ट्स, Retweets, Replies, @mentions, QuoteTweets, Quote Tweets के Retweets।
favorite_events	उपयोगकर्ता और target के साथ Favorite (like) इवेंट status।
follow_events	उपयोगकर्ता और target के साथ Follow इवेंट।
unfollow_events	उपयोगकर्ता और target के साथ Unfollow इवेंट।
block_events	उपयोगकर्ता और target के साथ Block इवेंट।
unblock_events	उपयोगकर्ता और target के साथ Unblock इवेंट।
mute_events	उपयोगकर्ता और target के साथ Mute इवेंट।
unmute_events	उपयोगकर्ता और target के साथ Unmute इवेंट।
user_event	जब कोई उपयोगकर्ता application authorization हटा देता है और सदस्यता अपने-आप हटा दी जाती है, तब Revoke इवेंट्स भेजे जाते हैं।
direct_message_events	जब direct message भेजा या प्राप्त किया जाता है, तब उपयोगकर्ता और target के साथ direct message status।
direct_message_indicate_typing_events	उपयोगकर्ता और target के साथ direct message typing इवेंट।
direct_message_mark_read_events	उपयोगकर्ता और target के साथ direct message read इवेंट।
tweet_delete_events	अनुपालन बनाए रखना आसान बनाने के लिए हटाई गई पोस्ट्स की सूचना।

Payload उदाहरण ऊपर दी गई तालिका में वर्णित प्रत्येक Account Activity इवेंट के लिए नीचे payload उदाहरण देखें।

tweet_create_events (पोस्ट्स, रीट्वीट्स, रिप्लाई, कोट ट्वीट्स)

{
	"for_user_id": "2244994945",
	"tweet_create_events": [
	  {
		<Tweet Object>
	  }
	]
}

tweet_create_events (@मेंशन)

{
	"for_user_id": "2244994945",
	"user_has_blocked": "false",
	"tweet_create_events": [
	  {
		<Tweet Object>
	  }
	]
}

favorite_events

{
	"for_user_id": "2244994945",
	"favorite_events": [{
		"id": "a7ba59eab0bfcba386f7acedac279542",
		"created_at": "Mon Mar 26 16:33:26 +0000 2018",
		"timestamp_ms": 1522082006140,
		"favorited_status": {
			<Tweet Object>
		},
		"user": {
			<User Object>
		}
	}]
}

follow_events

{
	"for_user_id": "2244994945",
	"follow_events": [{
			"type": "follow",
			"created_timestamp": "1517588749178",
			"target": {
				<User Object >
			},
			"source": {
				< User Object >
			}
		]
	}
}

unfollow_events

{
	"for_user_id": "2244994945",
	"follow_events": [{
			"type": "unfollow",
			"created_timestamp": "1517588749178",
			"target": {
				<User Object >
			},
			"source": {
				< User Object >
			}
		]
	}
}

block_events

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "block",
		"created_timestamp": "1518127020304",
		"source": {
			<User Object>
		},
		"target": {
			<User Object>
		}
	}]
}

unblock_events

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "unblock",
		"created_timestamp": "1518127020304",
		"source": {
			<User Object>
		},
		"target": {
			<User Object>
		}
	}]
}

mute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "mute",
		  	"created_timestamp": "1518127020304",
			"source": {
				<User Object>
			},
			"target": {
				<User Object>
			}
		}
	]
}

unmute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "unmute",
		  	"created_timestamp": "1518127020304",
			"source": {
				<User Object>
			},
			"target": {
				<User Object>
			}
		}
	]
}

user_event

{
	"user_event": {
		"revoke": {
			"date_time": "2018-05-24T09:48:12+00:00",
			"target": {
				"app_id": "13090192"
			},
			"source": {
				"user_id": "63046977"
			}
		}
	}
}

direct_message_events

{
  	"for_user_id": "4337869213",
	"direct_message_events": [{
		"type": "message_create",
		"id": "954491830116155396",
		"created_timestamp": "1516403560557",
		"message_create": {
			"target": {
				"recipient_id": "4337869213"
			},
			"sender_id": "3001969357",
			"source_app_id": "13090192",
			"message_data": {
				"text": "Hello World!",
				"entities": {
					"hashtags": [],
					"symbols": [],
					"user_mentions": [],
					"urls": []
				}
			}
		}
	}],
	"apps": {
		"13090192": {
			"id": "13090192",
			"name": "FuriousCamperTestApp1",
			"url": "https://x.com/furiouscamper"
		},
		"users": {},
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE opinions-are-my-own",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 22,
			"friends_count": 45,
			"statuses_count": 494,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		},
		"4337869213": {
			"id": "4337869213",
			"created_timestamp": "1448312972328",
			"name": "Harrison Test",
			"screen_name": "Harris_0ff",
			"location": "Burlington, MA",
			"protected": false,
			"verified": false,
			"followers_count": 8,
			"friends_count": 8,
			"profile_image_url": "null",
			"statuses_count": 240,
			"profile_image_url_https": "https://abs.twimg.com/sticky/default_profile_images/default_profile_normal.png"
		}
	}
}

direct_message_indicate_typing_events

{
	"for_user_id": "4337869213",
	"direct_message_indicate_typing_events": [{
		"created_timestamp": "1518127183443",
		"sender_id": "3284025577",
		"target": {
			"recipient_id": "3001969357"
		}
	}],
	"users": {
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE opinions-are-my-own",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 23,
			"friends_count": 47,
			"statuses_count": 509,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		},
		"3284025577": {
			"id": "3284025577",
			"created_timestamp": "1437281176085",
			"name": "Bogus Bogart",
			"screen_name": "bogusbogart",
			"protected": true,
			"verified": false,
			"followers_count": 1,
			"friends_count": 4,
			"statuses_count": 35,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/763383202857779200/ndvZ96mE_normal.jpg"
		}
	}
}

direct_message_mark_read_events

{
	"for_user_id": "4337869213",
	"direct_message_mark_read_events": [{
		"created_timestamp": "1518452444662",
		"sender_id": "199566737",
		"target": {
			"recipient_id": "3001969357"
		},
		"last_read_event_id": "963085315333238788"
	}],
	"users": {
		"199566737": {
			"id": "199566737",
			"created_timestamp": "1286429788000",
			"name": "Le Braat",
			"screen_name": "LeBraat",
			"location": "Denver, CO",
			"description": "data by day @X, design by dusk",
			"protected": false,
			"verified": false,
			"followers_count": 299,
			"friends_count": 336,
			"statuses_count": 752,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/936652894371119105/YHEozVAg_normal.jpg"
		},
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE opinions-are-my-own",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 23,
			"friends_count": 48,
			"statuses_count": 510,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		}
	}
}

tweet_delete_events

{
    "for_user_id": "930524282358325248",
    "tweet_delete_events": [
{
        "status": {
            "id": "1045405559317569537",
            "user_id": "930524282358325248"
        },
        "timestamp_ms": "1432228155593"
    }
   ]
}

Account Activity Replay API

Enterprise Account Activity Replay API एक डेटा रिकवरी टूल है, जो आपको पिछले पाँच दिनों तक की घटनाएँ पुनर्प्राप्त करने की सुविधा देता है। इसका उपयोग उन स्थितियों में डेटा रिकवर करने के लिए किया जाना चाहिए, जहाँ आपका वेबहुक सर्वर घटनाएँ मिस कर देता है — चाहे इसका कारण retry window से अधिक समय तक रहने वाला डिस्कनेक्शन हो, या ऐसी डिज़ास्टर रिकवरी स्थितियाँ हों जिनमें आपके सिस्टम को फिर से सामान्य स्थिति में लाने के लिए कुछ दिनों की आवश्यकता पड़े। Account Activity Replay API को उन सभी स्थितियों के लिए विकसित किया गया है, जहाँ आप कुछ समय तक गतिविधियाँ इनजेस्ट नहीं कर पाते। यह गतिविधियों को उसी वेबहुक पर डिलीवर करता है, जिसका उपयोग उनकी मूल रीयल-टाइम डिलीवरी के लिए किया गया था। यह प्रोडक्ट एक रिकवरी टूल है, बैकफिल टूल नहीं; इसका मतलब है कि घटनाएँ केवल तभी फिर से चलाई जाएँगी, जब उन्हें पहले डिलीवर करने का प्रयास किया गया हो। Account Activity Replay API किसी सदस्यता के बनाए जाने के समय से पहले की अवधि की घटनाएँ डिलीवर नहीं कर सकता।

Account Activity Replay API का उपयोग

यदि आपका खाता Replay फ़ंक्शनैलिटी के साथ कॉन्फ़िगर किया गया है, तो आप Account Activity API के अनुरोधों की तरह ही अनुरोध कर सकते हैं। यह ध्यान रखना ज़रूरी है कि आपके अनुरोध में वेबहुक id पैरामीटर निर्दिष्ट होना चाहिए, ताकि यह बताया जा सके कि आप किस वेबहुक की गतिविधियों को replay करना चाहते हैं। दूसरे शब्दों में, Replay अनुरोध Account Activity Replay API से वेबहुक id और application id के आधार पर शुरूआती तारीख और समय से अंतिम तारीख और समय तक की घटनाएँ पुनर्प्राप्त करने के लिए कहता है। कृपया ध्यान दें कि UTC समय अपेक्षित है। ये गतिविधियाँ id से जुड़े पंजीकृत वेबहुक के माध्यम से प्रति सेकंड अधिकतम 2,500 घटनाओं की दर से भेजी जाती हैं। यह भी ध्यान रखें कि प्रत्येक वेबहुक के लिए एक समय में केवल एक Replay job चल सकती है, हालांकि उस वेबहुक पर निर्दिष्ट तारीख/समय के दौरान सक्रिय रही सभी subscriptions को replay किया जाएगा। घटनाएँ निर्दिष्ट समयावधि के पहले (सबसे पुराने) मिनट से भेजी जाती हैं और कालानुक्रमिक क्रम में (जहाँ तक संभव हो) तब तक जारी रहती हैं, जब तक अंतिम मिनट की डिलीवरी नहीं हो जाती। उस समय, Replay वेबहुक को एक job completion event भेजेगा। चूँकि गतिविधियाँ कालानुक्रमिक क्रम में भेजी जाती हैं, इसलिए यदि शुरूआती समय के आसपास बहुत कम या कोई मेल खाते परिणाम नहीं हैं, तो पहले परिणाम मिलने से पहले कुछ समय का अंतराल हो सकता है।

सीमाएँ

Replay का उद्देश्य पाँच दिन पहले तक की गतिविधियों को आसानी से पुनर्प्राप्त करने के टूल के रूप में है, लेकिन यह किसी सदस्यता के बनाए जाने के समय से पहले की घटनाएँ डिलीवर नहीं करेगा। उदाहरण के लिए, यदि आपने तीन दिन पहले एक नई सदस्यता जोड़ी और आज से पिछले पाँच दिनों की विंडो के साथ एक Replay जॉब चलाई, तो आपको केवल उन तीन दिनों का डेटा मिलेगा, जिनके दौरान यह नई सदस्यता सक्रिय थी।

डेटा उपलब्धता और प्रकार

Account Activity Replay API की गतिविधियाँ अनुरोध शुरू किए जाने के बाद पाँच दिनों तक उपलब्ध रहती हैं, और किसी गतिविधि के बनाए जाने के लगभग 10 मिनट बाद नया डेटा उपलब्ध हो जाता है। आप अनुरोध में from_date और to_date पैरामीटर का उपयोग करके इस पाँच-दिवसीय अवधि के भीतर एक समय-सीमा निर्दिष्ट कर सकेंगे। Replay की पहुँच मिलने से पहले मूल रूप से डिलीवर की गई घटनाओं को फिर से नहीं चलाया जा सकता। उदाहरण के लिए, अगर आपके खाते को 1 जून, 2019 को 3:30PM UTC पर Account Activity Replay API की पहुँच के लिए सक्षम किया गया था, तो आप उस तारीख और समय से पहले की किसी भी घटना को प्राप्त करने के लिए Replay का उपयोग नहीं कर पाएँगे। Account Activity Replay API संदर्भ पर आगे बढ़ें

माइग्रेशन परिचय

हमने 2018 में Site Streams, User Streams और Account Activity API - DM Only उत्पादों के मानक बीटा संस्करण को बंद कर दिया था। यदि आप उन उत्पादों का उपयोग कर रहे थे, तो कृपया Account Activity API के premium या enterprise संस्करण पर माइग्रेट करना सुनिश्चित करें। **हमने पुराने Direct Message endpoints को भी बंद कर दिया है। यदि आप उन endpoints का उपयोग कर रहे थे, तो कृपया नए DM endpoints या Account Activity API के premium या enterprise संस्करण में से किसी एक पर माइग्रेट करना सुनिश्चित करें। ** अधिक जानने के लिए कृपया इस घोषणा को देखें। यहाँ वे endpoints दिए गए हैं जो इन परिवर्तनों से प्रभावित होंगे:

User Streams
Site Streams
GET direct_messages
GET direct_messages/sent
GET direct_messages/show
POST direct_messages/new
POST direct_messages/destroy

अब हमारे पास नए endpoints और सेवाएँ उपलब्ध हैं, जो समान एक्सेस प्रदान करती हैं और Direct Messages के लिए कुछ अतिरिक्त सुविधाएँ भी देती हैं:

Account Activity API enterprise और premium
GET direct_messages/events/list
GET direct_messages/events/show
POST direct_messages/events/new
POST direct_messages/events/destroy

इन नए endpoints और सेवाओं पर आसानी से माइग्रेट करने में आपकी मदद के लिए हमारे पास दो माइग्रेशन गाइड हैं:

Account Activity API migration guide उनके लिए, जो User Streams और Site Streams से हमारी नई वेबहुक-आधारित सेवा पर जा रहे हैं
Direct Message migration guide उनके लिए, जो Direct Message REST endpoints के बीच माइग्रेट कर रहे हैं

इसके अतिरिक्त, Account Activity API और उसके साथ शुरुआत करने के तरीके पर हमारे पास वीडियो की एक श्रृंखला भी है। और अंत में, आपकी समझ को और बेहतर बनाने और जल्दी शुरुआत करने में मदद के लिए हमारे पास code samples भी हैं:

Account Activity Dashboard एक नमूना Node.js web app है, जिसमें Account Activity API के साथ शुरुआत करने के लिए helper scripts शामिल हैं।
SnowBot एक नमूना chatbot है, जो Account Activity API और REST Direct Message endpoints का उपयोग करता है। यह Ruby में लिखा गया है, Sinatra web app framework का उपयोग करता है, और Heroku पर deploy किया गया है।

माइग्रेशन गाइड: User Streams/Site Streams से Account Activity API पर माइग्रेट करना

23 अगस्त, 2018 से हमने Site Streams और User Streams, दोनों को बंद कर दिया है। कृपया Account Activity API पर माइग्रेट करना सुनिश्चित करें। अधिक जानकारी के लिए कृपया इस घोषणा को देखें। यह गाइड आपको पुराने User Streams और Site Streams API से उनके विकल्प, Account Activity API, पर माइग्रेट करने में मदद करने के लिए तैयार की गई है। नीचे आपको बदलावों का सारांश, नई सुविधाओं की सूची, साथ ही इस संक्रमण में मदद के लिए मुख्य अंतर और महत्वपूर्ण बातों का विवरण मिलेगा। बेसिक DM endpoints से माइग्रेट करने के मार्गदर्शन के लिए, कृपया Direct Message migration guide देखें।

परिवर्तनों का सारांश

User Streams और Site Streams की तरह streaming connection के बजाय, Account Activity API प्रमाणित और subscribed खातों के लिए वेबहुक्स के माध्यम से घटनाएँ उपलब्ध कराएगा।

अप्रचलित API

GET user GET site (कंट्रोल स्ट्रीम्स सहित: GET site/c/:stream_id, GET site/c/:stream_id/info.json, GET site/c/:stream_id/friends/ids.json, POST site/c/:stream_id/add_user.json, POST /site/c/:stream_id/remove_user.json)

विकल्प API

Enterprise Account Activity API - सभी गतिविधियां

अंतर और माइग्रेशन संबंधी विचार

API प्रारूप: नया Account Activity API, User Streams और Site Streams से अलग तरीके से काम करता है। वेबहुक्स के ज़रिए डेटा प्राप्त करने के लिए आपको अपने web app में बदलाव करने होंगे। वेबहुक्स के बारे में अधिक जानकारी आप यहाँ पा सकते हैं। उपलब्ध डेटा: एक और महत्वपूर्ण अंतर जो आप देखेंगे, वह उपलब्ध कराए जाने वाले डेटा से संबंधित है। X अब उन लोगों के घटनाएँ नहीं भेजेगा जिन्हें आप X पर follow करते हैं (यानी आपकी home timeline)। यह बदलाव जानबूझकर किया गया था, और आगे इसे बदलने की हमारी कोई योजना नहीं है। विश्वसनीयता: streaming के विपरीत, वेबहुक्स डिलीवरी की पुष्टि करने और उन POST की गई गतिविधियों को फिर से भेजने का विकल्प देते हैं जो वेबहुक URL तक नहीं पहुँचतीं। इससे यह अधिक भरोसा मिलता है कि ऐप सभी लागू गतिविधियाँ प्राप्त कर रहा है, भले ही थोड़े समय के लिए कनेक्शन टूट जाए या downtime की अवधि हो।

नई सुविधाएँ

Account Activity API कई नई सुविधाएँ प्रदान करता है। इनमें सबसे महत्वपूर्ण यह है कि अब डेटा स्ट्रीमिंग के बजाय webhooks के माध्यम से भेजा जाता है। स्ट्रीमिंग की तुलना में webhooks के कई लाभ हैं, जिनमें गति और विश्वसनीयता सबसे प्रमुख हैं। API उपलब्ध होते ही आपको JSON events के रूप में डेटा भेज देगा, और अब आपको न तो सक्रिय कनेक्शन बनाए रखना होगा और न ही endpoint को poll करना होगा। इससे redundancy features की आवश्यकता कम होती है और कुल मिलाकर दक्षता बढ़ती है। webhooks के बारे में अधिक जानकारी technical documentation में उपलब्ध है।

उपयोगकर्ता सदस्यताओं का प्रबंधन

Account Activity API एक ही पंजीकृत webhook के लिए कई सदस्यताओं की अनुमति देता है। इससे webhooks के माध्यम से, Site Streams आर्किटेक्चर की तरह, कई उपयोगकर्ता सदस्यता गतिविधियां एक ही स्थान पर पहुंचाई जा सकती हैं। इसका मतलब है कि आप अपनी सदस्यता सीमाओं के संदर्भ में, webhook कनेक्शन से स्वतंत्र रूप से सदस्यताओं को ट्रैक कर सकते हैं। इससे एक ही webhook के लिए केवल एक या कुछ सदस्यताओं से लेकर हजारों सदस्यताओं तक स्केल करना भी संभव हो जाता है।

माइग्रेशन कैसे करें

Site Streams API से Account Activity API पर आसानी से माइग्रेट करने के लिए नीचे दिए गए चरणों का पालन करें

चरण 1: एक पैकेज चुनें आप वर्तमान में User Streams या Site Streams के साथ कैसे काम कर रहे हैं, इसके आधार पर आपको Account Activity API के enterprise या premium संस्करणों में से किसी एक पर माइग्रेट करने पर विचार करना चाहिए। वर्तमान में आप जितने applications या अधिकृत उपयोगकर्ताओं को support कर रहे हैं, उन्हें ध्यान में रखें और आवश्यक वॉल्यूम तथा विश्वसनीयता के अनुसार उपयुक्त रूप से scale करें। आपकी ज़रूरतों के लिए सबसे उपयुक्त पैकेज चुनते समय, इन बातों पर विचार करें:

आवश्यक webhooks की संख्या
आपके application पर प्रबंधित वर्तमान/अनुमानित subscriptions/अधिकृत उपयोगकर्ता
X client applications की वर्तमान संख्या
X से आप किस स्तर का support चाहते हैं (forum support या managed enterprise स्तर का 1:1 support)
प्रत्येक पैकेज की कीमत

चरण 2: डेवलपर कंसोल में अपने X ऐप का सेटअप जाँचें वर्तमान में User Streams या Site Streams के लिए उपयोग किया जा रहा X ऐप, owning user के लिए डेवलपर कंसोल में सूचीबद्ध होगा। इसी X ऐप का उपयोग Account Activity API के लिए भी किया जा सकता है, ताकि उस application के लिए अधिकृत उपयोगकर्ता बने रहें। यदि चाहें, तो एक नया ऐप भी बनाया जा सकता है, और उपयोगकर्ताओं को इस नए ऐप के लिए फिर से अधिकृत किया जा सकता है। यदि आप किसी business की ओर से नया ऐप बना रहे हैं, तो यह अनुशंसा की जाती है कि आप ऐप को किसी corporate X @handle account से बनाएं।

अपने X ऐप पेज के permissions tab में “Read, Write and Access direct messages” सक्षम करें। *ध्यान दें कि इन settings में बदलाव पूर्वव्यापी नहीं होता; जो उपयोगकर्ता पहले से अधिकृत हैं, वे वही authorization settings बनाए रखेंगे जो उनके authorization के समय लागू थीं। यदि किसी उपयोगकर्ता ने आपको पहले से read, write और direct message access नहीं दिया है, तो आपको उस उपयोगकर्ता से अपना application फिर से authorize कराना होगा।
यदि आप X Sign-in और X API के साथ user contexts के काम करने के तरीके से परिचित नहीं हैं, तो Access Tokens प्राप्त करना देखें।
“Keys and Tokens” tab के सबसे नीचे X ऐप owner के लिए access tokens generate करें। इसी tab में अपना Consumer Key, Consumer Secret, Access Token और Access Token Secret नोट कर लें। API का उपयोग करने के लिए आपको इनकी आवश्यकता होगी।
application-only API methods के लिए अपने Consumer Key और Consumer Secret का उपयोग करके एक बेयरर टोकन generate करें।

चरण 3: अपने Webhooks सेट अप और कॉन्फ़िगर करें

events प्राप्त करने के लिए webhook के रूप में उपयोग करने हेतु endpoint वाला एक web app बनाएं (उदा. https://your_domain.com/webhook/twitter या https://webhooks.your_domain.com)।
अपना webhook बनाते समय अपने Consumer Key, Consumer Secret, Access Token और Access Token Secret का उपयोग करें। ध्यान दें कि आपके endpoint को एक JSON रिस्पॉन्स लौटाना होगा, जिसमें response_token हो, जो crc_token और आपके ऐप Consumer Secret से बनाया गया base64-encoded HMAC SHA-256 hash हो।
Securing Webhooks दस्तावेज़ देखें और Challenge Response Check (CRC) requirements पर विशेष ध्यान दें।
सुनिश्चित करें कि आपका webhook incoming events के लिए POST requests और CRC के लिए GET requests support करता है।
सुनिश्चित करें कि आपके webhook की latency कम हो (<3 seconds to respond to POST requests)

चरण 4: अपने Webhook सेटअप को सत्यापित करें

Webhook APIs आपके webhooks को दो तरीकों से सुरक्षित करेंगी:

- यह सत्यापित करने के लिए challenge response checks आवश्यक होंगे कि webhook का owner ही web app का owner है। - source को सत्यापित करने के लिए आपके web app हेतु प्रत्येक POST request में एक signature header होगा।

यह सत्यापित करने के लिए कि web app और webhook URL, दोनों के owner आप ही हैं, X एक Challenge Response Check (CRC) करेगा, जिसे cyclic redundancy check के साथ भ्रमित नहीं करना चाहिए।
crc_token नाम के parameter के साथ एक GET request आपके webhook URL पर भेजी जाएगी। आपके endpoint को एक JSON रिस्पॉन्स लौटाना होगा, जिसमें response_token हो, जो crc_token और आपके ऐप Consumer Secret से बनाया गया base64-encoded HMAC SHA-256 hash हो।
प्रत्येक incoming CRC request के लिए crc_token बदलने की अपेक्षा की जानी चाहिए। गणना में crc_token को message के रूप में उपयोग किया जाना चाहिए, जहाँ आपका Consumer Secret key होता है।
यदि रिस्पॉन्स अमान्य होता है, तो registered webhook पर events भेजना बंद कर दिया जाएगा।

चरण 5: प्रत्येक User Stream या Site Streams अधिकृत उपयोगकर्ता के लिए Subscriptions बनाएं User Streams से Account Activity API में परिवर्तन करना:

User Streams पर अपनी मौजूदा उपयोगकर्ता सदस्यताओं की सूची बनाएं
इस अनुरोध का उपयोग करके अपनी नई Account Activity API सदस्यताएँ सेट अप करें: POST account_activity/all/:env_name/subscriptions
इस अनुरोध का उपयोग करके अपनी Account Activity API सदस्यताओं की पुष्टि करें: _GET account_activity/all/:env_name/subscriptions/list _

Site Streams से Account Activity API में रूपांतरण: (control streams का उपयोग करके):

इस अनुरोध का उपयोग करके Site Streams पर अपनी मौजूदा सदस्यताओं की सूची बनाएं: GET /1.1/site/c/:stream_id/info.json
इस अनुरोध का उपयोग करके अपनी नई Account Activity API सदस्यताएँ सेट अप करें: POST account_activity/all/:env_name/subscriptions
इस अनुरोध का उपयोग करके अपनी Account Activity API सदस्यताओं की पुष्टि करें: _GET account_activity/all/:env_name/subscriptions/list _

Webhook पंजीकृत करना और सदस्यताएँ बनाना (Site Streams या User Streams से माइग्रेट नहीं कर रहे हैं)

POST webhooks का उपयोग करके अपने ऐप के साथ अपना webhook URL पंजीकृत करें और एक webhook_id प्राप्त करें।
लौटाए गए webhook_id का उपयोग करके POST webhooks/:webhook_id/subscriptions/all से उपयोगकर्ता सदस्यताएँ जोड़ें।

Account Activity डैशबोर्ड (नमूना Account Activity API ऐप)

हमने Account Activity API का परीक्षण थोड़ा तेज़ और आसान बनाने के लिए एक नमूना ऐप बनाया है:

यहाँ से Account Activity Dashboard का नमूना ऐप डाउनलोड करें (यह Node.js का उपयोग करता है)
ऐप को इंस्टॉल और लॉन्च करने के लिए README में दिए गए निर्देशों का पालन करें
ऐप लॉन्च होने के बाद, आप UI का उपयोग करके अपना webhook आसानी से सेट अप कर सकते हैं और नई सदस्यता बना सकते हैं

उपलब्ध गतिविधियाँ

संदेश प्रकार	विवरण
tweet_create_events	पोस्ट स्टेटस पेलोड, जब सदस्यता उपयोगकर्ता द्वारा या उसके लिए निम्न में से कोई भी कार्रवाई की जाती है: पोस्ट्स, Retweets, Replies, @mentions, QuoteTweets
favorite_events	उपयोगकर्ता और लक्ष्य के साथ पसंद (लाइक) इवेंट स्टेटस।
follow_events	उपयोगकर्ता और लक्ष्य के साथ फ़ॉलो इवेंट।
block_events	उपयोगकर्ता और लक्ष्य के साथ ब्लॉक इवेंट।
mute_events	उपयोगकर्ता और लक्ष्य के साथ म्यूट इवेंट।
direct_message_events	उपयोगकर्ता और लक्ष्य के साथ डायरेक्ट मैसेज स्टेटस।
direct_message_indicate_typing_events	उपयोगकर्ता और लक्ष्य के साथ डायरेक्ट मैसेज टाइपिंग इवेंट।
direct_message_mark_read_events	उपयोगकर्ता और लक्ष्य के साथ डायरेक्ट मैसेज पढ़े जाने का इवेंट।

अप्रचलित स्ट्रीमिंग संदेश प्रकार


रिक्त पंक्तियाँ	अब Account Activity API में रिक्त पंक्तियाँ नहीं भेजी जाएँगी, क्योंकि User Streams और Site Streams में उनका उपयोग keep-alive संदेशों के रूप में किया जाता था।
सीमा सूचनाएँ	अब किसी दिए गए webhook पर सीमा सूचनाएँ नहीं भेजी जाएँगी। इसके बजाय, उपयोगकर्ता उपलब्ध handles के वर्तमान उपयोग की जानकारी पाने के लिए API को कॉल कर सकते हैं। इसे भविष्य में किसी समय डेवलपर कंसोल में शामिल किया जाएगा।
डिस्कनेक्ट संदेश	अब डिस्कनेक्ट सूचनाओं की आवश्यकता नहीं होगी, क्योंकि webhooks किसी सक्रिय कनेक्शन पर निर्भर नहीं करते हैं।
स्टॉल चेतावनियाँ	अब स्टॉल चेतावनियों की आवश्यकता नहीं होगी, क्योंकि webhooks ऐसे सक्रिय कनेक्शन पर निर्भर नहीं करते जो बड़ी संख्या में आने वाले संदेशों को संभाल सके।
फ्रेंड्स सूची	अब फ्रेंड्स सूचियाँ स्वतः नहीं भेजी जाएँगी। अब यह जानकारी पाने के लिए एक REST endpoint उपलब्ध होगा।

अप्रचलित इवेंट प्रकार


विवरण	इवेंट नाम	स्रोत	लक्ष्य	लक्ष्य ऑब्जेक्ट
उपयोगकर्ता एक पोस्ट हटाता है	delete	वर्तमान उपयोगकर्ता	वर्तमान उपयोगकर्ता	पोस्ट
फ़ॉलो किया गया उपयोगकर्ता एक पोस्ट हटाता है	delete	फ़ॉलो किया गया उपयोगकर्ता	फ़ॉलो किया गया उपयोगकर्ता	पोस्ट
उपयोगकर्ता किसी पोस्ट को पसंदीदा से हटाता है	unfavorite	वर्तमान उपयोगकर्ता	पोस्ट लेखक	पोस्ट
उपयोगकर्ता की पोस्ट को पसंदीदा से हटाया जाता है	unfavorite	पसंदीदा हटाने वाला उपयोगकर्ता	वर्तमान उपयोगकर्ता	पोस्ट
उपयोगकर्ता किसी को अनफ़ॉलो करता है	unfollow	वर्तमान उपयोगकर्ता	फ़ॉलो किया गया उपयोगकर्ता	Null
उपयोगकर्ता एक सूची बनाता है	list_created	वर्तमान उपयोगकर्ता	वर्तमान उपयोगकर्ता	सूची
उपयोगकर्ता एक सूची हटाता है	list_destroyed	वर्तमान उपयोगकर्ता	वर्तमान उपयोगकर्ता	सूची
उपयोगकर्ता एक सूची संपादित करता है	list_updated	वर्तमान उपयोगकर्ता	वर्तमान उपयोगकर्ता	सूची
उपयोगकर्ता किसी को सूची में जोड़ता है	list_member_added	वर्तमान उपयोगकर्ता	जोड़ा गया उपयोगकर्ता	सूची
उपयोगकर्ता को एक सूची में जोड़ा जाता है	list_member_added	जोड़ने वाला उपयोगकर्ता	वर्तमान उपयोगकर्ता	सूची
उपयोगकर्ता किसी को सूची से हटाता है	list_member_removed	वर्तमान उपयोगकर्ता	हटाया गया उपयोगकर्ता	सूची
उपयोगकर्ता को एक सूची से हटाया जाता है	list_member_removed	हटाने वाला उपयोगकर्ता	वर्तमान उपयोगकर्ता	सूची
उपयोगकर्ता एक सूची की सदस्यता लेता है	list_user_subscribed	वर्तमान उपयोगकर्ता	सूची स्वामी	सूची
उपयोगकर्ता की सूची की सदस्यता ली जाती है	list_user_subscribed	सदस्यता लेने वाला उपयोगकर्ता	वर्तमान उपयोगकर्ता	सूची
उपयोगकर्ता एक सूची की सदस्यता समाप्त करता है	list_user_unsubscribed	वर्तमान उपयोगकर्ता	सूची स्वामी	सूची
उपयोगकर्ता की सूची की सदस्यता समाप्त की जाती है	list_user_unsubscribed	सदस्यता समाप्त करने वाला उपयोगकर्ता	वर्तमान उपयोगकर्ता	सूची
उपयोगकर्ता अपनी प्रोफ़ाइल अपडेट करता है	user_update	वर्तमान उपयोगकर्ता	वर्तमान उपयोगकर्ता	Null
उपयोगकर्ता अपनी सुरक्षित स्थिति अपडेट करता है	user_update	वर्तमान उपयोगकर्ता	वर्तमान उपयोगकर्ता	Null

Direct Message माइग्रेशन मार्गदर्शिका

17 सितंबर, 2018 को हमने लीगेसी Direct Message endpoint को बंद कर दिया था। यदि आप उन endpoint का उपयोग कर रहे थे, तो कृपया नए Direct Message endpoint या Account Activity API पर माइग्रेट करना सुनिश्चित करें। अधिक जानकारी के लिए कृपया इस घोषणा देखें। यह मार्गदर्शिका आपको लीगेसी Direct Message REST API से उनके उन्नत विकल्पों पर माइग्रेट करने में मदद करने के लिए तैयार की गई है, जो beta से आगे बढ़कर अब स्थिर रूप में उपलब्ध हैं। नीचे आपको बदलावों का सारांश, नई सुविधाओं की सूची, और ट्रांज़िशन में मदद के लिए मुख्य अंतर तथा ध्यान देने योग्य बातें मिलेंगी। नए Direct Message endpoint अब सभी डेवलपरों के लिए उपलब्ध हैं। User Streams या Site Streams से माइग्रेट करने के मार्गदर्शन के लिए, Account Activity API की माइग्रेशन मार्गदर्शिका देखें।

बदलावों का सारांश
नई सुविधाएँ
Direct Messages भेजना
Direct Messages प्राप्त करना
Direct Messages हटाना

बदलावों का सारांश

यदि आप अभी भी नीचे दिए गए DM endpoint का उपयोग कर रहे हैं, तो आपको नए endpoint पर माइग्रेट करना होगा।

अप्रचलित endpoint	माइग्रेशन के लिए नया विकल्प
POST direct_messages/new	POST direct_messages/events/new
GET direct_messages/show	GET direct_messages/events/show
GET direct_messages	GET direct_messages/events/list
GET direct_messages/sent	GET direct_messages/events/list
POST direct_messages/destroy	DELETE direct_messages/events/destroy

नई सुविधाएँ

नए Direct Message API endpoints कई नई क्षमताओं का समर्थन करते हैं और पुराने Direct Messages तक बेहतर पहुँच प्रदान करते हैं। नई सुविधाओं में शामिल हैं:

मीडिया अटैचमेंट (image, GIF, और video) के लिए समर्थन।
उपयोगकर्ताओं से पहले से तय विकल्पों की सूची के साथ structured replies प्राप्त करने की क्षमता।
30 दिनों तक पुराने Direct Messages तक पहुँच।

नई Direct Message सुविधाओं की पूरी सूची और अतिरिक्त नए API endpoints के लिए technical documentation देखें।

अंतर और माइग्रेशन संबंधी बातें

नए API endpoint अपने पुराने समकक्षों से बहुत अलग तरीके से काम करते हैं। सिर्फ endpoint URL अपडेट करने से आपके application में errors आएंगे। माइग्रेशन के लिए अपने application को अपडेट करते समय नीचे दी गई बातों पर ध्यान दें।

नया Direct Message ऑब्जेक्ट

सबसे पहले संभवतः आप Direct Messages की नई ऑब्जेक्ट संरचना पर ध्यान देंगे। यह नई Message Create ऑब्जेक्ट संरचना Quick Replies और Attachments जैसी नई क्षमताओं के समर्थन के लिए पेश की गई है। इस नए ऑब्जेक्ट में एक छोटा, संक्षिप्त user ऑब्जेक्ट भी शामिल है। इस नई ऑब्जेक्ट संरचना को ध्यान में रखते हुए, parsing के दौरान और संभवतः data models या storage में भी आपकी ऐप को अपडेट करना होगा। प्रत्येक property के विवरण के लिए Message Create Object पर पूर्ण दस्तावेज़ देखें। उदाहरण message create ऑब्जेक्ट

{
      "type": "message_create",
      "id": "1234858592",
      "created_timestamp": "1392078023603",
      "initiated_via": {
        "tweet_id": "123456",
        "welcome_message_id": "456789"
      },
      "message_create": {
        "target": {
          "recipient_id": "1234858592"
        },
        "sender_id": "3805104374",
        "source_app_id": "268278",
        "message_data": {
          "text": "Blue Bird",
          "entities": {
            "hashtags": [],
            "symbols": [],
            "urls": [],
            "user_mentions": [],
          },
          "quick_reply_response": {
            "type": "options",
            "metadata": "external_id_2"
          },
          "attachment": {
            "type": "media",
            "media": {
             ...
            }
          }
        }
      }

सारांश

पूरी तरह नई Direct Message ऑब्जेक्ट संरचना।
संक्षिप्त यूज़र ऑब्जेक्ट।
नई जानकारी जोड़ी गई है (quick reply रिस्पॉन्स, अटैचमेंट्स आदि)।

Direct Messages भेजना

POST direct_messages/events/new Direct Messages भेजने के लिए सीधा प्रतिस्थापन है। इस endpoint में सबसे महत्वपूर्ण अंतर यह है कि अब सारी जानकारी अलग-अलग POST params की बजाय POST request body में JSON के रूप में भेजी जाती है। Twurl अनुरोध का उदाहरण

twurl -A 'Content-type: application/json' -X POST /1.1/direct\_messages/events/new.json -d '{"event": {"type": "message\_create", "message\_create": {"target": {"recipient\_id": "4534871"}, "message_data": {"text": "Hello World!"}}}}'

ऊपर दिए गए अनुरोध में ध्यान दें कि content-type को application/x-www-form-urlencoded के बजाय application/json पर सेट किया गया है। साथ ही, यदि आप OAuth 1.0a signature बना रहे हैं, तो ध्यान दें कि signature जनरेट करते समय JSON body को शामिल नहीं किया जाता। ज़्यादातर OAuth लाइब्रेरी पहले से ही इसका ध्यान रखती हैं। यदि आप twurl का उपयोग कर रहे हैं, तो सुनिश्चित करें कि आप कम से कम संस्करण 0.9.3 का उपयोग कर रहे हैं।

सारांश

संदेश JSON POST बॉडी में परिभाषित किया जाता है
Content-type हेडर को application/json पर सेट किया जाना चाहिए
OAuth signature के जनरेशन में JSON बॉडी शामिल नहीं होती।

Direct Message प्राप्त करना

पुराने Direct Message अब एक ही API endpoint से प्राप्त किए जा सकते हैं: GET direct_messages/events/list. इस नए endpoint में महत्वपूर्ण अंतर यह है कि अब यह भेजे गए और प्राप्त हुए, दोनों तरह के संदेशों को उल्टे कालानुक्रमिक क्रम में रिटर्न करता है। इससे किसी बातचीत को फिर से तैयार करना आसान हो सकता है। हालांकि, अगर आप केवल भेजे गए या केवल प्राप्त संदेश ढूंढ रहे हैं, तो आपको sender_id प्रॉपर्टी के आधार पर रिस्पॉन्स को post-process करना होगा। अब पेजिनेशन Direct Message के ID के बजाय cursor मान पर आधारित है। हर रिस्पॉन्स के साथ एक cursor प्रॉपर्टी रिटर्न की जाती है। GET direct_messages/events/list पिछले 30 दिनों तक के संदेश रिटर्न करेगा, चाहे उन 30 दिनों में कितने भी संदेश मौजूद हों। जब cursor रिटर्न नहीं किया जाता है, तो इसका मतलब है कि रिटर्न करने के लिए कोई और संदेश नहीं हैं। GET direct_messages/events/show के साथ अलग-अलग Direct Message तक पहुंचने की विधि पहले जैसी ही रहती है, हालांकि रिटर्न किए गए Direct Message object की संरचना, जैसा पहले बताया गया है, अलग होती है। अंत में, Direct Message तक रीयल-टाइम पहुंच अब Account Activity API के साथ webhook के माध्यम से प्राप्त की जाएगी। User Streams या Site Streams से migrate करने के मार्गदर्शन के लिए, अधिक जानकारी हेतु Account Activity API की migration guide देखें।

सारांश

अब भेजे गए और प्राप्त संदेश उसी endpoint से लौटाए जाते हैं।
अधिकतम 30 दिनों तक के संदेश लौटाए जाते हैं।
Cursor-आधारित pagination।
Webhook के माध्यम से Direct Message तक रीयल-टाइम पहुँच।

Direct Messages हटाना

Direct Messages को अब DELETE direct_messages/events/destroy से हटाया जा सकता है। इंटरफ़ेस अधिकांशतः वही है और हटाए जाने वाले संदेश की ID की आवश्यकता होती है। मुख्य अंतर यह है कि अब endpoint में POST request के बजाय DELETE request की आवश्यकता होती है। आधिकारिक X clients में हटाए गए Direct Messages जिस तरह दिखाई देते हैं, वह पहले जैसा ही रहता है। Direct Messages केवल दिए गए user context के इंटरफ़ेस से हटाए जाते हैं। बातचीत के अन्य सदस्य अब भी उस Direct Message तक पहुँच सकते हैं।

सारांश

किसी Direct Message को हटाने के लिए ID की आवश्यकता होती है।
नए endpoint के लिए DELETE अनुरोध की आवश्यकता होती है।
हटाए गए Direct Messages आधिकारिक X clients में कैसे दिखाई देते हैं, यह पहले जैसा ही रहता है।

**नए Direct Message endpoints पर माइग्रेट करने के बारे में कोई प्रश्न है? **अपना प्रश्न devcommunity.com पर developer community forum में पोस्ट करें।

अक्सर पूछे जाने वाले प्रश्न

सामान्य

Account Activity API का उपयोग करने के क्या फायदे हैं? Account Activity API webhooks का उपयोग करता है। इसका मतलब यह है कि streaming APIs के विपरीत, आपको जानकारी भेजने के लिए हमारे लिए आपके पास कोई खुला कनेक्शन बनाए रखना जरूरी नहीं है। Webhooks, REST APIs से भी अलग हैं, क्योंकि जिस डेटा की आपको ज़रूरत है उसे पाने के लिए आपको हर 15 मिनट में हमें सैकड़ों बार pull नहीं करना पड़ता। इससे उपयोगकर्ता और आपके ऐप के बीच कार्यक्षमता बढ़ती है, क्योंकि डेटा घटना के समय ही पहुँच जाता है। Account Activity API के कई फायदे हैं:

गति: हम X की गति से डेटा पहुँचाते हैं।
सरलता: हम एक ही webhook कनेक्शन के ज़रिए किसी अकाउंट की सभी events पहुँचाते हैं। API के माध्यम से भेजी जाने वाली गतिविधियों में पोस्ट्स, @mentions, replies, Retweets, Quote Tweets, Quote Tweets के Retweets, favorites, भेजे गए Direct Messages, प्राप्त Direct Messages, follows, blocks, और mutes शामिल हैं।
स्केल: event caps की किसी भी रेट लिमिट्स से सीमित हुए बिना, आप अपने प्रबंधित अकाउंट की सभी गतिविधियाँ प्राप्त करते हैं।

Account Activity API premium sandbox, premium paid, और enterprise offering के रूप में उपलब्ध है, ताकि liability features या अतिरिक्त functionality के लिए जैसे-जैसे आपको अधिक अकाउंट्स की आवश्यकता हो, आप उसी अनुसार स्केल कर सकें। शुरू करने के लिए, GitHub से sample code snippets डाउनलोड करें। मैं कैसे पहचानूँ कि मेरे लिए कौन-सा product tier सबसे उपयुक्त है? Premium विकल्पों और Enterprise विकल्प के बीच के अंतर के बारे में अधिक जानने के लिए कृपया हमारा Account Activity API Overview पृष्ठ पढ़ें। Premium environment और Enterprise webhook में क्या अंतर है? कोई अंतर नहीं है। प्रत्येक Premium environment का अपना webhook_id होगा। मुझे Account Activity API के लिए development, staging और production environment चाहिए, क्या यह संभव है? हाँ! Account Activity API के paid tiers (Paid Premium और Enterprise) के साथ, कई webhook URLs रजिस्टर करना और API methods के माध्यम से प्रत्येक के लिए subscriptions को अलग-अलग प्रबंधित करना संभव है। इसके अलावा, आपके वर्तमान authorized users के लिए authorization बनाए रखने हेतु कई client apps को allowlist में जोड़ा जा सकता है। क्या आपके पास Account Activity API को सेट अप करने के लिए कोई step-by-step guides हैं? हाँ, बिल्कुल हैं!

यदि आप अभी शुरुआत कर रहे हैं, तो हम अनुशंसा करते हैं कि आप हमारी Getting started with webhooks guide देखें
X Dev द्वारा समर्थित scripts के साथ आगे बढ़ें:
- Account Activity API dashboard, एक node web ऐप जो webhook events दिखाता है।
- SnowBot chatbot, Account Activity और Direct Message APIs पर बना एक Ruby web ऐप। इस code base में Account Activity API webhooks सेट अप करने में मदद के लिए एक script भी शामिल है।

यदि हमारा system कुछ समय के लिए बंद हो जाए, तो क्या डेटा पुनर्प्राप्त करने का कोई तरीका है? Account Activity API के paid tiers (Paid Premium और Enterprise) के साथ, हमारा system चार घंटे की अवधि में कई बार गतिविधियाँ आपको फिर से भेजने का retry करेगा। यदि आपका system उस चार घंटे की अवधि के भीतर रिस्पॉन्स नहीं देता, तो गतिविधि खो जाएगी और 7 दिनों के भीतर डेटा पुनर्प्राप्त करने के लिए आपको अन्य REST endpoints का उपयोग करना होगा। हम सुझाव देते हैं कि यदि आपके किसी एक system के बंद हो जाने पर भी आप कोई गतिविधि न चूकें, तो redundancy tool के रूप में आप अपने अलग-अलग webhooks, या environments, का उपयोग Account Activity Replay API की तरह करें। Account Activity API के साथ मुझे किस authentication का उपयोग करना होगा? Account Activity API के लिए आवश्यक authorization methods का विवरण API संदर्भ pages में प्रत्येक method के अनुसार दिया गया है। यदि आप X authentication के साथ अभी शुरुआत कर रहे हैं, तो हम अनुशंसा करते हैं कि आप this section पढ़ें। challenge-response check (CRC) क्या है? Account Activity API चैलेंज रिस्पॉन्स जांच एक सुरक्षा सुविधा है, जिसे यह सुनिश्चित करने के लिए लागू किया गया है कि Account Activity API की गतिविधियाँ सही डेवलपर को भेजी जा रही हैं। डेवलपर इसका उपयोग यह सुनिश्चित करने के लिए भी कर सकते हैं कि उन्हें जो डेटा मिल रहा है, वह X से आ रहा है। X आपके webhook URL पर हर 24 घंटे में स्वतः एक CRC भेजेगा। यह अंतराल उस समय से शुरू होता है जब webhook URL का पिछली बार सत्यापन किया गया था। सत्यापित बने रहने के लिए, आपके सिस्टम को 3 सेकंड के भीतर एक वैध रिस्पॉन्स देना होगा। ज़्यादा जानकारी के लिए कृपया हमारा वेबहुक्स को सुरक्षित करना पेज देखें। क्या ऐसी कोई स्थिति है जिससे मेरा webhook URL तुरंत अमान्य हो जाएगा? अगर नीचे दी गई स्थितियों में से कोई एक होती है, तो हम आपके webhook को तुरंत अमान्य के रूप में चिह्नित कर देंगे:

सर्वर किसी CRC के जवाब में गलत टोकन लौटाता है। इस स्थिति में, हमारा सिस्टम आपको गतिविधि भेजने के लिए पुनः प्रयास नहीं करेगा।
webhook URL पर गलत certificate कॉन्फ़िगर किया गया है। इस स्थिति में भी, हमारा सिस्टम आपको गतिविधि भेजने के लिए पुनः प्रयास नहीं करेगा।
आपका सर्वर non-2XX, non-4XXX, non-5XXX रिस्पॉन्स कोड लौटाता है।
आप gzip के उपयोग को निर्दिष्ट करते हैं, लेकिन वास्तव में उसे भेजते नहीं हैं।
आप gzip के उपयोग को निर्दिष्ट नहीं करते, लेकिन वास्तव में उसे रिस्पॉन्स में भेजते हैं।

यदि मैं ऐसे उपयोगकर्ताओं की सदस्यता लेता हूँ जो एक-दूसरे के साथ इंटरैक्ट कर रहे हैं, तो क्या मुझे डुप्लिकेट गतिविधियाँ मिलेंगी? हाँ। यदि आपके web app में User A और User B, दोनों के लिए सक्रिय सदस्यता हैं, और User A किसी पोस्ट में User B का उल्लेख करता है, तो पंजीकृत webhook पर दो POST गतिविधियाँ भेजी जाएँगी। हर गतिविधि में “for_user_id” नाम का एक संकेतक होगा, जो यह बताएगा कि वह गतिविधि किस सदस्यता से संबंधित है। **जब मैं अपने webhook के लिए subscription बनाता हूँ, तो क्या API द्वारा डिलीवर की जाने वाली गतिविधियों को सीमित करने के लिए मैं नीचे दिए गए endpoint के /all/ हिस्से को अन्य account activity data objects से बदल सकता हूँ? **POST https://api.x.com/1.1/account_activity/all/:env_name/subscriptions.json नहीं, यह संभव नहीं है। अभी केवल /all/ product ही उपलब्ध है। **क्या उपयोगकर्ताओं से Direct Messages permissions का अनुरोध किए बिना Account Activity API का उपयोग करने का कोई तरीका है? ** फ़िलहाल, Direct Messages permissions आवश्यक हैं क्योंकि इस API के लिए Direct Messages गतिविधियों को ‘filter out’ करने का कोई तरीका नहीं है। क्या Account Activity API का कोई sandbox संस्करण है? हाँ, हम परीक्षण के लिए sandbox विकल्प उपलब्ध कराते हैं। हमारा sandbox विकल्प केवल एक webhook तक सीमित है, और इसमें अधिकतम 15 सदस्यताओं की सीमा है। sandbox विकल्प के बारे में अधिक जानकारी आप हमारे documentation में पढ़ सकते हैं। **क्या subscribed users का उल्लेख करने वाले पोस्ट्स के Retweets पाने के लिए Account Activity API का उपयोग किया जा सकता है? ** दुर्भाग्य से, यह इस API द्वारा डिलीवर की जाने वाली गतिविधियों का हिस्सा नहीं है। इसके लिए, हम Streaming API का उपयोग करने का सुझाव देते हैं। tweet_create_event द्वारा दर्शाए जाने वाले संभावित activity types क्या हैं? निम्न स्थितियों में tweet_create_event payload भेजा जाएगा: यदि subscription user इनमें से कोई कार्रवाई करता है:

एक पोस्ट बनाता है
Retweet करता है
किसी पोस्ट का जवाब देता है

यदि कोई दूसरा उपयोगकर्ता:

subscription user को @mentions* करता है
subscription user द्वारा बनाए गए Tweet को Quote करता है

*ध्यान दें: Account Activity API केवल तब events डिलीवर करता है जब subscription user को X से notification मिलता हो और वह उस event को सार्वजनिक रूप से देख सकता हो। इसका मतलब है कि अगर उल्लेख किया गया खाता (@userA), protected account (@userB) को follow करता है, तो UserA को UserB द्वारा उसका उल्लेख किए जाने का notification मिलेगा। अगर UserA, UserB को follow नहीं कर रहा है (और UserB द्वारा approved भी नहीं है), तो UserA को notification नहीं मिलेगा, और इसलिए यदि @userA की subscription होती, तो AAA के माध्यम से tweet_create_event नहीं भेजा जाता। यदि कोई blocked user मेरे subscribed user का उल्लेख करता है, तो मैं इसे कैसे पहचान सकता हूँ? आपको json रिस्पॉन्स के top level पर user_has_blocked नाम का एक boolean field दिखाई देगा, जो “true” या “false” पर सेट होगा। यह field केवल पोस्ट mentions पर दिखाया जाता है। Enterprise मैं अपने ऐप को allowlist में कैसे जोड़ सकता हूँ, या कैसे जाँच सकता हूँ कि मेरा ऐप पहले से allowlist में है या नहीं? Enterprise APIs के ज़रिए एक्सेस के लिए allowlist में जोड़े गए X ऐप्स को मैनेज करने के लिए, कृपया अपने ऐप ID के साथ अपने अकाउंट मैनेजर से संपर्क करें। अपना ऐप ID आप डेवलपर कंसोल में “Apps” पेज पर जाकर ढूँढ सकते हैं। यदि मेरे पास तीन webhooks का एक्सेस है, तो क्या मैं enterprise उपयोग के लिए रजिस्टर किए गए अपने हर ऐप के लिए तीन webhooks इस्तेमाल कर सकता हूँ? webhook की सीमा ऐप स्तर पर नहीं, बल्कि अकाउंट स्तर पर तय होती है। अगर आपके पास तीन webhooks का एक्सेस है और enterprise उपयोग के लिए दो ऐप रजिस्टर हैं, तो आप एक ऐप पर दो webhooks और दूसरे ऐप पर तीसरा webhook इस्तेमाल कर सकते हैं, लेकिन हर ऐप पर तीन-तीन नहीं। क्या मैं यह तय कर सकता हूँ कि Account Activity Replay API का उपयोग करके किस प्रकार के events फिर से डिलीवर किए जाएँगे? फिर से चलाए जाने वाले events के प्रकार तय नहीं किए जा सकते। तय की गई दिनांक और समय विंडो के दौरान डिलीवर किए गए सभी events फिर से चलाए जाएँगे। अगर मेरा application किसी Account Activity Replay API event को ingest नहीं कर पाता है, तो क्या कोई retries होंगी? नहीं, कोई retries नहीं होंगी। अगर कोई application, Account Activity Replay API द्वारा भेजे गए किसी event को ingest नहीं कर पाता है, तो छूटे हुए Replay events को फिर से डिलीवर करने की कोशिश के लिए उसी समयावधि के लिए एक और Replay job सबमिट की जा सकती है। जब मुझे partial success completion event मिले, तो मुझे क्या करना चाहिए? हम सुझाव देते हैं कि जो events प्राप्त हुए थे उनके timestamps नोट कर लें और जो events छूट गए थे उनके लिए एक और Replay job का अनुरोध करें। एक समय में मेरे कितने Account Activity Replay API jobs चल सकते हैं? हर webhook पर एक समय में केवल एक Account Activity Replay API job चल सकती है। जब Account Activity Replay API events मेरे webhook पर डिलीवर किए जा रहे हों, तो मैं उन्हें real-time production events से कैसे अलग पहचान सकता हूँ? चूँकि Account Activity Replay API हमेशा पिछले events डिलीवर करता है, इसलिए उन्हें event के timestamp के आधार पर real-time production events से अलग पहचाना जा सकता है। मेरे application द्वारा छोड़ी गई या छूट गई किसी activity को फिर से डिलीवर करने के लिए मैं Account Activity Replay API का उपयोग कितनी जल्दी शुरू कर सकता हूँ? कोई activity बनाए जाने के लगभग 10 मिनट बाद redelivery के लिए उपलब्ध हो जाती है।

त्रुटि निवारण मार्गदर्शिका

Code 32

इस त्रुटि का आम तौर पर मतलब है कि आपके द्वारा निर्दिष्ट request, headers, authorization, या URL में कुछ गलत तरीके से बना है। यह Account Activity API की त्रुटि नहीं है; यह authorization त्रुटि है, और X को सही OAuth सेटअप या URL नहीं मिल रहा है।

Enterprise - सुनिश्चित करें कि आप जिन consumer keys और access tokens का उपयोग कर रहे हैं, वे ऐसे X ऐप से संबंधित हों जो Enterprise products के उपयोग के लिए पंजीकृत है। अगर आपके पास अपनी consumer keys और access tokens नहीं हैं, या आपको अपने X ऐप को allowlist में जोड़ना है, तो कृपया अपने account manager से संपर्क करें।
अगर आप user context के साथ authenticate कर रहे हैं, तो सुनिश्चित करें कि आपने सही oauth nonce, oauth_signature, और oauth_timestamp के साथ अपने request को properly authorize किया है।
सुनिश्चित करें कि आपके access tokens के पास सही permission level है।
- app dashboard में ‘Keys and tokens’ tab पर, कृपया सुनिश्चित करें कि आपके access tokens का permission level ‘Read, write, and direct messages’ है।
- अगर tokens का permission level इससे कम पर सेट है, तो कृपया ‘Permissions’ tab पर जाएँ, access permission को ‘Read, write, and direct messages’ पर सेट करें, फिर ‘Keys and tokens’ tab से अपने access tokens और secret को दोबारा generate करें।
सुनिश्चित करें कि आपका URL सही तरीके से बना हुआ है।
- कृपया ध्यान रखें कि :env_name case-sensitive है।

कोड 200 - निषिद्ध

Premium - API को अनुरोध भेजने का प्रयास करने से पहले सुनिश्चित करें कि आपके पास स्वीकृत डेवलपर खाता हो। आपको अनुरोध में सही :env_name का भी उपयोग करना होगा, जिसे आप dev environments पेज पर कॉन्फ़िगर कर सकते हैं।
Enterprise - सुनिश्चित करें कि आपके अकाउंट मैनेजर ने आपको Account Activity API का एक्सेस दिला दिया है।
सुनिश्चित करें कि आपने अपना URI सही तरीके से कॉन्फ़िगर किया है। अगर आपने अपने अनुरोध में गलत URI दर्ज किया है, तो यह त्रुटि आ सकती है।

Code 214 - Webhook URL आवश्यकताओं को पूरा नहीं करती है।

कृपया सुनिश्चित करें कि आप https का उपयोग कर रहे हैं।
आपकी webhook URL का फ़ॉर्मैट गलत हो सकता है।
Getting started with webhooks पेज पर Develop webhook consumer app अनुभाग में अपनी webhook URL सेट अप करने के बारे में अधिक जानें।

कोड 214 - CRC GET अनुरोध पर उच्च विलंबता। आपके webhook को 3 सेकंड से कम समय में जवाब देना चाहिए।

इसका मतलब है कि आपका सर्वर धीमा है। सुनिश्चित करें कि आप CRC अनुरोध का जवाब 3 सेकंड के भीतर दे रहे हैं।

Code 214 - CRC GET अनुरोध के दौरान Non-200 रिस्पॉन्स कोड (जैसे 404, 500 आदि)।

आपका सर्वर डाउन है। सुनिश्चित करें कि आपका सर्वर ठीक से चल रहा है।

कोड 214 - पहले से ही बहुत अधिक संसाधन बनाए जा चुके हैं।

Enterprise - आप अपने सभी webhook पहले ही इस्तेमाल कर चुके हैं। यह पता लगाने के लिए कि आपके webhook कहाँ वितरित हैं, अपने प्रत्येक पंजीकृत ऐप के लिए GET webhooks endpoint का उपयोग करें।

कोड 261 - एप्लिकेशन लिखने से संबंधित कार्रवाइयाँ नहीं कर सकता।

API के साथ आप जिस ऐप का उपयोग कर रहे हैं, उसके access token और access token secret के लिए सही अनुमति स्तर सेट नहीं है। कृपया X apps डैशबोर्ड में ‘Keys and tokens’ टैब पर जाएँ और अपने access token और access token secret को दिए गए अनुमति स्तरों की जाँच करें। यदि यह ‘Read, write and Direct Messages’ के अलावा किसी अन्य विकल्प पर सेट है, तो आपको ‘Permission’ टैब के अंतर्गत सेटिंग्स बदलनी होंगी और नई सेटिंग्स लागू करने के लिए अपना access token और access token secret फिर से जनरेट करना होगा।
वैकल्पिक रूप से, हो सकता है कि आप app-only authentication का उपयोग करके webhook रजिस्टर करने की कोशिश कर रहे हों, जो समर्थित नहीं है। इसके बजाय user context के साथ authenticate करें, जैसा कि Enterprise Account Activity API के लिए webhook रजिस्टर करने वाले API संदर्भ अनुभागों में बताया गया है।

Account Activity API संदर्भ इंडेक्स


उद्देश्य	Enterprise
एक webhook URL पंजीकृत करता है / एक webhook_id उत्पन्न करता है	POST webhooks
सभी webhook URL और उनकी स्थितियाँ लौटाता है	GET webhooks
चैलेंज रिस्पॉन्स जांच को मैन्युअल रूप से ट्रिगर करता है	PUT webhooks/:webhook_id
किसी ऐप को किसी अकाउंट की गतिविधियों के लिए सब्सक्राइब करता है	POST webhooks/:webhook_id/subscriptions/all
वर्तमान में सक्रिय सदस्यताओं की संख्या लौटाता है	GET subscriptions/count
यह जांचता है कि कोई webhook किसी अकाउंट के लिए सब्सक्राइब है या नहीं	GET webhooks/:webhook_id/subscriptions/all
वर्तमान में सक्रिय सदस्यताओं की सूची लौटाता है	GET webhooks/:webhook_id/subscriptions/all/list
webhook को हटाता है	DELETE webhooks/:webhook_id
3-legged OAuth का उपयोग करके किसी सदस्यता को निष्क्रिय करता है (DEPRECATED)	DELETE webhooks/:webhook_id/subscriptions/all
application-only OAuth का उपयोग करके किसी सदस्यता को निष्क्रिय करता है	DELETE webhooks/:webhook_id/subscriptions/:user_id/all.json
गतिविधियों को फिर से किसी webhook पर डिलीवर करता है	POST replay/webhooks/:webhook_id/subscriptions/all

Enterprise अकाउंट एक्टिविटी API

POST account_activity/webhooks

दिए गए ऐप संदर्भ के लिए एक नया webhook URL पंजीकृत करता है। सहेजने से पहले URL को CRC अनुरोध के माध्यम से सत्यापित किया जाएगा। यदि सत्यापन विफल हो जाता है, तो अनुरोधकर्ता को विस्तृत त्रुटि संदेश लौटाता है। अनुमत webhook की संख्या बिलिंग पैकेज के अनुसार निर्धारित होती है।

संसाधन URL

https://api.x.com/1.1/account_activity/webhooks.json

संसाधन जानकारी


रिस्पॉन्स प्रारूप	JSON
प्रमाणीकरण आवश्यक	हाँ (उपयोगकर्ता संदर्भ - सभी consumer और access token)
रेट लिमिट लागू	हाँ
अनुरोध / 15-मिनट विंडो (उपयोगकर्ता auth)	15
Tweet संपादनों के लिए समर्थन	सभी Tweet ऑब्जेक्ट्स में Tweet के संपादन इतिहास का वर्णन करने वाला Tweet edit metadata शामिल होगा। अधिक जानकारी के लिए “Tweet edits” fundamentals पेज देखें।

पैरामीटर


url (required)	कॉलबैक एंडपॉइंट के लिए एन्कोड किया हुआ URL।

उदाहरण अनुरोध

$ curl —request POST —url ‘https://api.x.com/1.1/account_activity/webhooks.json?url=https%3A%2F%2Fyour_domain.com%2Fwebhooks%2Ftwitter%2F0' —header ‘authorization: OAuth oauth_consumer_key=“CONSUMER_KEY”, oauth_nonce=“GENERATED”, oauth_signature=“GENERATED”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“GENERATED”, oauth_token=“ACCESS_TOKEN”, oauth_version=“1.0“‘

HTTP रिस्पॉन्स

HTTP Code	संदेश
200	Webhook URL दिए गए ऐप के लिए पंजीकृत है
403	आपके अनुरोध में त्रुटि है। नीचे दिया गया त्रुटि संदेश अनुभाग देखें।

उदाहरण रिस्पॉन्स - सफल

_HTTP 200_

    {
      "id": "1234567890",
      "url": "https://your_domain.com/webhook/twitter/0",
      "valid": true,
      "created_at": "2016-06-02T23:54:02Z"
    }

त्रुटि संदेश

कोड	संदेश
214	Webhook URL आवश्यकताओं को पूरा नहीं करता।
214	बहुत अधिक संसाधन पहले ही बनाए जा चुके हैं।
214	Webhook URL आवश्यकताओं को पूरा नहीं करता। अमान्य CRC टोकन या JSON रिस्पॉन्स प्रारूप।
214	CRC GET अनुरोध पर लेटेंसी अधिक है। आपके webhook को 3 सेकंड से कम समय में जवाब देना चाहिए।
214	CRC GET अनुरोध के दौरान गैर-200 रिस्पॉन्स कोड (जैसे 404, 500 आदि)।

HTTP 403

    {
      "errors": [
        {
          "code": 214,
          "message": "Too many resources already created."
        }
      ]
    }

GET account_activity/webhooks

दिए गए ऐप के लिए सभी URL और उनकी स्थितियाँ रिटर्न करता है। यदि कोई URL दैनिक वैधता जांच में विफल हो जाता है, तो हम उसे अमान्य के रूप में चिह्नित करते हैं। URL को फिर से सक्षम करने के लिए, update endpoint को कॉल करें।

संसाधन URL

https://api.x.com/1.1/account_activity/webhooks.json

संसाधन जानकारी


रिस्पॉन्स प्रारूप	JSON
प्रमाणीकरण आवश्यक है	हाँ (केवल ऐप - बेयरर टोकन)
रेट लिमिट लागू	हाँ
अनुरोध / 15-मिनट की विंडो (ऐप प्रमाणीकरण)	15

उदाहरण अनुरोध

    $ curl --request GET
     --url https://api.x.com/1.1/account_activity/webhooks.json
     --header 'authorization: Bearer TOKEN'

उदाहरण रिस्पॉन्स

HTTP 200 OK

    [
      {
        "id": "1234567890",
        "url": "https://your_domain.com/webhook/twitter/0",
        "valid": true,
        "created_at": "2016-06-02T23:54:02Z"
      }
      {
        "id": "2468013579",
        "url": "https://your_domain2.com/webhook/twitter/0",
        "valid": true,
        "created_at": "2016-06-04T22:31:29Z"
      }
    ]

त्रुटि संदेश

कोड	संदेश
99	आपके पास इस संसाधन तक पहुँच नहीं है।

PUT account_activity/webhooks/:webhook_id

दिए गए webhook के URL के लिए चैलेंज रिस्पॉन्स जांच (CRC) ट्रिगर करता है। अगर जाँच सफल होती है, तो यह 204 रिटर्न करता है और उसकी status को valid पर सेट करके webhook को फिर से सक्षम कर देता है।

संसाधन URL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json

संसाधन जानकारी


रिस्पॉन्स फ़ॉर्मैट	JSON
प्रमाणीकरण आवश्यक है	हाँ (उपयोगकर्ता संदर्भ - सभी consumer और access टोकन)
दर-सीमा लागू	हाँ
अनुरोध / 15-मिनट विंडो (उपयोगकर्ता प्रमाणीकरण)	15

पैरामीटर


webhook_id (required)	Webhook ID. संसाधन पथ में परिभाषित है।

उदाहरण अनुरोध

    $ curl --request PUT
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
     --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'

रिस्पॉन्स

HTTP 204 OK

{ }

त्रुटि संदेश

कोड	संदेश
34	Webhook मौजूद नहीं है या किसी दूसरे X ऐप से संबद्ध है।
214	Webhook URL आवश्यकताओं को पूरा नहीं करता।
214	Webhook URL आवश्यकताओं को पूरा नहीं करता। CRC token या json response प्रारूप अमान्य है।
214	CRC GET अनुरोध में विलंबता अधिक है। आपके webhook को 3 सेकंड से कम समय में रिस्पॉन्स देना चाहिए।
214	CRC GET अनुरोध के दौरान non-200 रिस्पॉन्स कोड मिला (जैसे 404, 500, आदि)।

POST account_activity/webhooks/:webhook_id/subscriptions/all

दिया गया ऐप, दिए गए उपयोगकर्ता संदर्भ में, सभी संदेश प्रकारों के लिए सभी गतिविधियों की सदस्यता लेता है। सक्रिय होने के बाद, अनुरोध करने वाले उपयोगकर्ता की सभी गतिविधियाँ, POST request के माध्यम से ऐप के webhook पर भेजे जाएंगे। सदस्यताएँ वर्तमान में आपके account configuration के आधार पर सीमित हैं। यदि आपको और सदस्यताएँ जोड़ने की आवश्यकता है, तो कृपया अपने account manager से संपर्क करें।

संसाधन URL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

संसाधन जानकारी


रिस्पॉन्स प्रारूप	JSON
प्रमाणीकरण आवश्यक	हाँ (3-legged OAuth - श्वेत-सूचीबद्ध consumer key और सदस्यता लेने वाले उपयोगकर्ता का access token)
रेट लिमिट लागू	हाँ
अनुरोध / 15-मिनट विंडो (user auth)	500

पैरामीटर


webhook_id (आवश्यक)	Webhook ID. रिसोर्स पथ में परिभाषित.

उदाहरण अनुरोध

    $ curl --request POST
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
     --header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBING_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

उदाहरण रिस्पॉन्स - सफलता

HTTP 204 NO CONTENT

{}

त्रुटि संदेश

Code	संदेश
34	Webhook मौजूद नहीं है या किसी अन्य X ऐप से संबद्ध है।
348	क्लाइंट ऐप्लिकेशन को इस उपयोगकर्ता की Webhook सदस्यताओं तक पहुँचने की अनुमति नहीं है।

GET account_activity/subscriptions/count

यह उन सदस्यताओं की संख्या रिटर्न करता है जो वर्तमान में आपके खाते पर सक्रिय हैं। ध्यान दें कि /count endpoint के लिए केवल application-only OAuth आवश्यक है, इसलिए आपको user context के बजाय बेयरर टोकन का उपयोग करके अनुरोध करने चाहिए।

संसाधन URL

https://api.x.com/1.1/account_activity/subscriptions/count.json

संसाधन जानकारी


रिस्पॉन्स प्रारूप	HTTP रिस्पॉन्स कोड
प्रमाणीकरण आवश्यक	हाँ (केवल एप्लिकेशन - बेयरर टोकन)
रेट लिमिट लागू	हाँ
अनुरोध / 15-मिनट विंडो (एप्लिकेशन प्रमाणीकरण)	15

HTTP रिस्पॉन्स कोड


कोड	संदेश
200	सफल। अनुरोधित webhook के लिए सदस्यताओं की संख्या लौटाई जाएगी।
401	आपके ऐप को निर्दिष्ट webhook की सदस्यताएँ देखने की अनुमति नहीं है।

अनुरोध का उदाहरण

    $ curl --request GET
     --url https://api.x.com/1.1/account_activity/subscriptions/count.json
     --header 'authorization: Bearer TOKEN'

उदाहरण रिस्पॉन्स - सफलता

HTTP 200

    {
      "account_name":"my-account",
      "subscriptions_count_all":"1",
      "subscriptions_count_direct_messages":"0",
      "provisioned_count":"50"
    }

त्रुटि संदेश

कोड	संदेश
32	आपको प्रमाणित नहीं किया जा सका।

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "Could not authenticate you."
        }
      ]
    }

GET account_activity/webhooks/:webhook_id/subscriptions/all

यह पता लगाने का तरीका प्रदान करता है कि webhook configuration दिए गए उपयोगकर्ता के events के लिए subscribed है या नहीं। अगर दिए गए उपयोगकर्ता संदर्भ में दी गई एप्लिकेशन के साथ कोई active subscription है, तो यह 204 OK रिटर्न करता है। अगर रिस्पॉन्स कोड 204 नहीं है, तो उपयोगकर्ता के पास active subscription नहीं है। अधिक जानकारी के लिए नीचे दिए गए HTTP response code और error messages देखें।

संसाधन URL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

संसाधन जानकारी


रिस्पॉन्स प्रारूप	JSON
प्रमाणीकरण आवश्यक	हाँ (3-legged OAuth - whitelisted consumer key और subscribing user का access token)
रेट लिमिट लागू	हाँ
अनुरोध / 15-मिनट विंडो (user auth)	500

पैरामीटर


webhook_id (required)	Webhook ID. संसाधन पथ में परिभाषित.

उदाहरण अनुरोध

$ curl —request GET —url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json —header ‘authorization: OAuth oauth_consumer_key=“WHITELISTED_CONSUMER_KEY”, oauth_nonce=“GENERATED”, oauth_signature=“GENERATED”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“GENERATED”, oauth_token=“SUBSCRIBING_USER’S_ACCESS_TOKEN”, oauth_version=“1.0“‘

उदाहरण रिस्पॉन्स - सफलता

HTTP 204 कोई सामग्री नहीं

{ }

GET account_activity/webhooks/:webhook_id/subscriptions/all/list

निर्दिष्ट webhook के लिए मौजूदा All Activity प्रकार की सदस्यताओं की सूची लौटाता है। ध्यान दें कि /list एंडपॉइंट के लिए केवल एप्लिकेशन-only OAuth की आवश्यकता होती है, इसलिए अनुरोध उपयोगकर्ता संदर्भ के बजाय बेयरर टोकन का उपयोग करके किए जाने चाहिए।

संसाधन URL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all/list.json

संसाधन जानकारी


रिस्पॉन्स प्रारूप	HTTP रिस्पॉन्स कोड
प्रमाणीकरण आवश्यक	हाँ (केवल एप्लिकेशन - बेयरर टोकन)
रेट लिमिट लागू	हाँ
अनुरोध / 15-मिनट विंडो (एप्लिकेशन प्रमाणीकरण)	50

पैरामीटर


webhook_id (required)	Webhook ID. संसाधन पथ में परिभाषित है।

HTTP रिस्पॉन्स कोड

Code	Message
200	सफल। अनुरोधित webhook के लिए सदस्यताओं की सूची लौटाई जाएगी।
401	आपके एप्लिकेशन को निर्दिष्ट webhook की सदस्यताएँ देखने की अनुमति नहीं है।

अनुरोध का उदाहरण

$ curl —request GET —url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all/list.json —header ‘authorization: Bearer TOKEN’

उदाहरण रिस्पॉन्स - सफल

HTTP 200

    {
      "webhook_id": "1234567890",
      "webhook_url": "https://your_domain.com/webhook/twitter/0",
      "application_id": "11231812",
      "subscriptions": [{
        "user_id": "20212306"
      }]
    }

त्रुटि संदेश

कोड	संदेश
32	आपका प्रमाणीकरण नहीं हो सका।

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "Could not authenticate you."
        }
      ]
    }

DELETE account_activity/webhooks/:webhook_id

दिए गए एप्लिकेशन के कॉन्फ़िगरेशन से webhook को हटा देता है। webhook ID को GET /1.1/account_activity/webhooks पर कॉल करके प्राप्त किया जा सकता है।

संसाधन URL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json

संसाधन जानकारी


रिस्पॉन्स प्रारूप	JSON
प्रमाणीकरण आवश्यक	हाँ (उपयोगकर्ता संदर्भ - सभी कंज़्यूमर और एक्सेस टोकन)
रेट लिमिट लागू	हाँ
अनुरोध / 15-मिनट विंडो (उपयोगकर्ता प्रमाणीकरण)	15

पैरामीटर


webhook_id (required)	Webhook ID। रिसोर्स पाथ में निर्दिष्ट।

उदाहरण अनुरोध

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
     --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'

रिस्पॉन्स

HTTP 204 OK

{ }

DELETE account_activity/webhooks/:webhook_id/subscriptions/all (अप्रचलित)

दिए गए उपयोगकर्ता संदर्भ और एप्लिकेशन के लिए सदस्यता(ओं) को निष्क्रिय करता है। निष्क्रिय करने के बाद, अनुरोध करने वाले उपयोगकर्ता से संबंधित सभी ईवेंट अब webhook URL पर नहीं भेजे जाएंगे।

संसाधन URL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

संसाधन जानकारी


रिस्पॉन्स प्रारूप	JSON
प्रमाणीकरण आवश्यक है	हाँ (3-legged OAuth - श्वेतसूचीबद्ध consumer key और subscribed उपयोगकर्ता का access token)
रेट लिमिट लागू	हाँ
अनुरोध / 15-मिनट विंडो (उपयोगकर्ता auth)	500

पैरामीटर


webhook_id (required)	Webhook ID. संसाधन पथ में परिभाषित है।

अनुरोध का उदाहरण

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
     --header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBED_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

उदाहरण अनुरोध

{ }

DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json

निर्दिष्ट webhook और उपयोगकर्ता id के लिए सदस्यता निष्क्रिय करता है। निष्क्रिय करने के बाद, अनुरोध करने वाले उपयोगकर्ता के लिए सभी ईवेंट webhook URL पर भेजे नहीं जाएंगे। ध्यान दें कि इस endpoint के लिए केवल एप्लिकेशन-only OAuth आवश्यक है, इसलिए अनुरोध उपयोगकर्ता संदर्भ के बजाय बेयरर टोकन का उपयोग करके किए जाने चाहिए।

संसाधन URL

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json

संसाधन जानकारी


रिस्पॉन्स प्रारूप	JSON
प्रमाणीकरण आवश्यक है	हाँ (केवल ऐप - बेयरर टोकन)
रेट लिमिट लागू	हाँ
अनुरोध / 15-मिनट विंडो	500

उदाहरण अनुरोध

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
     --header 'authorization: Bearer TOKEN'

रिस्पॉन्स

HTTP 204 कोई सामग्री नहीं

त्रुटि संदेश

कोड	संदेश
404	क्षमा करें, वह पृष्ठ मौजूद नहीं है। - यह अक्सर तब होता है, जब निर्दिष्ट उपयोगकर्ता id ने वास्तव में सदस्यता नहीं ली होती है।

Replay API

POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json ¶ अनुरोध में निर्दिष्ट दिनांक और समय विंडो के दौरान मौजूद सभी सदस्यताओं से पिछले पाँच दिनों तक की गतिविधियाँ प्राप्त करने के लिए एक अनुरोध सबमिट करता है। यदि आपके webhook में सक्रिय user subscriptions हैं, तो आपको वे इवेंट भी साथ-साथ प्राप्त होंगे। ध्यान दें: replay events डिलीवर करने से पहले हम CRC करते हैं।


Request Method	HTTP POST
URL	/1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm
रिस्पॉन्स प्रारूप	JSON
Requires Authentication	हाँ (केवल एप्लिकेशन - बेयरर टोकन)
Rate Limit	प्रति 15 मिनट 5 अनुरोध। वर्तमान में अनुरोध किए जा सकने वाले replay jobs की संख्या पर कोई अधिकतम सीमा नहीं है।
from_date	सबसे पुराना (प्रारंभिक) UTC timestamp, जिससे इवेंट उपलब्ध कराए जाएँगे, ‘yyyymmddhhmm’ प्रारूप में होना चाहिए। Timestamp मिनट-स्तरीय है और समावेशी है (अर्थात 12:00 में 00 मिनट शामिल है)। मान्य समय पिछले 5 दिनों के भीतर, UTC समय में, और वर्तमान समय बिंदु से 31 मिनट से अधिक हाल का नहीं होना चाहिए। यह अनुशंसा की जाती है कि from_date और to_date के बीच का अंतर लगभग 2 घंटे के भीतर हो।
to_date	सबसे नया (समापन) UTC timestamp, तक जिसके लिए इवेंट उपलब्ध कराए जाएँगे, ‘yyyymmddhhmm’ प्रारूप में होना चाहिए। Timestamp मिनट-स्तरीय है और बहिष्कारी है (अर्थात 12:30 में घंटे का 30वाँ मिनट शामिल नहीं है)। मान्य समय पिछले 5 दिनों के भीतर, UTC समय में, और वर्तमान समय बिंदु से 10 मिनट से अधिक हाल का नहीं होना चाहिए।

रिस्पॉन्स

निम्नलिखित रिस्पॉन्स API द्वारा लौटाए जा सकते हैं। अधिकांश त्रुटि कोड, body में अतिरिक्त विवरण वाली एक string के साथ लौटाए जाते हैं। non-200 रिस्पॉन्स के लिए, आपको त्रुटि का समाधान करके फिर से प्रयास करना चाहिए।

Status	Text	Error Code	Description	Message
202	स्वीकार किया गया	N/A	अनुरोध सफल रहा और गतिविधियाँ भेजी जाएँगी।	N/A
400	गलत अनुरोध	214	Webhook को अमान्य के रूप में चिह्नित किया गया है।	Webhook अमान्य के रूप में चिह्नित है और इसके लिए CRC जाँच आवश्यक है।
400	गलत अनुरोध	357	Query parameter मौजूद नहीं है।	: queryParam आवश्यक है।
400	गलत अनुरोध	358	Route या query parameter गलत प्रारूप में है।	parameter को parse नहीं किया जा सका।
400	गलत अनुरोध	360	Route parameter ऋणात्मक है।	webhook_id: [] 0 के बराबर या उससे अधिक नहीं है।
400	गलत अनुरोध	368	from_date या to_date अतीत में नहीं है।	: [<field_value>] अतीत में नहीं है।
400	गलत अनुरोध	356	from_date, to_date से पहले होना चाहिए।	from_date, to_date से पहले होना चाहिए।
400	गलत अनुरोध	356	from_date पिछले 5 दिनों के भीतर होना चाहिए।	from_date पिछले 5 दिनों के भीतर होना चाहिए।
401	अनधिकृत	32	दिए गए 3-legged auth के कारण HTTP authentication विफल हुआ।	अमान्य authentication method. कृपया केवल एप्लिकेशन-only authentication का उपयोग करें।
401	अनधिकृत	61	Client को इस method का अनुरोध करने की अनुमति नहीं है।	Client को इस method का अनुरोध करने की अनुमति नहीं है।
403	निषिद्ध	200	Client के पास Replay सक्षम वाला enterprise account नहीं है।	replay के साथ Account Activity API enterprise account आवश्यक है। कृपया पुष्टि करें कि आपके पास enterprise account है और replay सक्षम है।
404	नहीं मिला	34	webhook_id मौजूद नहीं है; webhook_id-application_id मेल नहीं खाता।	Webhook मौजूद नहीं है या किसी अन्य X एप्लिकेशन से संबद्ध है।
409	टकराव	355	एक अनुरोध पहले से प्रगति में है और दूसरा अनुरोध करने से पहले उसका processing पूरा होना चाहिए।	इस webhook के लिए एक replay job पहले से प्रगति में है।
429	बहुत अधिक अनुरोध	88	Rate limit लागू हो गई (प्रति समयावधि अनुरोधों की संख्या की सीमा तक पहुँच गया)	बहुत अधिक अनुरोध। कृपया अपने API अनुरोध rate को कम करें।
500	आंतरिक सर्वर त्रुटि	0	आंतरिक सर्वर त्रुटि।	आंतरिक सर्वर त्रुटि।
503	सेवा अनुपलब्ध	67	X की एक या अधिक आश्रित सेवाएँ अनुपलब्ध हैं।	X server त्रुटि। exponential backoff pattern का उपयोग करके फिर से प्रयास करें।

“जॉब सफलतापूर्वक पूरा हुआ” संदेश

जब आपका जॉब सफलतापूर्वक पूरा हो जाता है, तो Account Activity Replay API नीचे दिया गया जॉब पूर्णता इवेंट भेजेगा। यह इवेंट मिलते ही समझें कि जॉब चलकर पूरा हो चुका है और अब दूसरा जॉब सबमिट किया जा सकता है।

{
  "replay\_job\_status": {
    "webhook_id": "1234577122340233217",
    "job_state": "Complete",
    "job\_state\_description": "Job completed successfully"
    "job_id": "1095098195724558337"
  }
}

“जॉब पूरा नहीं हुआ” संदेश

यदि आपका जॉब सफलतापूर्वक पूरा नहीं होता है, तो हम नीचे दिया गया संदेश लौटाएँगे, जो आपको अपना Replay जॉब फिर से चलाने के लिए कहेगा। यह इवेंट प्राप्त होने पर, जॉब चलना समाप्त हो चुका होगा और आप दूसरा जॉब सबमिट कर सकते हैं।

{
  "replay\_job\_status": {
    "webhook_id": "123451374207332352",
    "job_state": "Incomplete",
    "job\_state\_description": "Job failed to deliver all events, please retry your replay job",
    "job_id": "1093226942650736640"
  }
}

curl अनुरोध का उदाहरण

    curl --request POST  --url 'https://api.x.com/1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm'
    --header 'authorization: Bearer TOKEN'

उदाहरण रिस्पॉन्स

HTTP 202

{
  "job_id": "1234567890",
  "created_at": "2016-06-02T23:54:02Z"
}

​वीडियो श्रृंखला

​सुविधा सारांश

​वेबहुक और सब्स्क्राइब किए गए उपयोगकर्ताओं को प्रबंधित करें

​वेबहुक का प्रबंधन:

​सब्सक्राइब किए गए उपयोगकर्ताओं का प्रबंधन:

​संदर्भित लेख

​Account Activity API का वीडियो वॉकथ्रू

​वेबहुक्स के साथ शुरुआत करना

​1. एक X ऐप बनाएँ।

​2. Account Activity API एक्सेस प्राप्त करें

​3. वेबहुक कंज़्यूमर ऐप विकसित करें

​4. सेटअप सत्यापित करें

​वेबहुक को सुरक्षित बनाना

​Challenge-Response Checks

​CRC अनुरोध इन स्थितियों में होगा:

​रिस्पॉन्स आवश्यकताएँ:

​भाषा के अनुसार HMAC लाइब्रेरी:

​Python में उदाहरण रिस्पॉन्स टोकन जनरेशन:

​उदाहरण JSON रिस्पॉन्स:

​अन्य उदाहरण:

​वैकल्पिक सिग्नेचर हेडर सत्यापन

​अतिरिक्त सुरक्षा दिशानिर्देश

​X समेकित नेटवर्क ब्लॉक

​अनुशंसित सर्वर कॉन्फ़िगरेशन

​webhook और सदस्यताओं का प्रबंधन

​Webhook बनाना और बदलना

​Webhook कॉन्फ़िगरेशन प्रबंधन एंडपॉइंट:

​मैं webhook URL को सीधे अपडेट क्यों नहीं कर सकता?

​User सदस्यताएँ जोड़ना और हटाना

​सदस्यता प्रबंधन एंडपॉइंट्स

​पुनः प्रयास

​पुनः प्रयास क्या हैं?

​पुनः प्रयास समयरेखा

​पुनः प्रयास समयरेखा

​Account Activity डेटा ऑब्जेक्ट की संरचना

​tweet_create_events (पोस्ट्स, रीट्वीट्स, रिप्लाई, कोट ट्वीट्स)

​tweet_create_events (@मेंशन)

​favorite_events

​follow_events

​unfollow_events

​block_events

​unblock_events

​mute_events

​unmute_events

​user_event

​direct_message_events

​direct_message_indicate_typing_events

​direct_message_mark_read_events

​tweet_delete_events

​Account Activity Replay API

​Account Activity Replay API का उपयोग

​सीमाएँ

​डेटा उपलब्धता और प्रकार

​माइग्रेशन परिचय

​माइग्रेशन गाइड: User Streams/Site Streams से Account Activity API पर माइग्रेट करना

​परिवर्तनों का सारांश

​अप्रचलित API

​विकल्प API

​अंतर और माइग्रेशन संबंधी विचार

​नई सुविधाएँ

​उपयोगकर्ता सदस्यताओं का प्रबंधन

​माइग्रेशन कैसे करें

​Site Streams API से Account Activity API पर आसानी से माइग्रेट करने के लिए नीचे दिए गए चरणों का पालन करें

​Account Activity डैशबोर्ड (नमूना Account Activity API ऐप)

​उपलब्ध गतिविधियाँ

​अप्रचलित स्ट्रीमिंग संदेश प्रकार

​अप्रचलित इवेंट प्रकार

​Direct Message माइग्रेशन मार्गदर्शिका

​बदलावों का सारांश

​नई सुविधाएँ

​अंतर और माइग्रेशन संबंधी बातें

​नया Direct Message ऑब्जेक्ट

​सारांश

​Direct Messages भेजना

​सारांश

​Direct Message प्राप्त करना

​सारांश

​Direct Messages हटाना

​सारांश

​अक्सर पूछे जाने वाले प्रश्न

वीडियो श्रृंखला

सुविधा सारांश

वेबहुक और सब्स्क्राइब किए गए उपयोगकर्ताओं को प्रबंधित करें

वेबहुक का प्रबंधन:

सब्सक्राइब किए गए उपयोगकर्ताओं का प्रबंधन:

संदर्भित लेख

Account Activity API का वीडियो वॉकथ्रू

वेबहुक्स के साथ शुरुआत करना

1. एक X ऐप बनाएँ।

2. Account Activity API एक्सेस प्राप्त करें

3. वेबहुक कंज़्यूमर ऐप विकसित करें

4. सेटअप सत्यापित करें

वेबहुक को सुरक्षित बनाना

Challenge-Response Checks

CRC अनुरोध इन स्थितियों में होगा:

रिस्पॉन्स आवश्यकताएँ:

भाषा के अनुसार HMAC लाइब्रेरी:

Python में उदाहरण रिस्पॉन्स टोकन जनरेशन:

उदाहरण JSON रिस्पॉन्स:

अन्य उदाहरण:

वैकल्पिक सिग्नेचर हेडर सत्यापन

अतिरिक्त सुरक्षा दिशानिर्देश

X समेकित नेटवर्क ब्लॉक

अनुशंसित सर्वर कॉन्फ़िगरेशन

webhook और सदस्यताओं का प्रबंधन

Webhook बनाना और बदलना

Webhook कॉन्फ़िगरेशन प्रबंधन एंडपॉइंट:

मैं webhook URL को सीधे अपडेट क्यों नहीं कर सकता?

User सदस्यताएँ जोड़ना और हटाना

सदस्यता प्रबंधन एंडपॉइंट्स

पुनः प्रयास

पुनः प्रयास क्या हैं?

पुनः प्रयास समयरेखा

पुनः प्रयास समयरेखा

Account Activity डेटा ऑब्जेक्ट की संरचना

tweet_create_events (पोस्ट्स, रीट्वीट्स, रिप्लाई, कोट ट्वीट्स)

tweet_create_events (@मेंशन)

favorite_events

follow_events

unfollow_events

block_events

unblock_events

mute_events

unmute_events

user_event

direct_message_events

direct_message_indicate_typing_events

direct_message_mark_read_events

tweet_delete_events

Account Activity Replay API

Account Activity Replay API का उपयोग

सीमाएँ

डेटा उपलब्धता और प्रकार

माइग्रेशन परिचय

माइग्रेशन गाइड: User Streams/Site Streams से Account Activity API पर माइग्रेट करना

परिवर्तनों का सारांश

अप्रचलित API

विकल्प API

अंतर और माइग्रेशन संबंधी विचार

नई सुविधाएँ

उपयोगकर्ता सदस्यताओं का प्रबंधन

माइग्रेशन कैसे करें

Site Streams API से Account Activity API पर आसानी से माइग्रेट करने के लिए नीचे दिए गए चरणों का पालन करें

Account Activity डैशबोर्ड (नमूना Account Activity API ऐप)

उपलब्ध गतिविधियाँ

अप्रचलित स्ट्रीमिंग संदेश प्रकार

अप्रचलित इवेंट प्रकार

Direct Message माइग्रेशन मार्गदर्शिका

बदलावों का सारांश

नई सुविधाएँ

अंतर और माइग्रेशन संबंधी बातें

नया Direct Message ऑब्जेक्ट

सारांश

Direct Messages भेजना

सारांश

Direct Message प्राप्त करना

सारांश

Direct Messages हटाना

सारांश

अक्सर पूछे जाने वाले प्रश्न