> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Upload a file directly to Compute description: >- Prepare an artifact, transfer it in digested parts, then complete it so the bytes are verified. Recover from an expiry or an interruption without corrupting the upload. route: /docs/compute/inputs/direct-upload page_id: docs-compute-inputs-direct-upload page_type: howTo content_layer: guided documentation surface_profile: guided_docs audience: Integrators and AI agents uploading input files to Compute voice: D reader_question: How do I upload a file to Compute and prove it arrived intact? primary_action: Complete the upload and reference the artifact source_locale: en-US source_status: APPROVED source_version: docs-compute-inputs-direct-upload-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## Before you start Know the file's size, the number of parts you will send, and the data profile the content falls under. Confirm the file fits the ceiling the workflow declares, because that ceiling is smaller than what the transfer layer would accept. An upload authority is time-bounded. Plan to transfer inside its window rather than hold it open. ## The three steps 1. Prepare the artifact. You declare size, part count and data profile, and you receive an artifact reference, an upload target, a part size and an expiry. 2. Transfer the parts to the target you were given, using the headers you were given. 3. Complete the artifact by supplying the manifest digest and the part-root digest. The artifact moves through its own states as you go: `PLANNED`, then `UPLOAD_AUTHORIZED`, `UPLOADING`, `UPLOADED_UNVERIFIED`, `VERIFIED`, and finally `ACCEPTED` or `REJECTED`. Only `ACCEPTED` means a job may reference it. For which ceiling actually binds your file, see [how a file reaches Compute](/docs/compute/files). ## Send the target and headers unchanged The prepare step hands you a signed target and the exact headers to send with it. Send them as given. A rewritten header, a re-encoded path or an added query parameter breaks the signature. The transfer is then refused rather than repaired. If a client library rewrites headers for you, turn that behavior off for this request. ## Transfer in parts, and let digests do the ordering Each part carries its own digest. Parts may travel in parallel, and arrival order does not matter, because the part index decides where each one belongs. That is also what makes an interrupted transfer safe. An artifact is its own idempotency scope. Re-sending a part with the same identity and the same digest is an exact replay, and it returns the earlier result. Sending different bytes under the same part identity is equivocation, and it is refused rather than accepted quietly. ## Complete it, and read the verification Until you complete the artifact it sits at `UPLOADED_UNVERIFIED`. Bytes have arrived; nothing has been proven about them. Completion supplies the manifest digest and the part-root digest. Those are recomputed on receipt and compared. A truncated, reordered or altered transfer fails that comparison and the artifact goes to `REJECTED`, with a safe reason and a concrete next action. ## Never log a signed URL A signed upload target is temporary bearer authority. Anyone who holds it can write to your artifact until it expires, without any other credential. So keep it out of shell history, application logs, CI output, screenshots, bug reports and any dump you attach to a support request. Support never asks for one and never needs one. When you do contact support, give the artifact reference and the `request_id` from the response envelope. Those identify the transfer without granting anything. ## Recovering from an expiry or a failure If the authority expires before you finish, prepare a new upload authorization for the same artifact and continue. Re-sending identical parts is a replay, so you are not penalized for overlap. If completion reports a digest mismatch, re-read the source and re-send the parts whose digests disagree. Do not complete again with the same manifest and different bytes; that is the equivocation case, and it refuses. If the artifact is rejected outright, the reason names what to change. Work from [what to do when an input is rejected](/help/compute/input-rejected) rather than retrying the same bytes.