fact_search
Changed onRun the fixed single-shot search pipeline over a workspace. Cost class: job.
One retrieval pass (hybrid search, plus the knowledge graph when the workspace has one, fused when both legs return candidates), targeted page reads or retrieved passages for prose (specialized engines for tables or images), then one answering pass — so it returns in seconds where deep-search may take minutes. The caller receives a 202 with a queued :class:~ndi_service.app.platform_api.results.Job and polls GET /jobs/{id} for the :class:~ndi_service.app.platform_api.results.IntelligentSearchResult — the identical result shape deep-search lands, evidences and coverage included.
Single-shot: a fact-search run keeps no conversation, so the result's session_id is always null and the request body has no session_id field. For a thread you can ask follow-ups in, call deep-search. It always answers — the result carries a direct grounded answer, with reasoning stating how the pipeline read the query — and never asks back: the body has no allow_clarification either (a fixed pipeline has no agent who could pose the question).
paths scopes the run to exactly those uploaded files: every retrieval leg 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.
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 evidence names (source_file_id) with its quote as the target text.
Request
- Base URLhttps://ndi-api.nace.ai
- 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. Waiting does not change how an admitted job is counted and takes no max_concurrent_sync slot (that limits synchronous calls such as the legacy synchronous API and /v1/systemone). For retained jobs, the deployment may shorten the wait and return 202 with the running job; poll GET /v1/jobs/{job_id}. For parse, split, classify, categorize, extract and ground, a zero_retention tenant must pass wait_seconds above 0.
Headers
Use the same key to recover an earlier request. A replay returned as a Job carries Idempotent-Replayed: true and replayed: true without a new charge; Job credits keeps the original cost. Re-serving a settled inline tool answer reports zero credits for that call and also carries Idempotent-Replayed: true; a fresh re-execution after a transient failure carries no header. The key is kept with the job for replay and never cleared, so it must not contain personal data.
Request body
Response
Terminal job or idempotent replay of the original job; read status and replayed.
Changes
- info
added the optional property
to the response with the status - info
added the success response with the status
- info