Felo X صارف پوسٹس

جس data کی آپ کو ضرورت ہے، اس کے مطابق operation منتخب کریں۔ پانچوں endpoints POST استعمال کرتے ہیں اور root پر JSON واپس کرتے ہیں، کسی مشترک data wrapper کے بغیر۔

تمام examples، overview سے FELO_API_KEY استعمال کرتے ہیں۔ Calls platform balance استعمال کرتی ہیں، Felo Pro credits نہیں۔ Response examples صرف وضاحتی ہیں؛ 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 یا کم بل کی ضمانت نہیں ملتی۔ 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 کے پاس اگلا page نہ ہو، کوئی page خالی ہو، یا cursor موجود نہ ہو۔ اس لیے successful response میں limit سے کم posts ہو سکتی ہیں۔ جہاں دستیاب ہو، جاری رکھنے کے لیے has_next اور next_cursor استعمال کریں۔

include_replies=true کے ساتھ، ہر returned post کو 5 اضافی pages تک اور زیادہ سے زیادہ 100 nested replies ملتی ہیں۔ Collection اس سے پہلے بھی رک سکتی ہے اگر اگلا page نہ ہو، page خالی ہو، یا cursor آگے نہ بڑھ سکے۔ یہ nested replies top-level limit اور total سے باہر ہوتی ہیں، لیکن billable results میں اضافہ کر سکتی ہیں۔

Nested replies مکمل reply archive نہیں ہیں اور اس اضافی collection کے لیے الگ continuation cursor ظاہر نہیں کرتیں۔ replies کو آزادانہ paginate کرنے کے لیے، Read replies operation اور اس کے returned cursor کو استعمال کریں۔ replies کے لیے top-level post cursor دوبارہ استعمال نہ کریں۔

صفحہ بندی اور لاگت کا نظم

total موجودہ response میں متعلقہ array کو شمار کرتا ہے: post queries کے لیے top-level posts، یا reply queries کے لیے ہر result entry کے اندر replies۔ یہ global match count، کسی post کے مکمل reply count، یا آخری billable count نہیں ہے۔

1. پہلی request cursor کے بغیر بھیجیں۔
2. Response سے has_next اور next_cursor پڑھیں۔ replies کے لیے، ہر result entry پر انہیں پڑھیں۔
3. اگر دوسرا page موجود ہو اور cursor خالی نہ ہو، تو اسی query کے ساتھ اسے بغیر تبدیلی کے بھیجیں۔ replies batch کے لیے، ہر post کو الگ الگ جاری رکھیں۔
4. جب اگلا page نہ ہو، cursor دوبارہ آنے لگے، یا آپ کی اپنی page یا spending limit پوری ہو جائے، تو رک جائیں۔

Pagination metadata آخری upstream response کو ظاہر کرتی ہے؛ returned collection کو result cap پر truncate کیا جا سکتا ہے۔ حتیٰ کہ has_next=false بھی اس بات کی guarantee نہیں کہ تمام X history یا replies حاصل کر لی گئی ہیں۔ bounded result set کو تمام دستیاب data کہنے کے بجائے اصل returned count دکھائیں۔

ہر successful page charge پیدا کر سکتا ہے۔ یہ پانچ operations flat request fee کے بجائے returned results کے مطابق بل کیے جاتے ہیں۔ Nested replies اور دیگر returned records billable count پر اثر ڈال سکتے ہیں؛ صرف top-level array length سے cost کا اندازہ نہ لگائیں۔ current prices اور console میں usage چیک کریں۔ مکمل object fields OpenAPI schema میں موجود ہیں۔