Connect ports with trade routes and reception workflows

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 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 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.

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.

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.