इस 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 (उपयोगकर्ता द्वारा) |
| स्तर | मूल्य | अद्वितीय सदस्यताओं की संख्या | वेबहुक की संख्या | विश्वसनीयता और गतिविधि रिकवरी |
|---|
| Enterprise | सेल्स से संपर्क करें | 500+ तक | 3+ | पुनर्प्रयास और Replay |
-
कोई प्रश्न हैं? त्रुटियाँ आ रही हैं?
-
हमारा सैंपल कोड देखें:
वेबहुक और सब्स्क्राइब किए गए उपयोगकर्ताओं को प्रबंधित करें
वेबहुक जोड़ना
वेबहुक देखना
वेबहुक हटाना
आइए, दिए गए ऐप संदर्भ के लिए एक नया वेबहुक 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
सब्सक्राइब किए गए उपयोगकर्ताओं का प्रबंधन:
सदस्यता जोड़ना
सदस्यताएँ देखना
सदस्यता हटाना
हम शुरुआत किसी उपयोगकर्ता को सब्सक्राइब करने से करेंगे, ताकि आपको सभी इवेंट प्रकार प्राप्त हों।निम्नलिखित मानों में बदलाव करने के बाद, नीचे दिए गए 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
-
सब्सक्राइब करने वाले उपयोगकर्ता का access token
<SUBSCRIBING_USER'S_ACCESS_TOKEN> उदा. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
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"'
Account Activity API का वीडियो वॉकथ्रू
- वेबहुक पंजीकृत करना
- user subscription जोड़ना
- user subscription हटाना
- account activities प्राप्त करना
- account activities को replay करना
-
कोई सवाल हैं? त्रुटियाँ आ रही हैं?
-
हमारा नमूना कोड देखें:
Enterprise
वेबहुक्स के साथ शुरुआत करना
- स्वीकृत डेवलपर खाते के साथ डेवलपर कंसोल में एक 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 एक्सेस प्राप्त करें
3. वेबहुक कंज़्यूमर ऐप विकसित करें
-
इवेंट प्राप्त करने के लिए अपने वेबहुक के रूप में इस्तेमाल करने हेतु URL वाला एक वेब ऐप बनाएं। यह आपके सर्वर पर डिप्लॉय किया गया endpoint है, जो आने वाले X वेबहुक इवेंट को सुनता है।
-
जैसा कि हमारी 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 देखें।
- यह सत्यापित करने के लिए कि आपका ऐप और वेबहुक सही तरीके से कॉन्फ़िगर किए गए हैं, उन 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
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 में उदाहरण रिस्पॉन्स टोकन जनरेशन:
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)
{
"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&nonce=nonce से की जाती है।
किसी अनुरोध को सत्यापित करने के चरण
- अपने consumer secret और आने वाली payload body का उपयोग करके एक hash बनाएं।
- बनाए गए hash की तुलना base64-encoded x-twitter-webhooks-signature मान से करें। timing attack के जोखिम को कम करने के लिए compare_digest जैसी विधि का उपयोग करें।
अतिरिक्त सुरक्षा दिशानिर्देश
-
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 कॉन्फ़िगरेशन प्रबंधन एंडपॉइंट:
| |
|---|
| Method | Enterprise |
| एक webhook URL पंजीकृत करता है / एक webhook_id जनरेट करता है | POST webhooks |
| सभी webhook URL और उनकी स्थिति लौटाता है | GET webhooks |
| ऐप का मौजूदा webhook कॉन्फ़िगरेशन हटाएँ | DELETE webhooks/:webhook_id |
| CRC अनुरोध को मैन्युअल रूप से ट्रिगर करें | PUT webhooks/:webhook_id |
मैं webhook URL को सीधे अपडेट क्यों नहीं कर सकता?
User सदस्यताएँ जोड़ना और हटाना
सदस्यता प्रबंधन एंडपॉइंट्स
कृपया ध्यान दें: API का उपयोग शुरू करने से पहले, X को आपके डेवलपर ऐप के लिए Account Activity API की पहुँच सक्षम करनी होगी। इसके लिए, यह सुनिश्चित करें कि आप प्रमाणीकरण के लिए जिस ऐप ID का उपयोग करना चाहते हैं, उसे अपने अकाउंट मैनेजर या तकनीकी सहायता टीम के साथ साझा करें।
| | | |
|---|
| विवरण | **एंडपॉइंट ** | 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 | | ✓ |
- Consumer Keys (API Key और Secret)
- Access Tokens (Access Token और Secret)
निम्नलिखित तीन एंडपॉइंट्स के मामले में, आप अपने ऐप के संदर्भ में write actions करते हैं (इनमें कोई X उपयोगकर्ता शामिल नहीं होता)। इसलिए, आपको जो Access Tokens देने हैं, वे आपके डेवलपर ऐप के होने चाहिए। इन्हें सीधे डेवलपर कंसोल में, आपके ऐप के “Keys and tokens” टैब के अंतर्गत जनरेट किया जा सकता है।
दूसरी ओर, नीचे दिए गए तीन endpoints के मामले में आप ऐसा अनुरोध कर रहे होते हैं, जो आपके application को किसी X उपयोगकर्ता की ओर से संरक्षित डेटा (उदाहरण के लिए, Direct Messages) तक पहुँचने की अनुमति देता है। इसलिए आपको संबंधित subscribing उपयोगकर्ता के Access Tokens देने होंगे। आवश्यक Access Tokens, 3-legged OAuth flow का उपयोग करके प्राप्त किए जा सकते हैं (देखें OAuth 1.0a: किसी उपयोगकर्ता के Access Tokens कैसे प्राप्त करें)। ऊपर दी गई तालिका में इन endpoints को तारांकन चिह्न (*) से चिह्नित किया गया है।
कृपया ध्यान दें: सुनिश्चित करें कि आपका developer App “Read, Write, and Direct Messages” के लिए enabled हो। आप इस setting को अपने डेवलपर खाते के Projects & Apps section में, चुने गए developer App के “App permissions” के अंतर्गत बदल सकते हैं। permissions settings बदलने के बाद आपको अपने App credentials फिर से generate करने होंगे। कृपया ध्यान दें: API का उपयोग शुरू करने से पहले X को आपके developer App के लिए Account Activity API access enable करना होगा। इसके लिए, authentication के उद्देश्य से जिस App ID का आप उपयोग करना चाहते हैं, उसे अपने account manager या technical support team के साथ साझा करना सुनिश्चित करें।
| | | |
|---|
| विवरण | **एंडपॉइंट ** | 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 | | ✓ |
- Consumer Keys (API Key और Secret)
- Access Tokens (Access Token और Secret)
निम्नलिखित तीन एंडपॉइंट्स के मामले में, आप अपने ऐप के संदर्भ में write actions करते हैं (इसमें कोई X उपयोगकर्ता शामिल नहीं होता)। इसलिए, जिन Access Tokens की आपको आवश्यकता है, वे आपके डेवलपर ऐप के होने चाहिए। इन्हें सीधे डेवलपर कंसोल में, आपके ऐप के “Keys and tokens” टैब के अंतर्गत जनरेट किया जा सकता है।
दूसरी ओर, निम्नलिखित तीन endpoints के मामले में, आप ऐसा अनुरोध कर रहे हैं जो आपके application को किसी X उपयोगकर्ता की ओर से संरक्षित डेटा (उदाहरण के लिए, Direct Messages) तक पहुँचने की अनुमति देता है। इसलिए, आपको संबंधित subscribing उपयोगकर्ता के Access Tokens देने होंगे। आवश्यक Access Tokens, 3-legged OAuth flow का उपयोग करके प्राप्त किए जा सकते हैं (देखें OAuth 1.0a: किसी उपयोगकर्ता के Access Tokens कैसे प्राप्त करें)। इन endpoints को ऊपर दी गई तालिका में तारांकन चिह्न (*) से चिह्नित किया गया है।
कृपया ध्यान दें: सुनिश्चित करें कि आपका डेवलपर ऐप “Read, Write, and Direct Messages” के लिए enabled है। आप इस setting को अपने डेवलपर खाते के Projects & Apps section में, चुने गए डेवलपर ऐप के “App permissions” के अंतर्गत बदल सकते हैं। permissions setting बदलने के बाद आपको अपने ऐप credentials फिर से generate करने होंगे। 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 | अनुपालन बनाए रखना आसान बनाने के लिए हटाई गई पोस्ट्स की सूचना। |
{
"for_user_id": "2244994945",
"tweet_create_events": [
{
<Tweet Object>
}
]
}
{
"for_user_id": "2244994945",
"user_has_blocked": "false",
"tweet_create_events": [
{
<Tweet Object>
}
]
}
{
"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>
}
}]
}
{
"for_user_id": "2244994945",
"follow_events": [{
"type": "follow",
"created_timestamp": "1517588749178",
"target": {
<User Object >
},
"source": {
< User Object >
}
]
}
}
{
"for_user_id": "2244994945",
"follow_events": [{
"type": "unfollow",
"created_timestamp": "1517588749178",
"target": {
<User Object >
},
"source": {
< User Object >
}
]
}
}
{
"for_user_id": "2244994945",
"block_events": [{
"type": "block",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}]
}
{
"for_user_id": "2244994945",
"block_events": [{
"type": "unblock",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}]
}
{
"for_user_id": "2244994945",
"mute_events": [
{
"type": "mute",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}
]
}
{
"for_user_id": "2244994945",
"mute_events": [
{
"type": "unmute",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}
]
}
{
"user_event": {
"revoke": {
"date_time": "2018-05-24T09:48:12+00:00",
"target": {
"app_id": "13090192"
},
"source": {
"user_id": "63046977"
}
}
}
}
{
"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"
}
}
}
{
"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 का उपयोग
- 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 के लिए कुछ अतिरिक्त सुविधाएँ भी देती हैं:
इन नए 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 पर माइग्रेट करना
अंतर और माइग्रेशन संबंधी विचार
उपयोगकर्ता सदस्यताओं का प्रबंधन
Site Streams API से Account Activity API पर आसानी से माइग्रेट करने के लिए नीचे दिए गए चरणों का पालन करें
- आवश्यक 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 से माइग्रेट नहीं कर रहे हैं)
Account Activity डैशबोर्ड (नमूना 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 माइग्रेशन मार्गदर्शिका
बदलावों का सारांश
यदि आप अभी भी नीचे दिए गए DM endpoint का उपयोग कर रहे हैं, तो आपको नए endpoint पर माइग्रेट करना होगा।
नए 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 ऑब्जेक्ट
{
"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 रिस्पॉन्स, अटैचमेंट्स आदि)।
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!"}}}}'
- संदेश JSON POST बॉडी में परिभाषित किया जाता है
- Content-type हेडर को application/json पर सेट किया जाना चाहिए
- OAuth signature के जनरेशन में JSON बॉडी शामिल नहीं होती।
Direct Message प्राप्त करना
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 को अब 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 में पोस्ट करें।
अक्सर पूछे जाने वाले प्रश्न
- गति: हम 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 के साथ आगे बढ़ें:
यदि हमारा 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 के लिए उपलब्ध हो जाती है।
त्रुटि निवारण मार्गदर्शिका
-
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 है।
-
Premium - API को अनुरोध भेजने का प्रयास करने से पहले सुनिश्चित करें कि आपके पास स्वीकृत डेवलपर खाता हो। आपको अनुरोध में सही :env_name का भी उपयोग करना होगा, जिसे आप dev environments पेज पर कॉन्फ़िगर कर सकते हैं।
-
Enterprise - सुनिश्चित करें कि आपके अकाउंट मैनेजर ने आपको Account Activity API का एक्सेस दिला दिया है।
-
सुनिश्चित करें कि आपने अपना URI सही तरीके से कॉन्फ़िगर किया है। अगर आपने अपने अनुरोध में गलत URI दर्ज किया है, तो यह त्रुटि आ सकती है।
Code 214 - Webhook URL आवश्यकताओं को पूरा नहीं करती है।
कोड 214 - CRC GET अनुरोध पर उच्च विलंबता। आपके webhook को 3 सेकंड से कम समय में जवाब देना चाहिए।
- इसका मतलब है कि आपका सर्वर धीमा है। सुनिश्चित करें कि आप CRC अनुरोध का जवाब 3 सेकंड के भीतर दे रहे हैं।
Code 214 - CRC GET अनुरोध के दौरान Non-200 रिस्पॉन्स कोड (जैसे 404, 500 आदि)।
- आपका सर्वर डाउन है। सुनिश्चित करें कि आपका सर्वर ठीक से चल रहा है।
कोड 214 - पहले से ही बहुत अधिक संसाधन बनाए जा चुके हैं।
- Enterprise - आप अपने सभी webhook पहले ही इस्तेमाल कर चुके हैं। यह पता लगाने के लिए कि आपके webhook कहाँ वितरित हैं, अपने प्रत्येक पंजीकृत ऐप के लिए GET webhooks endpoint का उपयोग करें।
- 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
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 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 आदि)। |
{
"errors": [
{
"code": 214,
"message": "Too many resources already created."
}
]
}
GET account_activity/webhooks
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'
[
{
"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
valid पर सेट करके webhook को फिर से सक्षम कर देता है।
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"'
| कोड | संदेश |
|---|
| 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
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"'
| Code | संदेश |
|---|
| 34 | Webhook मौजूद नहीं है या किसी अन्य X ऐप से संबद्ध है। |
| 348 | क्लाइंट ऐप्लिकेशन को इस उपयोगकर्ता की Webhook सदस्यताओं तक पहुँचने की अनुमति नहीं है। |
GET account_activity/subscriptions/count
https://api.x.com/1.1/account_activity/subscriptions/count.json
| |
|---|
| रिस्पॉन्स प्रारूप | HTTP रिस्पॉन्स कोड |
| प्रमाणीकरण आवश्यक | हाँ (केवल एप्लिकेशन - बेयरर टोकन) |
| रेट लिमिट लागू | हाँ |
| अनुरोध / 15-मिनट विंडो (एप्लिकेशन प्रमाणीकरण) | 15 |
| |
|---|
| कोड | संदेश |
| 200 | सफल। अनुरोधित webhook के लिए सदस्यताओं की संख्या लौटाई जाएगी। |
| 401 | आपके ऐप को निर्दिष्ट webhook की सदस्यताएँ देखने की अनुमति नहीं है। |
$ curl --request GET
--url https://api.x.com/1.1/account_activity/subscriptions/count.json
--header 'authorization: Bearer TOKEN'
{
"account_name":"my-account",
"subscriptions_count_all":"1",
"subscriptions_count_direct_messages":"0",
"provisioned_count":"50"
}
त्रुटि संदेश
| कोड | संदेश |
|---|
| 32 | आपको प्रमाणित नहीं किया जा सका। |
{
"errors": [
{
"code": 32,
"message": "Could not authenticate you."
}
]
}
GET account_activity/webhooks/:webhook_id/subscriptions/all
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
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all/list.json
| |
|---|
| रिस्पॉन्स प्रारूप | HTTP रिस्पॉन्स कोड |
| प्रमाणीकरण आवश्यक | हाँ (केवल एप्लिकेशन - बेयरर टोकन) |
| रेट लिमिट लागू | हाँ |
| अनुरोध / 15-मिनट विंडो (एप्लिकेशन प्रमाणीकरण) | 50 |
| |
|---|
| webhook_id (required) | Webhook ID. संसाधन पथ में परिभाषित है। |
| Code | Message |
|---|
| 200 | सफल। अनुरोधित webhook के लिए सदस्यताओं की सूची लौटाई जाएगी। |
| 401 | आपके एप्लिकेशन को निर्दिष्ट webhook की सदस्यताएँ देखने की अनुमति नहीं है। |
उदाहरण रिस्पॉन्स - सफल
HTTP 200
{
"webhook_id": "1234567890",
"webhook_url": "https://your_domain.com/webhook/twitter/0",
"application_id": "11231812",
"subscriptions": [{
"user_id": "20212306"
}]
}
| कोड | संदेश |
|---|
| 32 | आपका प्रमाणीकरण नहीं हो सका। |
{
"errors": [
{
"code": 32,
"message": "Could not authenticate you."
}
]
}
DELETE account_activity/webhooks/:webhook_id
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 (अप्रचलित)
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
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'
| कोड | संदेश |
|---|
| 404 | क्षमा करें, वह पृष्ठ मौजूद नहीं है। - यह अक्सर तब होता है, जब निर्दिष्ट उपयोगकर्ता id ने वास्तव में सदस्यता नहीं ली होती है। |
| |
|---|
| 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 मिनट से अधिक हाल का नहीं होना चाहिए। |
| 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 का उपयोग करके फिर से प्रयास करें। |
“जॉब सफलतापूर्वक पूरा हुआ” संदेश
{
"replay\_job\_status": {
"webhook_id": "1234577122340233217",
"job_state": "Complete",
"job\_state\_description": "Job completed successfully"
"job_id": "1095098195724558337"
}
}
“जॉब पूरा नहीं हुआ” संदेश
{
"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 --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"
}
