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

4. پوسٹس تلاش کریں

POST /api/v1/data/x/tweet/search

curl -sS --request POST "https://openapi.felo.ai/api/v1/data/x/tweet/search" \
  -H "Authorization: Bearer $FELO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"retrieval augmented generation","query_type":"Latest","limit":20}'

Response میں tweets، total، has_next اور next_cursor شامل ہوتے ہیں۔ Post objects میں id، content، author، created_at اور metrics شامل ہوتے ہیں؛ replies اور quoted/retweeted posts nested ہو سکتی ہیں۔ IDs کو strings کے طور پر treat کریں۔

نتیجے کی تعداد کی حدود

limit ایک target ہے، guarantee نہیں۔ موجودہ implementation کم از کم 20 کی target استعمال کرتی ہے: 20 کی target ایک upstream page پڑھتی ہے؛ بڑی targets خودکار طور پر 50 pages تک fetch کرتی ہیں۔ ہر page سے پہلے elapsed time چیک کیا جاتا ہے، اور 60 seconds سے تجاوز کے بعد مزید pages fetch نہیں کیے جاتے۔ ایک جاری upstream request پھر بھی وقت لے سکتی ہے، اس لیے یہ مجموعی HTTP timeout نہیں ہے۔

Collection اس وقت بھی رک جاتی ہے جب target پوری ہو جائے، upstream کے پاس اگلا page نہ ہو، کوئی page خالی ہو، یا cursor موجود نہ ہو۔ limit سے کم posts واپس آنے کا مطلب یہ نہیں کہ request ناکام ہوئی یا ہر matching post حاصل کر لی گئی۔ آگے بڑھنے سے پہلے has_next اور next_cursor چیک کریں۔

{
  "tweets": [{
    "id":"example-post-id",
    "content":"Example post content",
    "author":{"user_id":"example-user-id","username":"example","display_name":"Example"},
    "created_at":"2026-11-01T00:00:00Z",
    "metrics":{},
    "replies":[]
  }],
  "total":1,
  "has_next":false,
  "next_cursor":null
}

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

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