Stop and evict a polled stream
Stop and remove a [Poll stream](/docs/api-reference/streams/streams-poll-post) poller for the given `sid` from the server-side cache. This does not touch the underlying `kafka` Data Source's lifecycle managed by [Create stream](/docs/api-reference/streams/projects-project-streams-create-post)/ [Start stream](/docs/api-reference/streams/projects-project-streams-dsname-start-get)/ [Stop stream](/docs/api-reference/streams/projects-project-streams-dsname-stop-get)/ [Delete stream](/docs/api-reference/streams/projects-project-streams-dsname-delete) — it only tears down the on-demand poller and, if the `sid` also identifies a registered Data Source, deletes that Data Source too.
Stop and remove a Poll stream
poller for the given sid from the server-side cache. This does not
touch the underlying kafka Data Source's lifecycle managed by
Create stream/
Start stream/
Stop stream/
Delete stream —
it only tears down the on-demand poller and, if the sid also
identifies a registered Data Source, deletes that Data Source too.
Authorization
SymetryMLAuth HMAC-SHA256 signature-based authentication: requests are signed with
your secret key and sent with the Customer-ID, Sym-date,
Authorization, Content-MD5 and sym-version headers.
See SymetryML REST API Security
for the signature algorithm and a complete example.
In: header
Path Parameters
User/Customer identifier
Query Parameters
Name of the polled Data Source to stop and evict. An unknown sid is a silent no-op, but omitting the parameter entirely is not — it fails with a 500, so always send it. See the 500 response below.
Response Body
application/json
application/json
curl -X DELETE "https://example.com/c1/streams/poll"{ "statusCode": 200, "statusString": "OK", "values": {}}{ "statusCode": 500, "statusString": "Generic Exception [java.lang.NullPointerException: Cannot invoke \"Object.hashCode()\" because \"key\" is null]", "values": {}}Browse stream sources POST
List the topics/streams available on a Kafka or NATS JetStream server, without creating a Data Source. Distinct from `POST /{user}/projects/dsbrowse`, which browses file-based data sources (S3, SFTP, etc.) — this endpoint only understands `kafka` and `nats` in `values.type`. * **Kafka**: always returns a flat list of topics in `values.files`, each formatted as `<topic name>:<partition count>`. Topics starting with `_` (internal Kafka topics) are excluded. `values.path` is ignored. * **NATS**: if `values.path` is empty/omitted, returns the JetStream **stream** names in `values.dirs`. If `values.path` is set to a stream name, returns the **subjects** within that stream in `values.files`, echoing the stream name back in `values.path`. An unknown NATS stream name is **not** an error: the response is a `200` whose `dsdirectoryListing` carries only `ok: true`, with neither `dirs` nor `files`. `ok` defaults to `true` and is present on every response; unset list/path fields are omitted from the JSON entirely.
Poll stream POST
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.