Request and receive files
Create an incoming request, share its link, and follow files from selection to verified publication.
On this page
Create a request
Sign in to your deployment and open Receive. Check the active tenant, then create a request with a label that will still make sense in transfer history.
| Setting | How to use it |
|---|---|
| Destination subfolder | Keep a project or contributor’s files together beneath the configured receive root. |
| Expiry | Limit how long new submissions can use the request. |
| Password | Add a separate secret that the sender must provide. |
| Size cap | Bound the request’s byte allowance alongside the tenant’s quota. |
| Notifications | Opt into the configured receive events for the request. |
Copy the link or share its QR code. Anyone who has the link can attempt to use it under those restrictions. Send a password through a separate channel when appropriate.
Decide what happens after arrival
In After files arrive, select a Reception project to apply checks, approval, and destination copies to each completed upload. Existing requests have a Reception workflow editor. Changes apply to subsequent completed uploads.
Projects can copy to S3, mounted shared folders, or other VOTPort deployments, and either hold the local link for every destination or release after local checks while copies continue. Read reception workflows and trade routes for setup, progress, retries, and signed custody evidence.
Send through a request link
- Open the link supplied by the receiving team.
- Check the destination identity and request label. Enter the password if prompted.
- Select files or drop a folder into the page. Review the selected names and total size.
- Start the transfer and keep the page open while it is running.
- Wait for the completed result before disconnecting the source drive or closing the browser.
The browser prepares the cryptographic identities and manifest before or alongside transfer work. Reading a large folder can take time even before the network is busy. Keep source files stable: do not continue rendering into a selected file while sending it.
For native QUIC and transfer history outside the browser, use the desktop client or command line with the same request link.
Find the completed files
VOTPort verifies incoming ranges against the announced content identity. Files are staged until ready for publication, then made available without overwriting existing files. Repeated names use an available suffixed name, such as name-1.ext.
Both HTTP uploads and native QUIC pushes publish each completed file while the session continues. If a multi-file job stops halfway, files that already finished remain published even though the package did not complete. Partial files and checkpoints support recovery; an incomplete reception package does not start destination copies.
The Receive history lets the operator inspect the upload and its files. The configured receive root contains the published files and their .vot-receipt sidecars. Named tenants have separate directories beneath that root.
Recover after an interruption
Keep the original selection available and unchanged. Use the offered resume or retry controls and inspect the result before creating a new job. The native client’s journal records transfers that can be resumed; the server’s session lifetime, link expiry, revocation, and quotas still apply.
A retry is not permission to bypass a closed request. If access has expired or the destination is full, ask the owner to resolve that condition first. Abandoned staging is cleaned up according to the session policy; it does not appear as a verified completed file.
Close the request
Close or revoke a request when you no longer want new submissions. Removing access does not remove files already received. File deletion, retention, and backup retention are separate operations.
To hand received work onward, use Send beside the received file or prepare the appropriate outbound delivery. Keep receipts with files when the receiving team needs to verify them later.