Outbound 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.

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.

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.

Webhook Destinations and Content

For Notifications, Webhooks deliver information to configured HTTP endpoints. Review the selected events and payload: a webhook can send file details, and a configured payload can include file contents. Every primary and backup URL receives its configured requests; a backup URL is also a destination that must be approved to receive the data.

The same destination rules apply to Slack and Microsoft Teams notifications. Files.com validates every destination before saving a new notification or changes to its webhook settings. URLs must be well formed, use HTTP or HTTPS on an allowed port, and resolve to allowed public addresses. Destinations that resolve to private, loopback, or link-local addresses, or whose hostname cannot resolve, cannot be saved. The rules apply in every Workspace and through the web interface, API, CLI, and SDKs.

The Slack and Teams notification types determine the message format; they do not restrict the destination to the provider's domains. Approve the destination to receive the included file details, even when it passes URL validation.

This validation does not send a test HTTP request or require a successful receiver response. A Webhook delivery test checks a different question: whether the receiver accepts the request. Overriding a failed delivery test does not bypass destination validation. If validation cannot finish, the save fails and the previous configuration remains intact.

Event Channel targets use the same public-address and port requirements for Webhook, Slack Webhook, and Teams Webhook deliveries. Saving a target checks the URL's format and scheme without resolving its hostname or checking its destination address or port. Webhook targets accept HTTP or HTTPS; Slack and Teams targets require HTTPS. A saved target can therefore have a destination that Files.com will not deliver to. These rules apply in every Workspace and through the web interface, API, CLI, and SDKs.

For both Notifications and Event Channel targets, Files.com checks the destination every time it sends. It does not send to private, loopback, or link-local addresses, disallowed ports, or hostnames that cannot resolve. An Event Channel Delivery Attempt records Webhook URL is invalid when the destination fails these checks. A saved URL is not a promise of future delivery: DNS, receiver availability, credentials, and receiver behavior can change. Use HTTPS for confidential deliveries, maintain any receiver credentials, and monitor the delivery results for the workflow you depend on.

Receiver Verification

Configure a shared secret so the receiving system can verify a delivery before acting on it. Folder webhooks use their Verification token; Event Channel webhook targets use their signing secret. With a nonblank secret configured, X-Files-Signature-V2 carries an HMAC-SHA256 signature of the complete POST body, or the complete query string without the leading ? for a GET folder webhook. The receiver verifies the exact received bytes with the same secret.

Require a valid V2 signature on every delivery and reject a missing or invalid one. The older folder webhook signatures use MD5, and the folder webhook's X-Files-Signature checks only the file path. The Webhook Signatures reference and Event Channel signature guidance explain receiver verification and handling repeated deliveries separately.

The shared secret is the key behind the signature: anyone holding it can generate a matching signature. Keep a separate secret for each receiving integration. Files.com-generated folder webhook tokens use cryptographically secure random values, independent of other generated tokens; knowing one does not reveal another. Replacing a token requires updating the receiver's copy too.

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.