Remote Connections

Connecting Files.com to another system creates an authorized path for work and, often, for file contents. Files.com checks whether a user or workflow may request an operation; the destination checks the credentials used for that operation. Review both sides so the connected service's access matches the work you intend Files.com to perform.

Notifications and Event Channels use Webhooks & Event Delivery to send information to HTTP receivers. Their destination checks and receiver verification are separate from remote-storage access.

The connection must also reach the intended system. Connected System Identity explains how certificate checks, SFTP host-key pins, and receipt validation apply to directories, mail servers, remote storage, HTTP imports, and AS2 partners.

Remote Storage and Delegated Use

A Remote Server holds a connection configuration for a storage service or server. Mounts, syncs, and automations can use that connection. Their ability to read or write depends both on the applicable Files.com permissions and on the account or credentials configured at the remote destination.

This arrangement lets users work with connected storage without receiving its underlying secret. Not seeing a password does not mean a user has no access to the connected system: permissions can authorize the user or a workflow to use the connection on their behalf. Review which folders expose a mount and which administrators can configure work against the Remote Server.

Use an account on the destination whose permissions fit the integration. Files.com cannot grant permissions the destination account lacks, while an unnecessarily broad destination account gives the connection more authority than its intended work needs. Removing an individual Files.com user's folder access does not disable a shared Remote Server or stop independently configured workflows.

For FTP and FTPS, the remote server supplies the port for each passive data connection. Files.com accepts a permitted public IP address from the PASV reply, including one different from the control-connection host. A nonpublic or invalid IP address is replaced with the control-connection host while retaining the advertised port. This automatic rule supports servers behind NAT by reusing the host already selected for the control connection. Review the FTP connection requirements with the remote operator; data connections are not necessarily limited to the host used for login.

Integration-Centric Profiles

An Integration-Centric Profile delegates responsibility for connecting a user's own external accounts. Users can create connections of the types approved by the profile, maintain their settings and authentication, and remove them. This authority covers only their own Remote Servers. It does not grant control over other users' connections or permission to create Mounts, Syncs, or Automations.

Routing a connection through an Agent also requires permission to use that Agent. The connection then originates from the Agent host inside your environment, using that host's network access to reach the remote system. Owning a Remote Server connection does not grant access to that network position through another user's Agent.

Unassigning a profile leaves the user's Integration-Centric layout and existing connections in place. Ending this delegation therefore includes reviewing those connections and changing the layout, rather than just removing the profile assignment.

Credential Ownership and Rotation

The Remote Server Credential Manager lets administrators maintain credentials shared by multiple Remote Servers. Updating a shared credential updates the connections that use it, which is useful for coordinated rotation and also means that a mistaken change can interrupt several workflows. Identify those connections before replacing or removing a credential.

OAuth connections authorize each Remote Server separately and are not shared through the Credential Manager. Review the remote service's grants as well as the Files.com configuration when disconnecting an OAuth integration. Expiration or revocation at the remote service can stop access even while the connection remains configured in Files.com.

Assign responsibility for the connection to the team operating the workflow. A saved connection is a continuing configuration, not a login session belonging to the person who last edited it. An account offboarding process should therefore include any shared destination credentials the person controlled and the workflows that still need them.

Native Files.com Connections

A Files.com Remote Server uses an API key from another Files.com site to work with that site's files. The connecting site can expose the connection through mounts or use it in workflows. On the site that issued the key, this is native file access rather than a client signing in through its protocol interfaces.

The following controls on the site that issued the key do not apply to the native connection:

The key must remain valid, enabled, and unexpired. For a user API key, the owning user must remain enabled, unexpired, active, and unlocked. The user's applicable folder permissions, including inherited permissions, and the key's permission scope and path restrictions still govern file operations. A site-wide key uses its own site and Workspace scope instead of a user's folder access. Use a dedicated Files-Only user key with the folder access the workflow needs, rather than an unrestricted site-wide key.

Revoking or disabling the key ends its native access; disabling its owning user also ends access through a user key. Changing an IP whitelist, country list, or protocol permission does not. Site Administrators can disable use of the site's API keys by Files.com Remote Servers on other sites. Use that control when your organization cannot permit connections outside its network, protocol, or regional connection restrictions. An exchange through an ordinary protocol such as SFTP remains subject to that protocol's applicable connection controls.

On the site that issued the key, file actions appear in History Logs. A user key attributes them to its owner; a site-wide key has no owning user. The mounting Site also records activity at its mount path. Both Sites' Folder Settings and Archive Only Mode govern operations through the mount, and each Site's administrator lock bypass relaxes only its own locks; a Sync into that mount remains subject to the mounting Site's locks and Archive Only Mode. Access Across Sites and Storage explains how these controls combine. The native operations do not create login events or API request entries on the key's Site. Review file activity rather than using the absence of a login or API request as evidence that the connection was unused.

Work Inside Your Environment

The Files.com Agent receives authorized file operations and approved local work through its connection to Files.com. Its private key identifies the Agent installation to its site; a user session or API key from any site does not substitute for that identity. Protect the Agent configuration and private-key file like a password: an installation holding the same key can identify as that Agent and receive work routed through it.