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 مختلف ہو سکتے ہیں۔

5. جوابات پڑھیں

POST /api/v1/data/x/tweet/replies

placeholder کو ایک حقیقی post ID سے بدلیں:

curl -sS --request POST "https://openapi.felo.ai/api/v1/data/x/tweet/replies" \
  -H "Authorization: Bearer $FELO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tweet_ids":["POST_ID"]}'

Timeline اور post search کے برعکس، replies results کے تحت group ہوتی ہیں۔ ہر entry کی اپنی pagination state ہوتی ہے:

{"results":[{"tweet_id":"POST_ID","replies":[],"total":0,"has_next":false,"next_cursor":null}]}

درخواست کے فی جواب حدود

ہر request، فی tweet_id ایک upstream reply page پڑھتی ہے اور زیادہ سے زیادہ 100 replies رکھتی ہے؛ یہ خودکار طور پر ہر reply page fetch نہیں کرتی۔ زیادہ سے زیادہ 20 IDs کے batch میں، 100-reply cap ہر results entry پر الگ سے لاگو ہوتی ہے۔ اصل counts اس سے کم ہو سکتی ہیں۔

ہر entry کا total اس entry میں واپس آنے والی replies کی تعداد ہے، post کے مکمل reply count کی نہیں۔ جاری رکھنے کے لیے، اس entry کا next_cursor استعمال کریں اور اگلی request میں صرف اسی ایک post ID کو بھیجیں۔ فی request cap بڑھانے کے لیے کوئی limit parameter موجود نہیں۔

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

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 میں موجود ہیں۔