Felo X उपयोगकर्ता पोस्ट

आपको जिस डेटा की आवश्यकता है, उसके लिए उपयुक्त operation चुनें। सभी पाँच endpoints POST का उपयोग करते हैं और root पर JSON लौटाते हैं, बिना किसी shared data wrapper के।

सभी examples overview से FELO_API_KEY का उपयोग करते हैं। Calls platform balance का उपयोग करती हैं, Felo Pro credits का नहीं। Response examples केवल illustrative हैं; live content और optional fields बदलते रहते हैं।

3. किसी उपयोगकर्ता की समयरेखा प्राप्त करें

POST /api/v1/data/x/user/tweets

curl -sS --request POST "https://openapi.felo.ai/api/v1/data/x/user/tweets" \
  -H "Authorization: Bearer $FELO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"username":"OpenAI","limit":20,"include_replies":false}'

Response में tweets, total, has_next और next_cursor होते हैं। limit को 20 से कम सेट करना कम returned items या छोटे bill की गारंटी नहीं देता। Replies शामिल करने से returned data और billable results बढ़ सकते हैं।

परिणाम और नेस्टेड उत्तर सीमाएँ

limit इस request के लिए top-level posts की target संख्या है, guaranteed result count नहीं। वर्तमान implementation कम से कम 20 का target उपयोग करती है: 20 का target एक upstream page पढ़ता है; बड़े targets अपने-आप अधिकतम 50 pages तक fetch करते हैं। प्रत्येक page से पहले, यह elapsed time जाँचती है और 60 seconds से अधिक होने पर आगे के pages fetch करना रोक देती है। यह जाँच इस बात की गारंटी नहीं है कि पूरी HTTP request 60 seconds के भीतर समाप्त होगी।

Collection तब भी रुक जाती है जब target पूरा हो जाए, upstream में next page न हो, कोई page empty हो, या cursor missing हो। इसलिए एक successful response में limit से कम posts हो सकती हैं। जहाँ उपलब्ध हो, जारी रखने के लिए has_next और next_cursor का उपयोग करें।

include_replies=true के साथ, प्रत्येक returned post को अधिकतम 5 extra pages और अधिकतम 100 nested replies मिलती हैं। Collection इससे पहले भी रुक सकती है जब next page न हो, page empty हो, या cursor आगे न बढ़ सके। ये nested replies top-level limit और total के बाहर हैं, लेकिन billable results बढ़ा सकती हैं।

Nested replies complete reply archive नहीं हैं और इस extra collection के लिए अलग continuation cursor उपलब्ध नहीं करातीं। Replies को independently paginate करने के लिए, Read replies operation और उसके returned cursor का उपयोग करें। Replies के लिए top-level post cursor का पुन: उपयोग न करें।

पृष्ठांकन और लागत नियंत्रण

total वर्तमान response में संबंधित array को count करता है: post queries के लिए top-level posts, या reply queries के लिए प्रत्येक result entry के भीतर replies। यह global match count, किसी post की complete reply count, या अंतिम billable count नहीं है।

1. पहली request cursor के बिना भेजें।
2. Response से has_next और next_cursor पढ़ें। Replies के लिए, उन्हें प्रत्येक result entry पर पढ़ें।
3. यदि कोई और page मौजूद है और cursor nonempty है, तो उसी query के साथ उसे बिना बदले भेजें। Replies batch के लिए, प्रत्येक post को अलग-अलग जारी रखें।
4. जब next page न हो, cursor दोहराया जाए, या आपकी अपनी page अथवा spending limit पूरी हो जाए, तब रुकें।

Pagination metadata अंतिम upstream response को दर्शाती है; returned collection result cap पर truncate हो सकती है। यहाँ तक कि has_next=false भी इस बात की गारंटी नहीं है कि पूरा X history या replies प्राप्त कर लिए गए हैं। Bounded result set को all available data कहने के बजाय actual returned count दिखाएँ।

हर successful page पर charge लग सकता है। ये पाँच operations flat request fee से नहीं, बल्कि returned results के अनुसार billed होती हैं। Nested replies और अन्य returned records billed count को प्रभावित कर सकते हैं; केवल top-level array length से cost का अनुमान न लगाएँ। current prices और console में usage जाँचें। Complete object fields OpenAPI schema में हैं।