Preview stream

Fetch the next available batch of records from a Kafka topic as a one-off `DataFrame`, independent of the create/start/stop/delete stream lifecycle above (NATS is not supported here). Each poller is cached server-side for 2 minutes of inactivity, keyed by the DSInfo's `name`, so repeated polls against the same name continue from where the previous poll left off rather than re-reading from the start. Two distinct call patterns exist, and they behave very differently — pick based on which matches your situation, not by symmetry with the request body's shape: * **`sid` query param, no body**: look up an already-registered Data Source (e.g. one created via [Create stream](/docs/api-reference/streams/projects-project-streams-create-post)). This is the clean path: on success, returns a plain `200` with the batch. Requires the Data Source to already exist under that name — this call does **not** register anything itself. * **request body, no `sid`**: the real usage pattern from the CLI's stream-poll commands, which always send DSInfo `type: "kafka-poll"`. **Only `kafka`/`nats` are accepted as valid stream types — `kafka-poll` never passes** — so this call unconditionally returns `statusCode: 400`, `statusString: "Preview invalid DS Stream type [kafka-poll]"`. However, the server does not return early on that failed validation — it falls through and polls Kafka anyway, so **`values.dataframe` still carries a real batch of records** on the very same 400 response. Treat `values.dataframe`'s presence, not `statusCode`, as the actual success signal for this call pattern. This body-based call also does not register the DSInfo as a Data Source (the registration branch is skipped along with the rest of the failed-validation path), so a later `sid`-only poll under the same name will not find it. If both `sid` and a body are supplied, `sid` wins and the body is ignored entirely — its (in)validity has no effect on that request.