Connected Sites

Connected Sites lets two organizations with their own Files.com sites exchange files through a Partner relationship. The receiving organization can use the shared folders with its own site's file access, sharing, and automation features. The connection is approved on the site receiving access and does not require the organizations to exchange an API key.

The API refers to these connections as Partner Sites.

Host and Guest Sites

The Host is the site that shares a Partner's folders. The Guest is the site that receives access to those folders. Each organization continues to administer its own site.

For example, a travel company creates a Partner for a restaurant chain. The Partner's folders hold booking requests and confirmations. The travel company is the Host. When the restaurant chain connects its own Files.com site as the Guest, its Site Administrators can send requests and collect confirmations from that site, within the permissions the travel company granted to the Partner.

Approval establishes the Partner relationship on both sites. The Host appears as a Partner on the Guest site. Receiving access to the Host's folders does not give the Host access to the Guest's files.

The Our Role column in the Partners list describes your site's role for that Partner:

An ordinary Partner without a connected site has the Host role. Host capabilities do not require a connection to another site: the Partner can serve its own users directly. A Host & Guest Partner adds access to another site's shared folders to those local capabilities; it does not mean that a connection in the reverse direction has been approved.

A Guest Partner lets your administrators use the Host's shared folders without setting up local accounts or sharing files from your site. That Partner record cannot have a local root folder, Partner Users, local folder permissions, or Partner Channels, or host a connection to another site. These limits apply to the local Partner record; the Guest can still use Channels configured on the Host Partner and its own site's features with the connected folders.

To give a connected Guest Partner its own local root folder and Partner Users, a Site Administrator explicitly changes its role to Host & Guest and supplies a root folder. You can then configure permissions, users, and channels within that folder.

This local configuration does not expand access to the other site's folders. If both organizations need to share folders from their own sites, establish and approve a separate connection in the other direction, with its own Partner permissions.

Connection Options

Use Connected Sites when another organization already has a Partner on your site and wants to use the shared folders with its own Files.com site's features and workflows.

Use a Files.com to Files.com Remote Server when you need an API-key-based integration, such as access scoped to a particular user or Workspace. That connection follows the API key's permissions and is configured separately from Connected Sites.

Use Child Sites when your organization needs separate sites under a Parent Site's administration. A Connected Sites relationship does not make either organization a Parent or Child of the other.

Transfers between Files.com sites through Connected Sites are not billable Transfer Usage to either customer. Storage and transfers involving external systems follow the Usage rules.

Connection Requests and Approval

Begin with a Partner on the Host site, its root folder, and the folder permissions needed for the exchange. Review those permissions before connecting: every Site Administrator on the Guest site can use the connection, not only the person who approves it.

A Partner Admin can create, view, and cancel connection requests for their own Partner. A Host Site Administrator can manage requests for any Partner on the site. A Host Workspace Administrator can manage requests only for Partners in their own Workspace. Approval or rejection requires a Site Administrator on the Guest site.

By default, approval creates a Guest Partner named after the Host site, without a local root folder.

If your site already has a Host Partner representing that organization, you can explicitly select it during approval instead. It becomes Host & Guest and keeps its existing name, root folder, users, permissions, and other configuration. Use this option to keep the organization's existing local access and new connection under the same Partner.

The Host site's display name never selects an existing Partner automatically. If the name is already in use and no existing Host Partner is explicitly selected, approval reports a name conflict. Select an existing Partner only when it represents the organization whose connection you intend to approve.

1. On the Host site, start a Connected Sites request for the Partner and enter the Guest site's full Files.com site URL.
2. Continue to the Guest site and sign in as a Site Administrator. Review the Host site's name and approve or reject the request. Creating a request alone does not establish access.
3. After approval, use the Host site's shared folders from the Guest site as described below.

The approval step confirms that the Guest site's administrators agree to the connection. Rejecting a request does not create a connection. To connect after rejection or disconnection, create a new request and approve it on the Guest site.

File Access

The Guest can use the Host Partner's folders with its own site's file access and automated workflows, including folder permissions, its own Partners, Automations, and Syncs. This lets the Guest bring the shared files into the workflows it already runs. Features configured as Folder Settings, including Inboxes and Public Hosting, remain under the Host's folder administration.

The links, permissions, and workflows the Guest creates belong to the Guest site and follow the Guest's settings. The Host cannot view or control that configuration.

Operations on the shared originals still follow the Host's permissions and Folder Settings. Archive Only Mode on either Site protects the files, and each Site's administrator lock bypass relaxes only its own locks. Access Across Sites and Storage compares the controls on each side.

A Guest cannot include Host files under _/Sites/<host-site-id> in a Share Link because the Host Partner cannot hold Share permission. Creating such a link or changing a link's paths or permissions to include Host files fails with the same permission error as sharing a folder without Share permission, even for a Guest Site Administrator.

The Guest's Share Links to its own files follow the Guest's sharing settings; the Host's sharing settings do not apply.

On the Guest site, Site Administrators access the Host through the underscore folder at _/Sites/<host-site-id>. The folder appears alongside any Child Sites, but it opens the Host Partner's root folder, not the root of the entire Host site.

Approval gives every Guest Site Administrator access to the connection. Other Guest users and Workspace Administrators do not automatically receive that access, but the Guest can make the shared content available to them or to external recipients through its own permissions and features.

The Host Partner's permissions, including its Channels' inferred permissions, determine which folders can be listed and which files can be downloaded, uploaded, deleted, copied, or moved on the Host. They apply whether the operation comes from a Guest administrator, another permitted Guest user, or a workflow on the Guest site.

The Guest's permissions and features cannot grant file access beyond what the Host Partner allows. Listings, file counts, and folder sizes include only content that both the Guest requester and the Host Partner may see.

The Guest receives the Host Partner's inferred Partner Channel permissions. With directional subfolders, this is List Only on the Channel's base folder, Read Only on an enabled To Partner Folder, and Write Only plus List Only on an enabled From Partner Folder. A one-way Channel using its folder directly grants that direction's permissions on the Channel folder.

The Host's Route Paths resolve for the Guest's uploads, downloads, listings, and folder operations. Managed Folder restrictions also apply: the Guest cannot rename, move, or delete a Managed Folder, or place files and unconfigured folders at a level reserved for configured subfolders. This preserves the folder structure used by the Host's workflows.

Both sites' applicable folder structure locks also apply to operations through the connection. Each site's Ignore Locked Folders setting and administrator bypass relax only that site's own locks.

An Automation on the Guest can ignore Guest locks while the Host's locks continue to protect the folder structure used by its workflows. If the exchange requires creating, deleting, renaming, or moving folders protected by a Host lock, or copying folders into a tree protected by a Host lock, the Host must change the applicable Lock Subfolders configuration to permit those operations.

You can work with the shared files directly or copy and move files between the Guest site and the Host Partner's folders. File transfers can run in either direction when the relevant permissions allow them. For example, the Guest can upload a booking request to a folder where the Partner has Write permission and download a confirmation from a folder where the Partner has Read permission.

Moving a Host folder through Connected Sites requires the Host Partner's Full permission to apply recursively throughout the source folder. A Permission Fence in a subfolder stops permissions inherited from above it.

Full permission on the parent therefore does not permit moving the whole folder unless the Partner also has Full permission on each fenced folder with subfolders included. A nested fence needs its own recursive Full grant. Read access inside a fence permits downloads but is not enough to move the whole folder.

If any fence blocks the required permission, Files.com refuses the folder move before transferring files or creating the destination. The source folder and its contents remain on the Host, so the move cannot leave inaccessible contents behind after moving the rest. Ask the Host's administrator to review the Partner's grants within each fence, or move individual files that the Partner is permitted to move.

Shared folders can include Remote Server Mounts configured on the Host. The Host Partner's permissions still apply, along with the access available through the Host's Remote Server connection.

Folder Settings

The Host's Folder Settings govern the shared files, including filename restrictions, GPG processing, Auto Unzip, Malware Scanning, retention, and preview watermarks. They continue to apply to operations through the Guest's connection, including arrivals into Remote Server Mounts on the Host. This keeps the Host's processing rules in effect whichever organization submits or retrieves the files.

A Host Archive Removed Files rule preserves eligible deletions and overwrites in the Host's archive folder, using the file's path relative to the folder with that rule. The Host's watermark applies to previews through the Guest while its configuration remains private to the Host.

The Host's administrators configure these settings directly on the Host site. The Guest cannot view or configure them on or within _/Sites/<host-site-id>, including the Metadata Category assigned by a setting. Guest file access, even for a Guest Site Administrator, does not include administration of the Host's folder configuration. Copies of folders with their Folder Settings into this path are refused before copying starts.

The Guest's file-processing and retention settings do not carry into the Host's folders.

A recursive Webhook, Slack, Microsoft Teams, Amazon SNS, or Google Cloud Pub/Sub Folder Setting on the Guest's root can still respond to matching activity through the connection. It uses the Guest's History path; it does not change the Host's files. The folder structure locks checked on each site's paths remain separate from file processing.

If the Guest needs its own processing or retention rules for received content, it can copy that content into its own ordinary folders and configure rules there. Those copies are then stored and administered by the Guest. Scope & Inheritance compares site connections with Remote Server Mounts and Partner Channel routes.

Syncs Through a Connection

A Sync on the Guest can use _/Sites/<host-site-id> or a folder beneath it as its source or destination. The Host Partner's permissions govern every file read, written, or deleted there. Collecting files requires the Partner's Read permission; delivering them requires its Write permission. A Sync configured to delete source files also needs permission to delete them.

The Host's Folder Settings apply to those transfers in the same way as other operations through the connection. Each file the Sync reads is recorded as a download, and each file it writes is recorded as an upload by the Sync's user.

Both sites record the actions using their own paths. The Sync's run logs remain on the Guest site, where the Sync is configured.

History and File Events

File and folder actions on the Host's files through the connection are recorded in both sites' History Logs. This includes uploads, downloads, copies, moves, renames, deletes, and folder creation, whether the action comes from a Guest Site Administrator, another permitted Guest user, or a workflow on the Guest site. Both organizations can review what happens to the files they exchange.

The Guest's History records the action at the _/Sites/<host-site-id>/... path. The Host's History records it at the Host's own file or folder path. Use the path as it appears on the site whose History you are filtering.

Each site's notifications, webhooks, and Automations respond to that site's record when their scope, triggers, and conditions match. Guest notification Folder Settings follow the root-folder rule above.

For example, a Host Automation watching for uploads into a Partner folder runs when the Guest uploads there. The same action can trigger responses on both sites. Configure each response on the site responsible for that part of the exchange.

Parent Site operations on Child Site files through the underscore folder are also recorded in both sites. Activity performed directly within a Child Site is recorded there only.

Permissions and Disconnection

The Host controls continuing access through the Partner's root folder and permissions. Those permissions are checked when each file operation happens, including operations through features configured on the Guest site. Removing a permission ends the corresponding access through all of those features.

For example, removing Read permission prevents the Guest's users and workflows from obtaining new download access to the Host's files. Previously issued transfer URLs and transfers already in progress follow the usual transfer URL expiration rules.

A Site Administrator on either site can unlink the connection. Unlinking ends access to the Host through that connection, including through the Guest's links, permissions, and workflows, and preserves the Host Partner.

Files already copied into the Guest's own folders remain there and remain under the Guest's control, just as downloaded files do. Changing permissions or unlinking does not recall those copies or delete files stored on either site.

When the final connection through which a Partner receives access is removed, the outcome on the Guest site depends on the Partner's role. A Guest Partner is deleted because it has no local root folder, users, or sharing configuration to retain.

A Host & Guest Partner returns to Host and keeps its root folder, users, permissions, and other configuration. If another incoming connection remains, the Partner keeps its role.

Unlinking leaves any separate access through Partner User accounts in place on either site. Review those accounts as part of offboarding when the organization should no longer have access.

Deleting a Partner also removes its site connections and deletes its Partner Users. Use that broader action when ending the Partner relationship itself.

API Integration

For an API integration, see Partner Site Requests for creating and approving a connection, Partner Sites for unlinking it, and Partners for relationship roles. The same approval and permission rules apply.

Approval accepts the request's pairing_key and an optional partner_id identifying an existing local Partner with the host role. Omitting partner_id creates a guest Partner with root_folder: null; providing it changes the selected Partner to host_and_guest. To promote a connected Guest Partner later, update the Partner with partnership_role: "host_and_guest" and a root_folder in the same request.