Protocol Services and Access
Files.com hosts FTP, FTPS, SFTP, and WebDAV services so applications, devices, and trading partners can exchange files using the protocols they support. Listening on the ports for those services and responding to their protocol commands are intended product capabilities.
Service Ports and Methods
| Service | Standard connection | Purpose |
|---|---|---|
| FTP and Explicit FTPS | TCP port 21 | FTP-compatible file transfers. Explicit FTPS negotiates TLS to encrypt the connection. |
| SFTP | TCP port 22 | File transfers over an encrypted SSH connection. |
| WebDAV | HTTPS on TCP port 443 | File and folder operations through WebDAV HTTP methods. |
Port 21 being open does not mean that unencrypted transfers are allowed. Files.com requires FTP encryption by default; plain FTP must be explicitly enabled. FTP connection profiles cover Implicit FTPS, alternate ports, and the separate data connections FTP uses. SFTP connection settings cover its alternate port.
WebDAV uses HTTP methods for listing folders and transferring or changing files. A server that recognizes and responds to those methods is providing WebDAV functionality. The user's authorization determines whether a requested operation is permitted.
Service Availability and Site Access
A reachable service and permission to use a site are separate. A connection must satisfy the site's protocol settings, the user's protocol privileges, the applicable authentication and network requirements, and the permissions for the requested operation. An open port does not grant access to files or site administration.
On shared service addresses, disabling FTP or SFTP for one site does not close the shared ports. Other customers still need those services. The site's disabled protocol remains unavailable to its users even though the shared service answers connections. Site protocol settings describe the behavior for shared and dedicated addresses.
API and Web Interface Availability
The Files.com API intentionally exposes functionality that the web interface does not. The API supports programmatic work and integrations, while the web interface presents controls for interactive use. A capability does not need a corresponding button or screen to be supported.
Authorization is enforced by the service for the operation and credential involved. The absence of a control in the web interface is not a permission restriction. Authentication Checks by Connection Method and API Key Permissions and Lifetime explain the credentials and access controls that apply.