Files.com to Files.com

Files.com can connect directly to another Files.com site as a Remote Server. Two organizations that each run Files.com, or one organization running multiple Files.com sites, can move files natively instead of falling back to FTPS, SFTP, or WebDAV between the two sites.

A company that receives files from a partner over SFTP can use this native connection when the partner also runs Files.com. An organization that splits into separately billed Files.com sites can use it for migration and ongoing transfers. The native connection supports parallel file-part transfers; actual performance depends on the workload and endpoints.

You can browse a Files.com Remote Server, mount it as a folder with a Remote Server Mount, use it as a source or destination in a Sync, and copy, move, delete, download, and upload through it. A mount applies the mounting Site's supported Folder Settings alongside the other Site's own Folder Settings. Archive Only Mode applies from both Sites, and each Site's administrator lock bypass relaxes only its own locks. Access requires both the requester's permission on the mounting Site and the paired API key's permission on the other Site, as explained in Access Across Sites and Storage.

If the other organization has a Partner on your site and wants to use that Partner's folders with its own site's features, Connected Sites provides a connection approved by the Guest site's administrators without exchanging an API key. Connected Sites supports the Guest's own folder permissions and automated workflows, including Syncs. Choose this Remote Server integration when you need access defined by an API key, such as a connection scoped to a particular user or Workspace.

Parent and Child Sites

When one site is a Child Site of the other, or both are Child Sites of the same Parent Site, a Parent Site Administrator can use cross-site Automations and Syncs from the Parent Site without creating this Remote Server connection. Use the ordinary connector when separate sites need an explicitly credentialed connection.

Authentication

The connection authenticates to the other site with an API key generated on that site. Create a Remote Server with the Files.com type and enter the key.

The key must be a usable key from a different Files.com site. A key that is invalid, issued by the same site, expired, disabled, or deleted is rejected. For a user API key, the owning user must also remain enabled, unexpired, active, and unlocked.

A same-site key is rejected because this integration is for crossing between Files.com sites. Within one site, perform the file operation directly against its source and destination paths rather than routing it through a Remote Server and back into the same site.

Access Permissions

The connection can only access what the API key itself is allowed to access, following the key's own permissions and any path restriction on it. A key that belongs to a single user, a Workspace, or a specific path exposes only what that user, Workspace, or path allows.

Including files from this connection's mount in a Share Link requires both the creator's Share permission on the mounting Site and the paired API key's Share permission on the other Site. Sharing requires Share permission from every Site involved, on the folders being shared. A Partner User's key cannot supply Share permission because Partners cannot hold it.

Ask your counterparty for a key that allows exactly what the connection needs, and grant the same way when you are the one issuing the key. An unrestricted site-wide Full Access key grants administrative access to your site. A key restricted to one Workspace or path limits the exposure to the folders the connection actually uses.

Use a Files-Only key rather than a Full key for the connection. The connection only works with files and folders, which is everything a Files-Only key allows. A Full key also grants API access to users, permissions, and site settings that the connection never needs.

Connection Controls

This native connection uses the API key's permissions rather than signing in through the other site's client interfaces. On the site that issued the key, IP whitelists at the site, Partner, group, and user levels do not apply. Neither do its Allowed Countries and Disallowed Countries lists, the key owner's user or group protocol permissions, or the Global Acceleration Features setting that pins client connections to a region. The key's scope, path restrictions, and applicable folder permissions still apply.

Site Administrators on the site that issued the API key control native access under Security > Site Connections, in the Files.com Site Connections group. Allow other Files.com sites to connect using this site's API keys is enabled by default and applies to both user and sitewide keys in every Workspace.

Disabling the setting rejects new Files.com Remote Server connections and blocks subsequent access through existing connections, including mounted access and automated workflows. API keys and connection configuration are retained. Re-enabling the setting permits access again with usable keys; it does not renew expired keys, restore revoked keys, or re-enable disabled users.

Disabling does not cancel previously authorized transfer URLs. They follow the usual transfer URL expiration rules, and transfers already accepted can continue. Files already copied to another site or downloaded are not recalled.

This control does not change ordinary API access or your site's outbound connections using other sites' API keys. Those outbound connections depend on the issuing sites' settings. Partner-based Connected Sites uses a separate approval and permission model and is unaffected by this setting.

Disable native access if your organization cannot permit a connection outside the network, protocol, or regional connection controls above. If the exchange must use those controls, connect through a permitted protocol such as SFTP instead. Security Reference explains the controls and credential lifecycle together.

Connection Setup

On the site whose files will be accessed, create a dedicated account with access only to the folders the connecting site needs. For an external organization, use a Partner User when its scope fits; Partner permissions are shared across that Partner. Generate a Files-Only user API key and transfer it through a secure channel.

On the connecting site, create the Files.com Remote Server and enter the key. Give the connection a name that identifies the relationship and environment. Verify listing, reading, writing, and replacement behavior with representative files before enabling recurring transfers.

Maintain separate credentials for independently operated connections. To change access, update the remote account's folder permissions or the key's scope; to end the connection, revoke its key or disable its owning user. Changing IP, country, or protocol restrictions does not end this native access. A key from one site does not become a credential for that site's Parent or Child Sites.

Choose mounted access for work on the remote files themselves and a Sync for a replicated copy. Use an empty subfolder for the mount in most deployments; mounting the site root is supported but makes the remote the storage behind that site. A Sync whose local folder is within the mount follows the mounting Site's locks and Archive Only Mode as well as the other Site's rules. Syncs & Automations covers selection, replacement permissions, and failure behavior.

File Activity

On the site that issued the key, file activity appears in History Logs. When the connection uses a user API key, those actions are attributed to the key's owner. The mounting Site also records activity using its mount paths. Each Site's notifications, Event Channels, and Automations match its own records. Native actions do not create login events or API request entries on the key's Site, so use file history to review the connection's activity.

When the other Site has Archive Removed Files configured, eligible deletions and overwrites through the mount preserve the old file in that Site's archive folder. This includes access through a Partner Channel route. The mounting Site's own archive rule does not apply within the mount.