deep_search
Run an agentic search over a workspace. Cost class: job.
The caller receives a 202 with a queued :class:~ndi_service.app.platform_api.results.Job immediately, and polls GET /jobs/{id} for the result once the job succeeds.
Every run uses one configuration: a reasoning engine with a thinking budget, the internal CLI tool surface, and the workspace's knowledge graph when one is built (the 2026-09 five-lane evaluation picked it as the most accurate lane).
One implementation serves every scope: the source-level agent (deep_search_v2). It browses, reads, and computes over the uploaded files exactly as an API caller would, writes its own SQL over the tables in scope, and every executed statement lands on the result as a receipt (sql_receipts) — a figure and the query behind it travel together. (Jobs created before the 2026-09 consolidation may carry the retired classic loop's intelligent_search kind; they stay readable via GET /jobs.)
Scope never changes the configuration: paths scopes the run to exactly those uploaded files — every tool the agent runs (search, listings, reads, ask-file, SQL, the shell's ndi commands) sees only them and the content ingested from them, enforced server-side against the stored job. Each entry must name a visible uploaded source file (file_not_found / access_denied otherwise, before any job is created). With path_prefix the two add up: the run covers the folder's files plus the named ones.
Pass the result's session_id to ask a follow-up. With the same folder/file scope and access grants, the agent resumes that transcript. Changing either starts a fresh conversation and returns its new session_id, so prior tool results cannot cross the new scope boundary. Older transcripts without a scope snapshot also restart. Classic thread ids return session_not_found; retrying the original request with its idempotency key still returns that historical job.
allow_clarification lets the agent ask instead of guessing on a genuinely ambiguous query: the succeeded result then carries the questions in clarification_questions (and as text in clarification) with answer null. Answer them in the same thread — send the result's session_id with the same query and clarification_answers, or with any refined query. Off (the default) the agent never asks back.
Retrieval only: this job never grounds. To pin a quote to a region of its source document, call document-operations ground on the file the citation names with its quote as the target text — separately, and only for the citations you actually need a locator for.
exhausted: true means the step budget ran out before the agent finished — a successful, partial response, not a failure.
Args: body: Search parameters: query, context, allow_clarification, clarification_answers, path_prefix, paths, session_id. context: Resolved workspace plus the caller's access predicate. session: Database session. wait_seconds: Bounded inline wait (0 → immediate 202). idempotency_key: Replaying with the same key returns the original job. response: Injected by FastAPI for status-code management. temporal: Temporal client used to dispatch the workflow. search_model: Internal engine pin; overrides the configuration's engine, never its tooling. search_playbook: Internal procedure pin; retired with the classic loop — refused. report_usage: Internal usage-accounting switch. postprocessing: Internal optional-postprocessing mode; none skips the detached presentation/grounding sidecars after commit.
Returns: A queued :class:~ndi_service.app.platform_api.results.Job. On success the result is a :class:~ndi_service.app.platform_api.results.DeepSearchV2Result, naming itself in result_type.
Request
- Base URLhttps://ndi-api.nace.ai (the document declares no server; this is the origin it was published from)
- AuthAPI key in header X-API-Key
- TypeScriptA function with typed inputs. Its response is checked against the schema.
Path parameters
Workspace identifier.
Query parameters
Bounded inline wait. 0 (the default) returns 202 immediately. Above 0 the route returns 200 with a terminal job if the work finished in time, and 202 with the still-running job if it did not. Either way, read status.
Headers
Replaying a request with the same key returns the original job with 200, never a second job. The key is kept with the job for replay and never cleared, so it must not contain personal data.
Request body
Response
Successful Response
Changes
No recorded changes to this operation across all 1 revision of this API.