Background Requests
Queue long-running research and poll or stream for the result.
By default, POST /v1/research runs synchronously and blocks until the final answer is ready. For complex research at deep or exhaustive effort, that can exceed client-side timeouts or tie up a worker. Set background: true to run the request asynchronously and receive a task handle immediately. The frontier effort level requires background mode—synchronous requests with research_effort: "frontier" return 422.
In background mode, the response is a task object rather than the research result:
A task moves through the following states: queued → running → completed | failed | cancelled.
Poll for the Result
Call GET /v1/research/{task_id} to check status. The result field is null until the task completes. If the task fails, status is failed and error contains a diagnostic message.
Stream Progress
GET /v1/research/{task_id}/stream returns Server-Sent Events (SSE) with real-time progress. The stream starts with a connected event and closes when the task reaches a terminal status. Use ?from_id=N to replay events after reconnecting. Once the stream closes, poll GET /v1/research/{task_id} to retrieve the full result.
End-to-End Python Example
The Python SDK ships helpers for background tasks in youdotcom.research_helpers, so you do not have to write the submit-and-poll loop yourself. research_and_wait() submits the task, polls until it reaches a terminal status, and raises if it fails or times out.
To submit and poll as separate steps—for example, when the task handle is stored and picked up by another worker—use research_background() and poll_research_task():
To follow progress as it happens, stream_research() yields the Server-Sent Events described above. Each event carries an id, an event name, and a data payload, and unknown event names pass through rather than raising, so new event types will not break your consumer.