Felo API PlatformFelo API Platform

Felo Пошук дописів X

Провайдер: Felo · Оплата з балансу платформи

Автентифікація та налаштуванняБілінг і помилкиПовний посібник із робочого процесу

Оберіть операцію для потрібних вам даних. Усі п’ять кінцевих точок використовують POST і повертають JSON у корені, без спільної оболонки data.

У всіх прикладах використовується FELO_API_KEY з огляду. Виклики використовують баланс платформи, а не кредити Felo Pro. Приклади відповідей є ілюстративними; живий контент і необов’язкові поля можуть відрізнятися.

4. Пошук дописів

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

ПолеТипОбов’язковеЗначення
querystringТакТекст пошуку, 1–1,000 символів
query_typestringНіLatest (за замовчуванням) або Top
limitintegerНі1–1,000; поточна реалізація використовує щонайменше 20, за замовчуванням 20
cursorstringНіКурсор пагінації, до 4,000 символів
since_timeinteger or stringНіЧас початку; використовуйте Unix seconds для однозначного числового значення
until_timeinteger or stringНіЧас завершення; використовуйте Unix seconds, а не мілісекунди
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}'

Відповідь містить tweets, total, has_next і next_cursor. Об’єкти дописів містять id, content, author, created_at і metrics; відповіді та процитовані/ретвітнуті дописи можуть бути вкладеними. Розглядайте ID як рядки.

Обмеження кількості результатів

limit — це ціль, а не гарантія. Поточна реалізація використовує ціль не менше 20: ціль 20 читає одну вхідну сторінку; більші цілі автоматично отримують до 50 сторінок. Минувший час перевіряється перед кожною сторінкою, і подальші сторінки не отримуються, щойно він перевищує 60 секунд. Запит до вхідного джерела, що вже виконується, все ще може зайняти час, тож це не є загальним HTTP-тайм-аутом.

Збір також зупиняється, коли досягнуто цілі, на вхідному джерелі немає наступної сторінки, сторінка порожня або курсор відсутній. Повернення меншої кількості дописів, ніж limit, не означає, що запит провалився або що всі відповідні дописи було отримано. Перевіряйте 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 рахує відповідний масив у поточній відповіді: дописи верхнього рівня для запитів дописів або відповіді в кожному елементі результату для запитів відповідей. Це не глобальна кількість збігів, не повна кількість відповідей на допис і не кінцева кількість, що підлягає оплаті.

  1. Надішліть перший запит без cursor.
  2. Прочитайте has_next і next_cursor у відповіді. Для відповідей читайте їх у кожному елементі результату.
  3. Якщо є ще одна сторінка і курсор непорожній, надішліть його без змін із тим самим запитом. Для пакета відповідей продовжуйте окремо для кожного допису.
  4. Зупиніться, коли немає наступної сторінки, коли курсор повторюється або коли досягнуто вашого власного ліміту сторінок чи витрат.

Метадані пагінації відображають останню вхідну відповідь; повернута колекція може бути обрізана на ліміті результатів. Навіть has_next=false не гарантує, що вся історія X або всі відповіді були отримані. Відображайте фактично повернену кількість замість того, щоб позначати обмежений набір результатів як усі доступні дані.

Кожна успішна сторінка може спричинити списання. Ці п’ять операцій оплачуються за повернутими результатами, а не фіксованою платою за запит. Вкладені відповіді та інші повернуті записи можуть впливати на кількість, що підлягає оплаті; не оцінюйте вартість лише за довжиною масиву верхнього рівня. Перевіряйте поточні ціни і використання в консолі. Повні поля об’єктів наведено у схемі OpenAPI.

Потрібна допомога?