Connections & Networks

Files.com operates the hosted transfer services, so you can exchange files without building and maintaining your own transfer server. Start with our connection recommendations when choosing how the two businesses connect.

The network arrangement matters when a partner's server, client network, firewall, or callback requirement constrains how the exchange can work. A supplier that cannot accept incoming connections, for example, can still upload invoices to Files.com by opening the connection itself. Those uploads require no incoming path into the supplier's network.

For an external protocol connection, the first distinction is between the system accepting connections and the one initiating them. This determines where the endpoint must be reachable and who controls the transfer schedule. Either business can initiate, regardless of which one produces the files.

Push and Pull

When a supplier connects to your Files.com site and uploads invoices, the transfer is a push because the sender initiates it. If Files.com instead connects to the supplier's server to download those invoices, the transfer is a pull because the receiver initiates collection. The invoices arrive in Files.com in both cases, but the connection starts on a different side.

The same client connection can support both uploads and downloads. If your system connects to the supplier to collect invoices and upload response files, it pulls the invoices and pushes the responses. The connection still starts on your side in both cases.

In a partner agreement, inbound and outbound need a perspective and an object: whose side is it, and are you describing the connection or the file? “Files.com opens an SFTP connection to the supplier and downloads invoices” makes both directions clear.

The Hosting Decision

When a partner already operates a server and requires you to collect from it, your integration acts as the client. When partners send to a common endpoint you operate, each partner acts as a client. Both arrangements can support recurring unattended work.

The server operator controls accounts, folder permissions, availability, and server identity. The client operator controls when to connect and how to retry. With a pull, the receiving team can schedule collection but still depends on the sender to make complete input available. With a push, the sender can deliver as soon as its file is ready, while the receiver needs a way to recognize a delivery that never arrives.

Choose an arrangement that fits the parties' supported systems, network rules, and ownership. A business that permits outbound connections but cannot expose a server can act as the client. A partner's mandatory connection method can settle the choice before any product configuration begins.

A partner can connect to your Files.com site using its supported protocols, or Files.com can connect to the partner through a Remote Server. The Remote Server stores the connection details. A Sync or another workflow uses that connection to collect or deliver files at the required time.

NAT and Public Addresses

Network Address Translation (NAT) lets a system with a private network address communicate through a public address. When it opens an outbound connection, NAT creates a mapping for replies to reach it. The remote server generally sees the mapping's public address rather than the client's private one.

A new connection initiated in the opposite direction needs its own permitted path. The existence of an outbound connection does not make every port on the client reachable from the internet. This distinction matters for active-mode FTP, where the server opens a separate connection back to the client.

An organization's public web server address is not necessarily the source address used by its transfer jobs. Jobs running through a corporate gateway, a cloud NAT service, or several failover locations can have different source addresses. Obtain the addresses from the team operating the actual production connection.

Allowlisting in Both Directions

An allowlist permits specified traffic through a network or service access rule. A connection may need permission at both ends: the receiving side can restrict public source addresses, while the initiating side can restrict the destination hostnames, addresses, and ports its clients may reach. Different operators maintain these rules, so agreement on one does not settle the other.

For each connection, exchange the destination hostname and ports, all possible public source addresses or ranges, the environment, and the purpose of the connection. Include alternate servers and failover addresses used by the agreed arrangement. Record who will notify the other side before an address changes.

Network access remains separate from file access. An IP allowlist controls which networks can connect, while account credentials and folder permissions determine access to the files. A shared public address cannot identify an individual partner account.

For connections to Files.com, use the firewall hostname and port references. For connections Files.com initiates, use the Remote Server's connection routing to identify the source addresses the partner needs. A connection routed through an Agent originates from the Agent's network. The site's incoming destination addresses and a Remote Server's outgoing source addresses serve different purposes.

Additional Network Controls

For a Files.com partner exchange, we recommend an encrypted connection with appropriate authentication and permissions as the default. Apply the same proportional judgment to IP allowlists and dedicated VPNs as to additional encryption layers: use them to meet a concrete access, routing, or contractual requirement. We recommend against adding them to every B2B exchange simply to make its network arrangement more elaborate.

An IP allowlist restricts which networks can reach an endpoint, while a VPN can provide a private network path. Both add configuration and change coordination: a supplier's new public address can stop its deliveries until an allowlist is updated, and a VPN becomes another service the exchange depends on. For routine business files, those costs often outweigh the benefit. Use the additional control when the exchange has a specific need for that access restriction or route.

The Complete Network Path

Test from the system and network that will run the exchange. A transfer that works on your laptop can fail from a production scheduler using a different gateway. Test the file operation and any required callback as well as login; FTP data ports or a receipt's return path can still be blocked after authentication succeeds.

For a protocol using callbacks, such as an asynchronous AS2 receipt, document that return connection separately. For FTP and FTPS, include the data ports as well as the command port. Keep hostnames in connection profiles so DNS can perform its routing job, even when the firewall uses fixed address rules.