A Customer Communications Provider Standardizes FTP and SFTP Intake With Files.com—While Keeping Files on Its Production Servers

An outsourced customer communications provider designs, prints, and mails the transactional documents other companies bill with, producing billing statements and notices for utilities, municipalities, collections firms, and doctors’ offices.

The raw material of that business is other companies’ data. Every bill the provider mails begins as a data file generated by a client’s billing system, and it does not own, run, or standardize any of those systems. Getting each client’s file from the client’s server to the press is where this story starts.

Files.com gave the provider a layer in the middle: it could standardize intake across client-owned FTP and SFTP servers, add an API path, and still land every file on the internal servers that run production.

Every New Client Brought Another Server, Another Login, Another Directory Tree

Client billing data reached the company two ways, and both had a problem. Some clients uploaded files directly to the company’s own SFTP server. For the rest, intake meant going out to each client’s own FTP or SFTP server, and every one of those servers was different: its own directory structure to check, its own set of logins to hold, and for some clients a separate UAT environment that multiplied the connections again.

That sprawl collided with a deadline that never stops. The service is time-sensitive: files have to be pulled down and processed throughout the day, because each file is rows of billing data, and a late file is a late bill. Once-a-day batch collection was never going to be enough.

Then a client asked for something the infrastructure could not do at all. The client wanted to submit files programmatically, over an API, and the company’s SFTP estate had no API front end to offer. There was no way to say yes.

Two Estates the Provider Could Not Change

The obvious fixes were unavailable, because neither end of the exchange was the provider’s to redesign. The client side belongs to the clients: their servers, their directory conventions, their credentials, their test environments, all multiplying with every new relationship. And the company’s own side was not going to move either, on purpose. Statements and bills are produced and mailed from FTP and SFTP servers inside its own network, and the stated design goal was to keep it that way: whatever sat in front, files had to actually land on the provider’s servers, inside its own network.

So the fix had to be a layer in the middle, and the requirements wrote themselves. It had to speak FTP and SFTP to whatever each client runs, without asking any client to change anything. It had to present a real API to clients who wanted programmatic submission. It had to deliver every file onto the internal servers where production happens, run all day rather than once a day, and be able to carry healthcare billing data, with a HIPAA path in mind from the first design conversation. The provider selected Files.com to be that layer: the front end for client file exchange, with the files themselves landing on servers inside its own network.

An All-Day Pipeline From Client Servers to the Production Floor

Files.com was configured with remote server connections to client endpoints, including production and UAT environments, and to sync against them on a short interval matched to the intraday cadence of the billing data.

The handoff was built as paired Files.com sync automations. Throughout the day, they pulled new files from a client endpoint and delivered them through Files.com to the provider’s internal FTP server. Success-based removal prevented duplicate collection. A file made the whole trip, client server to Files.com to the provider’s own server, with no one touching it, and output files traveled back to clients over the same path in reverse.

The same platform also supplied the API foundation for the programmatic front door the provider had lacked. Its engineers built against the Files.com REST API and JavaScript SDK, with folder automations that forwarded uploaded files onward into the same pipeline. Multiple concurrent outbound connections let the arrangement span clients’ directories, logins, and test environments at once.

One Intake Layer, Running All Day

With the pipeline in production, the provider replaced fragmented, per-client collection with a single Files.com layer between client endpoints and its internal servers. Billing files now move to the production servers throughout the day, with no one in the middle.

Onboarding the next client means another connection and another sync pair on a pattern that already exists, not a new integration project. That pattern is already expanding: one of the provider’s larger clients has begun bringing its own downstream clients aboard, each routed through the same pipeline to the same internal server.

Neither Side Had to Change

Before Files.com, every new client made the provider’s intake surface bigger: one more server to reach, one more credential set to hold, one more directory convention to learn, and still no answer for the client who wanted an API. Now the intake surface is one layer. Clients keep their servers, their directories, and their logins exactly as they are. The provider’s production servers keep rendering and mailing statements exactly where they always have, inside its own network. Files.com carries everything between the two, all day, in both directions. A company that cannot dictate how its clients exchange files, and has no intention of moving production off its own infrastructure, consolidated the entire exchange anyway, by changing the middle instead of either end.