upload_file
Changed onUpload a source file into the workspace. Cost class: job.
The one route with two credentials: the tenant's X-API-Key, or a short-lived X-Upload-Token grant minted by create_upload_grant — which is how a customer's end client uploads directly without ever holding the key. A grant redeems the multipart path only, within the constraints frozen into it (workspace, optional pinned path, byte cap).
Two content paths, per the UploadFileRequest contract:
- multipart/form-data — file bytes in a file part, request parameters as a JSON string in a metadata form field.
- application/json — an UploadFileRequest body whose source carries a UrlSource; the bytes are fetched server-side and then take the exact same storage/ledger path as multipart.
Upload does NOT ingest. The file lands with ingestion_status = discovered and is not searchable. Making it searchable requires a separate POST .../ingestions call. This keeps the cost model honest: a caller can upload a thousand files and choose to ingest fifty.
Request
- Base URLhttps://ndi-api.nace.ai
- Auth
- API key in header X-API-Key
- or API key in header X-Upload-Token
- 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 multipart/form-data
Response
Successful Response
Changes
- info
added the optional property
to the response with the status
- info