Upload lifecycle

Your middleware decides who can upload. The SDK checks each file's type, size, and count against the route before it contacts Uploadfile. Uploadfile then reserves capacity for the whole batch, so parallel uploads can't spend the same remaining allowance twice.

Opening an upload session costs 4 request units per file, and each accepted part costs 1 more. Cancelling a session doesn't refund work already done.

The browser sends file bytes straight to signed Amazon S3 URLs. Large files upload in parts. The SDK tries each part up to three times and gets a fresh signed URL for every attempt.

The hosted service needs no CORS setup on your side. The storage bucket accepts uploads from any origin because each URL is signed for one part and expires. Your API key never leaves your server, and the browser only holds a token scoped to its upload session.

After the last part, Uploadfile verifies the file, publishes it, and calls your route's onUploadComplete with the file's key and URL. The value it returns reaches the browser as serverData in onClientUploadComplete.

In development the SDK polls Uploadfile for these events and runs onUploadComplete on your machine, for up to 30 minutes per upload. In production Uploadfile posts them to your route over HTTPS on port 443, follows no redirects, and waits up to 15 seconds for a response.

Uploadfile can deliver the same event more than once. Write onUploadComplete so that running it twice for the same file key changes nothing, for example with an upsert keyed on file.key.

createUpload, returned by generateReactHelpers, gives you one upload you can pause, resume, and abort. Pausing keeps the session open, and resuming sends only the missing parts. uploadFiles accepts an AbortSignal and cancels the session when it fires.

Cleanup releases the capacity held by expired and cancelled sessions. Deleting files and cancelling uploads still work when an application is over capacity or its delivery is paused.