Recherche de publications X Felo

Choisissez l'opération correspondant aux données dont vous avez besoin. Les cinq points de terminaison utilisent POST et renvoient le JSON à la racine, sans enveloppe commune data.

Tous les exemples utilisent FELO_API_KEY depuis l'aperçu. Les appels utilisent le solde de plateforme, et non les crédits Felo Pro. Les exemples de réponse sont illustratifs ; le contenu réel et les champs facultatifs varient.

4. Rechercher des publications

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}'

La réponse contient tweets, total, has_next et next_cursor. Les objets publication incluent id, content, author, created_at et metrics ; les réponses et les publications citées/retweetées peuvent être imbriquées. Traitez les IDs comme des chaînes.

Limites du nombre de résultats

limit est une cible, pas une garantie. L'implémentation actuelle utilise une cible d'au moins 20 : une cible de 20 lit une page amont ; des cibles plus élevées récupèrent automatiquement jusqu'à 50 pages. Le temps écoulé est vérifié avant chaque page, et aucune page supplémentaire n'est récupérée une fois qu'il dépasse 60 secondes. Une requête amont en cours peut encore prendre du temps ; il ne s'agit donc pas d'un délai global HTTP.

La collecte s'arrête aussi lorsque la cible est atteinte, que l'amont n'a plus de page suivante, qu'une page est vide, ou que le curseur est manquant. Renvoyer moins de publications que limit ne signifie pas que la requête a échoué ni que toutes les publications correspondantes ont été récupérées. Vérifiez has_next et next_cursor avant de continuer.

{
  "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
}

Pagination et contrôle des coûts

total compte le tableau correspondant dans la réponse actuelle : les publications de premier niveau pour les requêtes de publication, ou les réponses dans chaque entrée de résultat pour les requêtes de réponses. Il ne s'agit pas d'un nombre global de correspondances, d'un nombre complet de réponses d'une publication, ni du total final facturable.

1. Envoyez la première requête sans cursor.
2. Lisez has_next et next_cursor dans la réponse. Pour les réponses, lisez-les dans chaque entrée de résultat.
3. Si une autre page existe et que le curseur n'est pas vide, renvoyez-le inchangé avec la même requête. Pour un lot de réponses, continuez chaque publication séparément.
4. Arrêtez-vous lorsqu'il n'y a pas de page suivante, lorsqu'un curseur se répète, ou lorsque votre propre limite de pages ou de dépenses est atteinte.

Les métadonnées de pagination reflètent la dernière réponse amont ; la collection renvoyée peut être tronquée par un plafond de résultats. Même has_next=false ne garantit pas que tout l'historique X ou toutes les réponses ont été récupérés. Affichez le nombre réellement renvoyé plutôt que d'étiqueter un ensemble de résultats borné comme étant toutes les données disponibles.

Chaque page réussie peut entraîner des frais. Ces cinq opérations sont facturées par résultats retournés, et non par frais fixes par requête. Les réponses imbriquées et autres enregistrements renvoyés peuvent affecter le nombre facturé ; n'estimez pas le coût uniquement à partir de la longueur du tableau de premier niveau. Consultez les prix actuels et l'utilisation dans la console. Les champs d'objet complets figurent dans le schéma OpenAPI.