Skip to main content
A search is asynchronous. POST /v1/searches reserves the money, writes the run, and answers 202 with an id before any searching happens. From there you have two ways to follow it, and they read the same run: stream /events for live stages, or poll the run and wait for a terminal state. A run can take many minutes. Nothing holds a request open for the whole run any more, so a long timeout is only needed on the stream. To keep a run on particular websites, send sites as a comma-separated list such as linkedin.com, x.com. Leave it out to search the web.
That is the whole body: 202, an id and a status. If your balance cannot cover the $5.00 reservation the call is 402 instead and no run is started. See Errors.

2a. Stream the events

Each record is id: <seq> then data: {json} then a blank line. Lines beginning with : are keepalives and carry nothing. The server closes the stream once the run is terminal and you have caught up, so the connection ending is not by itself a failure, and nor is it proof the run finished cleanly. Keep the last id you saw: it is what lets you reconnect without a gap or a repeat, which Streaming works through in full.

2b. Or poll the run

Poll every few seconds, not every few hundred milliseconds. result holds the final event once the run is terminal, which is the table to store; see Result row.

3. Stop a run, if you need to

The flag is raised immediately; the run unwinds within seconds and lands as stopped with whatever had already passed the funnel. Dropping the event stream is not a stop: the run keeps going on the server and keeps costing money.
Read until type is done, but do not rely on it arriving. The rows you store are in the final event, which arrives just before cost, usage and done. A run that was interrupted can end without any of the four, which is why the run’s status is the authority on whether it is over. See The run.