Réponses aux publications X Felo
Fournisseur : Felo · Payé avec le solde de plateforme
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.
5. Lire les réponses
POST /api/v1/data/x/tweet/replies
| Champ | Type | Requis | Signification |
|---|---|---|---|
tweet_ids | string ou tableau de strings | Oui | Un ID de publication ou un lot allant jusqu'à 20 IDs |
cursor | string | Non | Jusqu'à 4 000 caractères ; à utiliser avec un seul ID de publication |
since_time | integer | Non | Heure de début en secondes Unix |
until_time | integer | Non | Heure de fin en secondes Unix |
Remplacez l'espace réservé par un vrai ID de publication :
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"]}'Contrairement à la timeline et à la recherche de publications, les réponses sont regroupées sous results. Chaque entrée possède son propre état de pagination :
{"results":[{"tweet_id":"POST_ID","replies":[],"total":0,"has_next":false,"next_cursor":null}]}Limites de réponses par requête
Chaque requête lit une page de réponses amont par tweet_id et conserve au plus 100 réponses ; elle ne récupère pas automatiquement chaque page de réponses. Dans un lot allant jusqu'à 20 IDs, la limite de 100 réponses s'applique séparément à chaque entrée results. Les nombres réels peuvent être inférieurs.
Le total de chaque entrée est le nombre de réponses renvoyées dans cette entrée, pas le nombre complet de réponses de la publication. Pour continuer, utilisez le next_cursor de cette entrée et envoyez uniquement son ID de publication unique dans la requête suivante. Il n'existe pas de paramètre limit permettant d'augmenter le plafond par requête.
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.
- Envoyez la première requête sans
cursor. - Lisez
has_nextetnext_cursordans la réponse. Pour les réponses, lisez-les dans chaque entrée de résultat. - 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.
- 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.