Skip to main content
documents.create_upload stages bytes for one parse, extract, split, classify, or ground operation. It returns an UploadResponse that can be passed directly as the operation’s source.
A granular upload is temporary and single-use. To keep a file, upload it to a workspace.

Basic usage


Method signature

Parameters

Returns

UploadResponse:

Upload options

From a path

Use Path when the file is on disk:
String filesystem paths are also accepted:

From an open binary file

From bytes

Raw bytes do not have a filename. Supply one so NDI can select the correct processing lane:

Custom unused-upload TTL

The TTL only bounds an upload that no operation consumes. Once a document operation uses the handle, NDI removes the staged bytes when that job finishes. The handle cannot be reused for another operation.

Use a URL instead

You do not need to call create_upload when NDI can fetch the source directly:
The URL must use HTTPS and be reachable by NDI. For private storage, provide a presigned HTTPS URL. See Sources and uploads.

Async upload


Limits and formats

The upload endpoint enforces the byte cap configured for your API key and rejects formats that no granular document operation supports. Format support then narrows for the operation that consumes the upload; a file accepted by upload can still be rejected by parse, split, classify, extract, or ground.

Format support

Check which document, image, spreadsheet, email, and media formats each operation accepts.

Errors and limits

Review upload size, rate, concurrency, and request limits.

Error handling

Common upload outcomes:
  • file_too_large (413) — the bytes exceed the upload cap.
  • zero_byte_file (422) — the staged file is empty.
  • unsupported_file_type (422) — raised by create_upload when no granular operation supports the format, when the filename conflicts with a conclusive byte signature, or by the consuming operation when that specific operation does not support it.
  • FileNotFoundError — a local path does not exist; this is raised before an HTTP request.
Consuming operations can return upload_expired (409) for an expired handle or upload_not_found (404) for an unknown, cross-tenant, or already removed handle. These are not raised by create_upload itself. unsupported_file_type is synchronous and non-retryable. A rejection from create_upload creates no upload handle; a rejection from the consuming operation creates no job, so there is nothing to poll with jobs.wait. The service inspects only a bounded byte prefix and treats multipart Content-Type as advisory.

Best practices

Prefer Path objects

Use pathlib.Path for local files so the filename travels with the bytes.

Create near use

Stage a granular upload immediately before its operation. It is a temporary, single-use handle.

Name raw bytes

Always pass file_name with raw bytes so NDI can infer the format.

Use workspaces for persistence

Put files in a workspace when they must survive one operation or become searchable.

Next steps