Transfer Capabilities — Xferity File Transfer Features

Transfer Capabilities

This page is the explicit, structured reference for Xferity’s transfer execution capabilities.

Supported protocols

Xferity supports the following enterprise file transfer protocols:

SFTP — SSH-based partner directory exchange with host key verification
FTPS — FTP over explicit TLS with passive mode and SHA-256 certificate fingerprint pinning
AS2 — Certificate-based B2B message exchange with MDN receipt handling (sync and async)
Amazon S3 — Object upload and download with IAM or static credentials
S3-compatible storage — MinIO, Cloudflare R2 via endpoint override
WebDAV — Upload and download over HTTPS with PROPFIND listing and MKCOL directory creation
Azure Blob Storage — Upload and download using shared-key, connection-string, or DefaultAzureCredential authentication

Flow-driven execution model

Every transfer in Xferity is defined as a Flow — a named, versioned YAML configuration file.

Flows define:

transfer direction (upload or download)
source and destination location
partner or inline endpoint reference
file matching rules (glob patterns, include, exclude)
scheduling expression (six-field cron with seconds)
retry behavior
idempotency mode
cleanup behavior (delete, archive, dead-letter)
payload handling (PGP encryption, decryption, signing)
notification routing

Job execution model

When Postgres-backed mode is active:

supported triggers enqueue durable Job records in the PostgreSQL job queue
Workers claim and execute jobs using SELECT FOR UPDATE SKIP LOCKED
jobs survive process restarts and crashes
execution results are persisted for later inspection

In file-backed mode: flows execute in-process immediately when triggered.

Scheduling

Six-field cron expressions — seconds, minutes, hours, day-of-month, month, day-of-week
Interval-based polling — xferity run-service <flow> --interval-seconds N
On-demand execution — xferity run <flow>
API-triggered execution — POST /api/flows/<flow>/run
Batch execution — xferity run-all runs all configured flows

Retry with exponential backoff

Configurable max attempts — per-flow setting
Base delay and delay cap — prevents infinite retry escalation
Jitter — random spread to prevent coordinated retry storms across concurrent flows
Permanent vs. transient distinction — crypto key mismatch is permanent; network timeout is transient
Per-file error tolerance — configurable file-level failure threshold; one bad file does not abort the whole batch

SHA-256 content-hash idempotency

Each successfully processed file is tracked by its SHA-256 content hash
On rerun, retry, or restart: files whose hashes are already present are skipped automatically
Prevents duplicate uploads or duplicate processing after partial failure, crash, or manual rerun
Idempotency mode is configurable per flow
hash mode is the recommended default for production partner exchange

Distributed flow locking

Lock acquired at flow start; prevents two instances of the same flow from running concurrently
Configurable lock wait time — optional wait for an existing lock to release
Stale-lock takeover — lock exceeding its max age is reclaimed automatically
Ownership-aware release — one process cannot release another’s lock

Dead-letter handling

Files that exhaust all retry attempts are moved to a configurable dead-letter directory
Prevents file loss in recovery scenarios
Provides a clear inventory of files needing manual attention
Dead-letter artifacts are inspectable and can be retried manually

Recovery and resume

xferity resume <flow> — re-enters a flow from its last committed state
Idempotency tracking prevents re-processing files already completed for that run
xferity flow history <flow> — shows per-run outcomes and retry counts
xferity trace <file> — shows the file’s full lifecycle across all runs

File matching

Glob pattern includes and excludes
Remote file stability checks (SFTP) — waits for files still being written before picking up
Configurable minimum file age thresholds

Cleanup behavior

Delete after transfer — configurable per flow
Archive after transfer — move processed files to a local archive path
Dead-letter on exhaustion — move unprocessable files to dead-letter path

Payload handling in flows

Flows can invoke payload protection as part of transfer execution:

OpenPGP encryption — encrypt before upload
OpenPGP decryption — decrypt after download
OpenPGP signing — sign before upload
OpenPGP verification — verify signature after download
Provider modes: gopenpgp, gnupg, or auto

Capability summary

Xferity transfer capabilities include:

SFTP (SSH host key verification, password or key auth, remote stability checks)
FTPS (explicit TLS, passive mode, SHA-256 fingerprint validation)
AS2 (certificate roles, MDN receipts sync and async, inbound and outbound)
S3-compatible storage (AWS S3, MinIO, Cloudflare R2)
WebDAV (Nextcloud, ownCloud, SharePoint DAV endpoints, Box, Apache mod_dav, nginx-dav)
Azure Blob Storage (Azure Storage Accounts, sovereign cloud endpoints, Azurite)
Flow-defined YAML transfer workflows
Durable PostgreSQL-backed job queue with worker execution
Six-field cron scheduling
Exponential backoff retry with jitter
SHA-256 content-hash idempotency
Distributed flow locking with stale-lock takeover
Dead-letter handling for exhausted retries
Resume support from last committed state
OpenPGP encryption, decryption, signing, verification in flows