Transfer Protocols in Xferity — SFTP, FTPS, AS2, S3-Compatible Storage, WebDAV, and Azure Blob

Protocols

Xferity supports the following protocols for partner file exchange:

• SFTP — SSH-based partner directory exchange
• FTPS — FTP with TLS for legacy-compatible partner workflows
• AS2 — Certificate-based B2B message exchange with MDN receipts
• S3-compatible storage — Object storage (AWS S3, MinIO, Cloudflare R2)
• WebDAV — HTTP-based file exchange for WebDAV-compatible platforms and document systems
• Azure Blob Storage — Azure object storage exchange for upload and download workflows

These protocols are not interchangeable. Each has a different trust model, authentication pattern, and failure profile. Xferity keeps those differences explicit in configuration and runtime behavior.

---

Protocol roles in Xferity

Transfer transports

SFTP, FTPS, S3-compatible storage, WebDAV, and Azure Blob Storage are used as transfer transports in flows.

A flow references one source and one destination. The transport is implied by the partner type or inline endpoint in the flow.

Message exchange

AS2 is a message-oriented exchange protocol, not a directory transfer protocol. It uses certificate roles for signing, encryption, and verification, plus HTTPS transport trust and MDN processing.

That distinction matters when designing partner exchange workflows.

---

Trust model differences

SFTP

SFTP trust is based on SSH host verification.

Connections require one of:

• a known_hosts file
• a configured host_key_fingerprint (SHA-256)
• an explicit allow_insecure_host_key: true override

If none is present, the connection fails. Xferity does not silently accept unknown host keys.

FTPS

FTPS trust is based on TLS certificate validation.

Xferity supports:

• explicit TLS mode
• passive mode
• standard TLS verification against system CA pool
• optional SHA-256 server certificate fingerprint validation

S3-compatible storage

S3-compatible storage trust depends on:

• TLS to the API endpoint
• credential source (IAM role or static key)
• bucket and prefix scoping

It does not use SSH host keys. The trust model is endpoint + TLS + credential.

AS2

AS2 trust is certificate-based and role-specific. The runtime may use separate certificates for:

• signing outbound messages
• verifying inbound message signatures
• encrypting outbound messages
• decrypting inbound messages
• HTTPS transport trust (client or server certificate)

AS2 also includes MDN (Message Disposition Notification) handling — synchronous or asynchronous receipts that confirm delivery.

WebDAV

WebDAV trust is based on HTTPS certificate validation and the credentials used to access the DAV collection.

Xferity supports:

• HTTP GET and PUT for file transfer
• PROPFIND listing for download workflows
• MKCOL for automatic collection creation on upload
• Basic authentication when username and password are configured

Azure Blob Storage

Azure Blob trust depends on:

• TLS to the blob service endpoint
• credential scope for the target storage account and container
• endpoint selection for Azure public cloud, sovereign cloud, or custom endpoints such as Azurite

Xferity supports shared account key, connection string, and DefaultAzureCredential authentication.

---

Operational differences

SFTP

SFTP is commonly used for directory-style partner exchange: poll a remote directory, download matching files, or upload to a partner’s inbound directory.

Typical operational concerns:

• SSH host key verification (required in Xferity)
• authentication method (password or SSH key)
• remote file stability checks for files still being written
• polling schedule and retry behavior

FTPS

FTPS combines FTP semantics with TLS. Passive mode and data-channel behavior matter operationally, especially when firewalls or network address translation are involved.

Xferity supports explicit TLS mode (FTPES) and passive mode only.

S3-compatible storage

S3-compatible workflows are API-driven object operations, not session-based directory transfers.

They work well for:

• bucket-based partner exchange
• staging areas between internal systems
• object-store handoff patterns

Supports AWS S3, MinIO, and Cloudflare R2 via endpoint override.

AS2

AS2 is closer to B2B message delivery than to directory polling.

Features:

• inbound AS2 message handling (HTTP endpoint)
• outbound AS2 message sending
• synchronous and asynchronous MDN receipt handling
• certificate roles per partner
• AS2 message persistence in Postgres-backed deployments

WebDAV

WebDAV works well for:

• Nextcloud and ownCloud based partner exchange
• SharePoint or document-platform delivery over DAV endpoints
• environments where HTTPS is allowed but SFTP is not

Azure Blob Storage

Azure Blob workflows are object-storage operations, similar to S3, and work well for:

• cloud storage exchange with Azure-native partners
• staging data for Azure Functions, Data Factory, or Logic Apps
• archive or handoff workflows in Azure-centric environments

---

Choosing a protocol

Use this as a practical guide:

Protocol	Use when
SFTP	Partner requires SSH-based directory access
FTPS	Partner requires FTP-compatible protocol with TLS
S3-compatible	Exchange boundary is an object store (AWS, MinIO, R2)
AS2	Partner requires B2B messaging with signing, encryption, and MDNs
WebDAV	Partner or internal platform exposes a WebDAV endpoint over HTTP/HTTPS
Azure Blob	Exchange boundary is Azure Storage Blob containers or prefixes

---

Common runtime behavior across protocols

Regardless of protocol, Xferity applies:

• flow-level scheduling (schedule_cron or run-service)
• retry with exponential backoff
• SHA-256 content idempotency
• flow locking to prevent concurrent runs
• structured audit logging per file
• run history and status tracking
• notification channels for flow outcomes

What changes by protocol is the trust model and transport-specific configuration.

---

Related pages

• SFTP
• FTPS
• AS2
• S3-Compatible Storage
• WebDAV
• Azure Blob Storage
• Security
• Configuration
• Partner Reference