File Transfer Protocols
A trading partner may ask you to collect files from its SFTP server, send an AS2 message, or provide an endpoint for its software to connect to. Files.com supports these arrangements, so an existing requirement can settle the connection choice. When the choice is yours, we recommend Files.com's native connections and tools because they reduce the protocol-specific work you need to coordinate.
Our Connection Recommendations
A protocol defines how two systems communicate, authenticate, and perform file operations. Before choosing one, consider whether the exchange needs a separately configured protocol connection at all:
- When both businesses use Files.com, prefer Connected Sites. Each business can use its own workflows with the shared folders, and Files.com handles the connection and service identities. If you are proposing the arrangement, encourage the other business to use Files.com too.
- When a partner's application or script can choose how it connects to Files.com, prefer an official SDK, CLI App, or application connector. Choose the tool for the environment running the job; it supplies native request handling and transfer behavior.
- When an existing partner system requires a standard protocol, use the method it accepts. Files.com can receive the partner's connection or connect to its server through an appropriate Remote Server. Compatibility with the agreed exchange comes first.
When both businesses can choose among standard protocols, Files.com's order of preference is S3, SFTP, FTPS, WebDAV, then AS2. This order balances setup and ongoing work with the methods a traditional MFT counterparty is likely to accept. The choice still needs to fit the partner's supported methods and the exchange's message, receipt, and access requirements.
| Preference | Protocol | Files.com's Recommendation |
|---|---|---|
| 1 | S3 API | Our first choice among standard protocols when both sides support it. It uses HTTPS and an established object-storage interface. Traditional MFT counterparties rarely offer S3, so it is often unavailable despite being our preferred option. |
| 2 | SFTP | Usually the practical starting point with a traditional MFT counterparty. Its single SSH connection keeps the network arrangement simpler than FTP's separate command and data connections. |
| 3 | FTPS | Fits FTP-based partner systems while protecting the connection with TLS. Agree on explicit or implicit mode and the data-connection arrangement. |
| 4 | WebDAV over HTTPS | Fits a partner application built around HTTP-based file access. Prefer it when that application's existing interface calls for it. |
| 5 | AS2 | We recommend against it for new exchanges: its setup effort and ongoing certificate and message coordination are disproportionate to the benefits for most routine business files. See our AS2 recommendation. |
A partner requirement for AS2 takes precedence over this preference order. Use AS2 and agree on the message and receipt profile its system requires.
Transfer Speed as a Priority
The order above favors ease of operation; throughput can lead to a different choice. When you control the client, start with native Files.com tools, which offer transfer optimizations such as parallel requests and file chunking. Capabilities vary by tool, as explained in the integration method guide.
Among standard protocols, evaluate S3 first when it is available and the client can use parallel transfers or multipart uploads. These let a large transfer keep moving while individual requests wait for responses, provided the S3 service and client support the operations involved.
Between FTPS and SFTP, Files.com recommends FTPS when speed is the priority, especially for large files. That reverses their positions in the general B2B preference order. SFTP's request size and number of outstanding requests can constrain throughput over distance; an appropriately configured client can improve it.
WebDAV's additional file-operation round trips can be costly for many small files. AS2 message packaging, signing, encryption, compression, and receipt handling all contribute to completion time according to the chosen profile. Measure that complete exchange, including the required receipt, to assess whether it meets the delivery deadline.
Because the client, storage, route, file sizes, and concurrency all affect throughput, compare the available methods with a representative workload. The transfer-speed measurement method helps you assess whether a choice meets the business deadline.
Protocol Identities and Network Paths
Similar protocol names can hide substantial differences. SFTP is the SSH File Transfer Protocol and uses SSH (Secure Shell) for its protected connection, while FTPS adds Transport Layer Security (TLS) to FTP (File Transfer Protocol). An HTTPS API and AS2 both can use HTTP protected by TLS, but offer different operations and acknowledgments.
The ports below are conventional defaults. A partner can use another port; confirm the actual endpoint rather than inferring it from the protocol name.
| Method | Suitable work | Identity and authentication | Network implications |
|---|---|---|---|
| SFTP | Scheduled file pickup and delivery, directory operations, existing SSH-based integrations | SSH host key identifies the server; the client authenticates with a supported password or SSH key method | Usually one client-initiated TCP connection to port 22 |
| FTPS | Integrations that require FTP with encrypted connections | TLS certificate identifies the server; account credentials authenticate the client | Command connection plus separate data connections; requires an agreed data-port policy |
| FTP | Existing systems limited to unencrypted FTP | Account credentials without transport confidentiality | Same separate command and data connections as FTPS; credentials and contents travel unencrypted |
| AS2 | Partner messages requiring agreed signing, encryption, and protocol receipts | HTTPS server certificate plus separately agreed AS2 message certificates and identities | HTTP(S) delivery; asynchronous receipts require a separate return connection |
| HTTPS API | Application integration requiring explicit file operations, metadata, or workflow control | TLS server certificate; an API key, token, or other method defined by the service | Usually client-initiated connections to port 443; file data may use additional storage hosts |
| S3 API | Tools designed around object storage and bucket/object operations | TLS server certificate and signed requests using access credentials | Usually HTTPS; endpoint, addressing style, and supported operations must match the service |
| SCP | Existing SSH copy jobs | SSH host key and account authentication | Usually the SSH port; the command's actual wire protocol depends on the client |
| WebDAV over HTTPS | HTTP-based file access, including clients that expose remote files as a drive | TLS server certificate and the service's account authentication | Usually HTTPS; gateways must permit the HTTP methods the client needs |
SFTP and FTPS do not provide an AS2-style signed receipt. A successful operation reports a transfer result; application acceptance requires the evidence agreed with the recipient. None of these methods determines whether the payload is CSV, EDI, an image, or a PGP-encrypted file.
Explicit and Implicit FTPS
Explicit FTPS starts with an FTP command connection and requests an upgrade to TLS before protected authentication and file operations. Port 21 is the conventional command port. A profile that requires explicit TLS must fail if the upgrade cannot occur, rather than continuing with an unencrypted login.
Implicit FTPS expects TLS immediately when the connection opens, conventionally on port 990. It comes from an earlier FTPS approach; explicit negotiation is standardized in RFC 4217. A partner requiring implicit mode still needs that mode configured. Its age does not mean the connection is unencrypted, and switching between implicit and explicit does not by itself change the TLS algorithms in use.
Both modes use FTP's separate data connections, so choosing when encryption starts leaves a separate decision about how those data connections open. Files.com recommends explicit FTPS with passive data connections unless the client requires another supported profile.
FTP Data Connections
FTP uses one connection for login and transfer commands and separate connections for folder listings and file contents. A client can therefore log in successfully but fail on its first listing or upload if the network permits the command connection and blocks the data connection.
In passive mode, the server supplies a data port and the client opens a connection to it. The server's network needs a defined reachable passive port range, and the client's network must permit connections to that range.
In active mode, the client supplies an address and port for the server to connect back to. This can be difficult behind NAT: the client may advertise an unreachable private address, and even the correct public address needs a mapping and network rule permitting the incoming connection. Passive mode avoids that return connection to the client.
Some firewalls inspect unencrypted FTP commands and temporarily permit the negotiated data connection. With FTPS, TLS hides those commands from ordinary inspection. The network therefore needs explicit rules for the agreed passive range rather than relying on that inspection. A gateway terminating TLS is a different arrangement and must be assessed as part of the connection's trust and compatibility requirements.
Use the actual server's range, not a generic FTP example. Files.com FTP connection settings specify its supported profiles and ports.
API and Object-Storage Compatibility
HTTPS defines the protected connection, not a common file API. Two services using HTTPS can have entirely different operations, credentials, and file paths. For a Files.com integration, API Concepts explains requests and results; the API and SDK references define supported operations.
Similarly, “S3-compatible” describes an interface for the operations a service supports. Compatibility depends on the operations your tool uses, its endpoint configuration, and its authentication; it does not imply that the endpoint is an Amazon S3 bucket or supports every AWS feature. The Files.com S3-Compatible Endpoint documents its behavior.
SCP and WebDAV Clients
Modern OpenSSH clients use SFTP by default for the scp command, so an existing job can change its wire protocol after a client update even though the command stays the same. When diagnosing server support or file-operation differences, check which protocol the client is actually using. Files.com supports SCP through its SSH service.
WebDAV presents file operations over HTTP, often through a mounted-drive interface. That can fit interactive access while having different caching, file-size, or reconnect behavior from a batch transfer client. For unattended exchange, verify the intended client's completion and recovery behavior rather than treating drive visibility as delivery assurance. Use WebDAV over HTTPS to protect the connection.