UPLOADFILE DOCUMENTATION

Upload lifecycle

Understand authorization, direct transfer, and completion.

Authorize and reserve

Your middleware establishes who can upload. File policy checks enforce the declared type, size, and count. The service reserves capacity before issuing upload destinations so concurrent uploads cannot all spend the same remaining allowance.

An authorized per-file upload session consumes four request units. Each accepted upload part consumes one more. Aborting an authorized session does not erase the work already performed.

Transfer directly to storage

Upload bytes go to presigned storage destinations. Large uploads use multiple parts. Preserve part numbers and ETags, and include every completed part when finishing the session.

Storage CORS must allow your frontend origin, the required PUT headers, and the ETag response header. Do not put your service API token in requests to storage.

Complete and observe

A successful transfer is followed by server-side completion and processing. Wait for the file’s ready state before treating it as published. Callback delivery can be retried; your application should handle the same event idempotently.

Expired and canceled sessions release unused reservations through cleanup. Deletion and upload cancellation remain available even when an application is over capacity or delivery is paused.

Up nextServer API

Uploadfile is an independently operated service. The framework SDK is forked from the MIT-licensed UploadThing SDK; UploadThing’s hosted backend is not included in that source.