---
title: Prepare and deliver files
description: Share the right files, control access, and distinguish a download start from a verified arrival.
order: 120
layout: docs
label: Delivering files
---

## Prepare the library

Open **Deliver** in your deployment. The outbound library contains files beneath the configured outbound directory, including nested project folders and files uploaded by operators.

Under **Choose files**, select existing library files or upload a new selection. Use **Upload into folder** to place uploads in a library directory and **Search files** to narrow the listing. A server-side render or export process can also populate that library. Finish writing those files before issuing a delivery; a changed source can fail the identity check when it is served.

For a file already received by VOTPort, **Send** beside the file in **Receive** starts an onward delivery.

## Issue a delivery link

Select individual files or share a project folder, then complete **Set access and share** with a recognizable label, expiry, optional password, and download cap. Select **Create download link** to issue it. The current server supports up to 1,000,000 files in a library selection or direct folder share. Large selections take time to prepare because VOTPort hashes the selected content.

The issued URL is shown when the grant is created. Save it then and share it only with the intended recipients. A password protects metadata, file downloads, receipt downloads, and the ZIP as well as the landing page.

For multi-file links, the download cap applies per file and per full-delivery round. A cap of one permits one download of each file or one full delivery. Set limits with interrupted downloads and multiple intended recipients in mind.

## Use a project delivery workflow

For required metadata, sequence or media checks, malware scanning, approval, scheduling, or S3 import/export, open **Workflows > New delivery**, or follow **Use a project workflow** from Deliver. Choose a configured project and create a persistent job. The download link becomes available after required checks and human approval, with project policy choosing whether it also waits for all destination copies. A locally released link can coexist with pending or failed destination copies.

Protected project folders cannot bypass these rules through ordinary sharing. Recipient-enrolled projects require proof of possession of a selected device key on browser and native paths. See [delivery workflows](/docs/using/workflows/) for preparation, deadlines, and recovery.

## Download a delivery

Open the delivery link and enter its password if needed. Check the displayed selection before starting.

| Method          | Useful when                                           | What to expect                                                       |
| --------------- | ----------------------------------------------------- | -------------------------------------------------------------------- |
| Individual file | You need one item or a resumable download             | The HTTP endpoint supports a single byte range and a download lease. |
| ZIP             | You want a multi-file browser download in one archive | The archive contains payload files; receipts are separate downloads. |
| Separate files  | You want the selection without unpacking an archive   | Availability depends on the browser’s bulk-download support.         |
| Native client   | You want files verified into a chosen folder          | QUIC is used when available, with HTTP fallback where supported.     |

Before an individual HTTP stream starts, the server checks the source identity and receipt and then serves verified ranges. ZIP and grouped downloads verify staged copies for the request. Native receivers check the announced roots and can publish completed files while the rest of the delivery downloads.

## Resume without discarding progress

The desktop client and CLI preserve interrupted receive state. For HTTP receives, keep the partial and its hidden lease sidecar together. The saved allowance can be reused for up to 24 hours, bounded by the delivery’s expiry. A retry may request the password again.

An exhausted delivery can still show metadata for recovery, but it cannot authorize a fresh download or a new native capability beyond its cap. Revoked and expired links remain unusable. If recovery cannot proceed, ask the owner for a valid delivery rather than renaming partial files as completed ones.

## Read the delivery history

Delivery history includes aggregate and per-file download starts, with first and most recent timestamps. A start tells you that access began. It does not establish that a recipient saved every byte to their local storage.

The native client reports completion after verification and publication, and queues a signed verification report. Browser recipients can select and hash their saved files on the delivery page. Explicit acceptance is a separate signed action; inspect [recipient evidence](/docs/using/verification/#confirm-recipient-verification-and-acceptance) instead of treating a download start as completed delivery.

## Revoke access

Revoke the grant when the handoff is over or a link was shared incorrectly. Revocation prevents further authorized use; it cannot recall copies a recipient already downloaded. Removing a library source or changing its bytes is a separate action and can make a delivery fail.