---
title: Connect ports with trade routes and reception workflows
label: Trade routes and reception
description: Apply checks and approval to completed uploads, copy to multiple destinations, and retain signed custody evidence between VOTPort deployments.
layout: docs
order: 115
---

A reception project starts work after an upload completes. It can check the package, hold it for approval, and deliver verified copies to S3, a mounted shared folder, or another VOTPort. Each destination reports its own progress and errors.

## Choose the path through your ports

A **port** is one licensed VOTPort installation. One company might use a single port connected to several storage destinations, or a separate port at each site. A **trade route** carries a package from one port to another, with signed custody evidence from the handoff. A **reception project** decides what happens to a completed upload at the receiving port.

For example, a shoot uploads to a studio's port. Its reception project checks the files and sends them to the finishing team's port. That port can require its own approval before copying to its shared folder or forwarding to a delivery partner. Each installation has its own access rules; a route does not copy accounts or permissions between them.

Copying to several S3 buckets or shared folders from one port does not create more ports. A connection to another installed VOTPort is the port-to-port handoff.

## Attach a reception project

1. In **Workflows > Projects**, create or edit a project and enable **Use this project for incoming files**.
2. Configure required metadata, recipients, checks, and approval. Select destination connections and the release rule described below, then save the project.
3. In **Receive**, open **After files arrive** and select the **Reception project** when creating a request. Supply its required metadata and recipient selections.
4. For an existing request, use its **Reception workflow** editor. The selection applies to subsequent completed uploads.
5. Send a complete upload through the request, then follow the reception job in **Workflows > Deliveries**.

The server queues the reception job in the same database transaction that records upload completion. An incomplete upload does not start destination copies. Its individually completed files remain visible, but ordinary sharing cannot bypass the reception release policy.

Reception jobs retain and verify the original received files until retirement, including while the resulting delivery remains active. They do not make another payload snapshot. Keep those files unchanged; altered sources fail verification. Jobs also work for tenants that do not use an outbound library.

## Choose destinations and release timing

Platform administrators configure connections in **Storage > Add storage > Destination type**:

| Type            | Setup                                                                                                         |
| --------------- | ------------------------------------------------------------------------------------------------------------- |
| S3 storage      | Bucket, region, credentials, root prefix, and optional KMS key.                                               |
| Shared folder   | An absolute directory path already mounted and visible to the VOTPort server, including inside its container. |
| Another Votport | The destination's receive-request URL and optional password, saved privately.                                 |

**Test saved connection** checks access without transferring a package. S3 listing success does not establish export-write or KMS permission. See [storage setup](/docs/self-hosting/storage/) for connection details.

Select up to 16 connections under **Workflows > Projects > Destinations**, then choose **Release the download link**:

| Release rule                                                | Behavior                                                                                                                                    |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **After all destinations finish**                           | The default. Hold the local link until checks, approval, and every destination finish.                                                      |
| **After local checks and approval; copy in the background** | Release the local link after local requirements pass while destination copies continue. A failed destination does not retract that release. |

These destination and release rules also apply to outgoing project deliveries. A released local link is not confirmation that every remote copy is complete. Check the individual destination results before starting work that depends on them.

## Retry destination failures

Up to two destination legs run concurrently. Successful legs remain complete across retries; a failed destination does not restart copies that already finished. Errors use persistent exponential backoff. After five worker attempts in a retry cycle, use **Retry** to begin another cycle after correcting the cause.

The job shows destination progress, errors, and scheduled retries. macOS and Windows Workflows also show reception and destination status. An initial failure notification and signed workflow events can feed your production system. Use [replayable webhooks](/docs/administration/workflow-events/) when downstream delivery must be recoverable; workplace messages remain best effort.

## Set up a trade route

1. On the destination port, create a receive request with the intended destination, expiry, password, and byte limits. Attach a reception project there if the incoming package needs checks, approval, or onward delivery.
2. On the sending port, open **Storage > Add storage**, choose **Another Votport**, and save that request's URL and password. Treat them as credentials.
3. Use **Test saved connection** to check access, then select the connection in the sending project's **Destinations**. Save its release rule.
4. Run a complete package through the project and inspect the destination result in **Workflows > Deliveries**. Check the receiving port's upload and any reception job it starts.
5. Export the custody evidence from both sides and confirm the intended onward destinations before relying on the route for production work.

Native acceleration needs reachable UDP on the receiving port as well as HTTPS. Keep both server versions compatible. A saved-connection test does not transfer files or prove that a full package will fit the destination's quota, request limits, or policy.

## Retain custody evidence between ports

A connection to another VOTPort creates a signed trade route. The sender signs the frozen package manifest; the receiving port verifies the files and signs its own custody receipt when it records completion. Forwarding includes the parent's receipt digest and signed ancestry. Receivers verify the chain and reject loops; a route permits at most eight sending ports.

Peer transfers use native QUIC when available and HTTP otherwise, with receiver checkpoints for resuming. A receipt already committed by the destination lets a retry recover from a lost completion response without creating another upload. Native acceleration requires the destination's advertised UDP endpoint to be reachable; see [native networking](/docs/self-hosting/native-transfers/).

On the sending job's destination entry, choose **Download custody evidence** to save the receipt, ancestry, and any revocation acknowledgment. On the receiving port, use **Receive > Trade route > evidence**. Preserve trusted signing keys with the evidence.

Custody records establish the signed handoff between deployments. They do not replace an individual recipient's explicit acceptance or strengthen a file receipt's recorded storage assurance. See [verification and receipts](/docs/using/verification/).

## Keep each site's access independent

The destination request determines its own tenant, quota, and reception project. Routes exchange file identities, the label, informational metadata, and signed custody evidence. They do not synchronize users, credentials, request links, tenant names, memberships, or project policies. Configure each port's access independently, whether it belongs to another facility or an external vendor.

## Revoke a managed route

Cancelling, revoking, or expiring the source delivery queues a signed revocation separately from payload work. The destination stops route-managed sharing and forwarding, then signs an acknowledgment. Further managed ports receive their own requests. The UI distinguishes pending and acknowledged revocations; an offline destination is retried with capped backoff.

Revocation cannot recall files already downloaded, S3 exports, shared-folder copies, or independent manual copies. Deleting a source tenant requires acknowledgment of its outgoing route revocations. If the destination tenant has already been deleted, its port can acknowledge that the exact route is absent.