# Felo X-berichtantwoorden

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

Kies de bewerking voor de gegevens die je nodig hebt. Alle vijf eindpunten gebruiken POST en retourneren JSON op de root, zonder een algemene `data`-wrapper.

Alle voorbeelden gebruiken `FELO_API_KEY` uit het [overzicht](https://openapi.felo.ai/nl/docs/data-api/guides/felo-overview.md). Aanroepen gebruiken **platformsaldo**, niet Felo Pro-credits. Reactievoorbeelden zijn illustratief; live inhoud en optionele velden kunnen variëren.





## 5. Antwoorden lezen

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

| Veld | Type | Vereist | Betekenis |
|---|---|---|---|
| `tweet_ids` | string of string array | Ja | Eén bericht-ID of een batch van maximaal 20 ID's |
| `cursor` | string | Nee | Tot 4.000 tekens; gebruik met één bericht-ID |
| `since_time` | integer | Nee | Begintijd in Unix-seconden |
| `until_time` | integer | Nee | Eindtijd in Unix-seconden |

Vervang de tijdelijke aanduiding door een echte bericht-ID:

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

In tegenstelling tot de tijdlijn- en berichtzoekopdracht worden antwoorden gegroepeerd onder `results`. Elke invoer heeft een eigen paginatiestatus:

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

### Antwoordlimieten per verzoek

Elk verzoek leest één upstream-antwoordpagina per `tweet_id` en behoudt maximaal 100 antwoorden; het haalt niet automatisch elke antwoordpagina op. In een batch van maximaal 20 ID's geldt de limiet van 100 antwoorden afzonderlijk voor elke `results`-invoer. Werkelijke aantallen kunnen lager zijn.

De `total` van elke invoer is het aantal antwoorden dat in die invoer is teruggegeven, niet het volledige antwoordaantal van het bericht. Om door te gaan, gebruik je de `next_cursor` van die invoer en stuur je in het volgende verzoek alleen de enkele bericht-ID. Er is geen `limit`-parameter om de limiet per verzoek te verhogen.



## Paginering en kostenbeheersing

`total` telt de overeenkomstige array in de huidige reactie: berichten op topniveau voor berichtquery's, of antwoorden binnen elke resultaatinvoer voor antwoordquery's. Het is geen globaal matchaantal, geen volledig antwoordaantal van een bericht en geen uiteindelijke factureerbare telling.

1. Stuur het eerste verzoek zonder `cursor`.
2. Lees `has_next` en `next_cursor` uit de reactie. Voor antwoorden lees je ze in elke resultaatinvoer.
3. Als er nog een pagina is en de cursor niet leeg is, stuur je die ongewijzigd mee met dezelfde query. Voor een antwoordenbatch ga je per bericht afzonderlijk verder.
4. Stop wanneer er geen volgende pagina is, wanneer een cursor zich herhaalt, of wanneer je eigen pagina- of bestedingslimiet is bereikt.

Paginatiemetagegevens weerspiegelen de laatste upstream-reactie; de teruggegeven verzameling kan worden afgekapt bij een resultaatlimiet. Zelfs `has_next=false` is geen garantie dat alle X-geschiedenis of antwoorden zijn opgehaald. Geef het daadwerkelijk teruggegeven aantal weer in plaats van een begrensde resultaatset als alle beschikbare gegevens te labelen.

Elke succesvolle pagina kan kosten met zich meebrengen. Deze vijf bewerkingen worden gefactureerd op basis van teruggegeven resultaten, niet per vaste verzoekprijs. Geneste antwoorden en andere teruggegeven records kunnen de gefactureerde telling beïnvloeden; schat de kosten niet alleen op basis van de lengte van de array op topniveau. Controleer de [huidige prijzen](https://openapi.felo.ai/api/v1/data/prices) en het gebruik in de console. Volledige objectvelden staan in het [OpenAPI-schema](https://openapi.felo.ai/api/v1/data/openapi.json).