Skip to main content
documents.createUpload 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

FileContent is a path string, URL (file: protocol only), Uint8Array, ArrayBuffer, Blob, File, or a { name?, read() } stream object.

Parameters

Returns

Promise<UploadResponse>:

Upload options

From a path string (Node.js)

Use a local path string when the file is on disk:

From a file: URL (Node.js)

Only file: protocol URLs are accepted. For remote sources, pass a UrlSource directly to the operation instead of uploading through this method.

From a File object (browser or Node.js 20+)

From raw bytes (Uint8Array or ArrayBuffer)

Raw bytes carry no filename. Supply one so NDI can select the correct processing lane:
Passing Uint8Array or ArrayBuffer without file_name throws a client-side error before any network request.

From a Blob (browser)

From a readable stream

Any object with a read() method is accepted:

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 createUpload 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 usage

createUpload always returns a Promise. Use await or chain .then():

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 createUpload 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.
  • Client-side Error — a path string that does not exist, or raw bytes supplied without file_name; thrown before any 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 createUpload itself. unsupported_file_type is synchronous and non-retryable. A rejection from createUpload 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 strings

Use a local path string for Node.js so the filename travels with the bytes automatically.

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 Uint8Array, ArrayBuffer, or Blob 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