A Recruitment Marketing Technology Company Moved Its Clients Off In-House SFTP and Automated Per-Client Decryption With Files.com

A global recruitment marketing technology company runs recruitment marketing for hundreds of enterprise customers worldwide: personalized career sites, programmatic job advertising, candidate relationship management, and hiring events, delivered across operations in the Americas, Europe, and Asia.

Underneath all of it is a feed. A client's HR systems produce job-posting data as XML. The company ingests it, personalizes it, publishes it to the client-branded career site it hosts, and syndicates the postings onward to the major job boards. Hundreds of corporate career sites are kept current this way. So before the company can do any of the work it actually sells, hundreds of corporate clients have to be able to push files to it reliably, every day, and a growing share of those clients require their feeds encrypted.

Running a Transfer Service Was Never the Business

For years, the company answered that requirement by operating its own transfer service. It ran local SFTP and FTP implementations and handed out credentials on those servers as the way clients delivered feeds. When clients began demanding PGP-encrypted delivery, the company's engineers wrote and maintained custom scripts to decrypt each feed as it arrived, with each client's own keys. Every account was added and removed by hand, through an internal manual process.

The cost of that arrangement scaled with exactly the thing the company wanted to grow: its client count. Every new client meant another hand-provisioned account, and every encrypted client meant more key handling inside scripts somebody had to own. The company had outgrown its own estate. The team was spending its time operating servers and encryption plumbing that had nothing to do with publishing jobs.

An Endpoint Hundreds of Clients Depended On

The estate was hard to walk away from because it was not internal. It was a service hundreds of external companies were configured against, each with their own transfer tooling on their side and, for the encrypted feeds, their own keys. Moving the service off it meant moving those counterparties without interrupting the feeds that keep hundreds of career sites publishing.

So the replacement had specific work to do. It had to present the SFTP and FTPS endpoints clients already knew how to use. It had to keep each client's data in its own space and decrypt each client's feeds with that client's keys. It had to let the company's own systems create and remove accounts through an API instead of a person. And it had to run alongside the legacy servers while clients moved, because a hard cutover across hundreds of external companies was never realistic.

The company selected Files.com to carry that client-facing transfer layer.

Per-Client Folders, Automatic Decryption, and Provisioning by API

Files.com became the intake layer between the company's corporate clients and its publishing pipelines. Clients push their XML job feeds into Files.com over SFTP or FTPS, each into their own folder. When a feed arrives encrypted, Files.com decrypts it on landing using the GPG key pair configured on that folder. Keys are set per client, per folder, and the model stretches as far as a client needs: one client runs separate test and production keys against a single Files.com endpoint. The company's pipelines then pull the decrypted feeds and reprocess them into the career sites it hosts and out to the job boards.

That per-folder decryption is what retired the scripts. Encryption handling was the part of the old service the company had built entirely by hand, and once Files.com performed it automatically on arrival, the custom scripting had nothing left to do.

Provisioning moved to the Files.com REST API. Creating or removing a client account is now a step inside the company's own onboarding process rather than a task performed by hand on a server.

Dozens of Clients in Two Months

The migration off the legacy servers ran as a wave, not a cutover. In a two-month window, the company moved dozens of clients from its in-house SFTP server onto Files.com. The old server stayed online in parallel to avoid interrupting feeds and remains in place for a small number of clients, while every new client is onboarded directly to Files.com. The bulk of the client base has moved over.

Feeds for Hundreds of Career Sites, and No Scripts to Maintain

With Files.com carrying the client-facing service, the company replaced a self-operated server estate and its custom encryption scripting with a repeatable intake pattern:

• The decryption scripting is retired. Encrypted feeds decrypt automatically on arrival with each client's own key, and nobody at the company maintains PGP scripts.
• Account lifecycle is an API call. The company's internal onboarding process creates and removes client credentials itself, so provisioning no longer grows with the client roster.
• Job feeds for hundreds of corporate career sites now land on Files.com.
• New clients onboard straight to Files.com, and the company adds client accounts month after month without adding corresponding administrative work.

The compounding result is the one the company was after. Taking on the next client, including one that mandates encrypted delivery, is a folder with the client's key and a credential provisioned over the API. Growth in clients stopped meaning corresponding growth in transfer administration.

More Time for the Platform the Company Sells

With Files.com carrying the bulk of the client-facing service, the people who used to run servers spend their time on the platform the company actually sells.