# Respuestas a publicaciones de Felo en X

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

Elige la operación para los datos que necesitas. Los cinco endpoints usan POST y devuelven JSON en la raíz, sin un contenedor común `data`.

Todos los ejemplos usan `FELO_API_KEY` de la [vista general](https://openapi.felo.ai/es/docs/data-api/guides/felo-overview.md). Las llamadas usan **saldo de la plataforma**, no créditos Felo Pro. Los ejemplos de respuesta son ilustrativos; el contenido en vivo y los campos opcionales varían.





## 5. Leer respuestas

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

| Campo | Tipo | Requerido | Significado |
|---|---|---|---|
| `tweet_ids` | string o arreglo de strings | Sí | Un ID de publicación o un lote de hasta 20 IDs |
| `cursor` | string | No | Hasta 4.000 caracteres; úsalo con un solo ID de publicación |
| `since_time` | integer | No | Hora de inicio en segundos Unix |
| `until_time` | integer | No | Hora de fin en segundos Unix |

Reemplaza el marcador de posición con un ID real de publicación:

```bash
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"]}'
```

A diferencia de la cronología y la búsqueda de publicaciones, las respuestas se agrupan bajo `results`. Cada entrada tiene su propio estado de paginación:

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

### Límites de respuestas por solicitud

Cada solicitud lee una página upstream de respuestas por cada `tweet_id` y conserva como máximo 100 respuestas; no recupera automáticamente cada página de respuestas. En un lote de hasta 20 IDs, el tope de 100 respuestas se aplica por separado a cada entrada de `results`. Los recuentos reales pueden ser menores.

El `total` de cada entrada es el número de respuestas devueltas en esa entrada, no el recuento completo de respuestas de la publicación. Para continuar, usa el `next_cursor` de esa entrada y envía solo su único ID de publicación en la siguiente solicitud. No existe un parámetro `limit` para aumentar el tope por solicitud.



## Paginación y control de costes

`total` cuenta el arreglo correspondiente en la respuesta actual: publicaciones de nivel superior para consultas de publicaciones, o respuestas dentro de cada entrada de resultado para consultas de respuestas. No es un recuento global de coincidencias, ni el recuento completo de respuestas de una publicación, ni el recuento final facturable.

1. Envía la primera solicitud sin `cursor`.
2. Lee `has_next` y `next_cursor` de la respuesta. Para respuestas, léelos en cada entrada de resultado.
3. Si existe otra página y el cursor no está vacío, envíalo sin cambios con la misma consulta. Para un lote de respuestas, continúa cada publicación por separado.
4. Detente cuando no haya página siguiente, cuando un cursor se repita o cuando se alcance tu propio límite de página o gasto.

Los metadatos de paginación reflejan la última respuesta upstream; la colección devuelta puede truncarse en un tope de resultados. Incluso `has_next=false` no garantiza que se haya recuperado todo el historial o las respuestas de X. Muestra el recuento real devuelto en lugar de etiquetar como todos los datos disponibles un conjunto de resultados limitado.

Cada página exitosa puede incurrir en un cargo. Estas cinco operaciones se facturan por resultados devueltos, no con una tarifa fija por solicitud. Las respuestas anidadas y otros registros devueltos pueden afectar el recuento facturado; no estimes el coste solo por la longitud del arreglo de nivel superior. Consulta los [precios actuales](https://openapi.felo.ai/api/v1/data/prices) y el uso en la consola. Los campos completos de los objetos están en el [esquema OpenAPI](https://openapi.felo.ai/api/v1/data/openapi.json).
