A Pharmaceutical Wholesaler Automates FTPS Supplier Stock Without Bending Its SFTP-Only Policy
A national pharmaceutical wholesaler handles a large share of its country's pharmaceutical wholesale market, fulfilling tens of thousands of deliveries a week to thousands of pharmacies.
To simplify how pharmacies buy, the wholesaler built its own ordering platform: one channel through which a pharmacy orders and replenishes against the wholesaler's warehouse stock and the stock of external suppliers. The platform matches each order to the best available supplier option, keyed by medicinal product ID, and triggers replenishment as pharmacies dispense. That matching is only as good as the stock data underneath it, so the design called for supplier inventory to refresh every 10 to 15 minutes. Without automated ingress, those stock files had to be uploaded by hand, leaving the feed to run at whatever pace a person could manage.
An SFTP Mandate Meets a Supplier Feed That Runs on FTPS
The wholesaler built its new ordering platform internally, on Azure. As the platform was in penetration testing, with acceptance testing and a soft launch scheduled, two facts collided.
The first was internal. The wholesaler's head of IT security had made SFTP the only permitted file transfer protocol across the estate. FTP and FTPS were out, everywhere.
The second was external. Suppliers pushed their stock files over FTP and FTPS, and at least one supplier's system delivered over FTPS only.
The wholesaler controlled only its own side. The policy was not going to bend for one supplier, and the supplier's system delivered over FTPS. The premise of the platform—pharmacies ordering against external suppliers' live stock alongside the wholesaler's own—was blocked at the ingress layer.
What the Bridge Had to Do
Redesigning the platform around one supplier's protocol was not on the table either. The wholesaler's ingress architecture was deliberate: each supplier would get its own isolated endpoint, stood up by script, with credentials generated, stored in Azure Key Vault, and then distributed to the supplier. Suppliers could not see each other's data. That was a hard requirement, not a preference.
The fix had to accept FTPS from the supplier at the perimeter, speak only SFTP toward the wholesaler's environment, keep every supplier separated behind its own credentials, and change nothing about the scripted, per-supplier architecture inside.
The wholesaler selected Files.com to be that bridge.
A Protocol Bridge in Front of an Unchanged Azure Estate
Files.com became the perimeter layer that accepted the supplier's protocol and presented only SFTP inward.
On the supplier side, each external supplier connected to Files.com with its own credential set and saw only its own space. The supplier whose feed runs on FTPS connected over FTPS, exactly as it always had. From the supplier's point of view, nothing about the exchange changed.
On the wholesaler's side, Files.com used Outbound Connections to deliver each file over SFTP into that supplier's scripted Azure endpoint. From there, the flow remained untouched: event-driven handlers on AKS normalized each supplier's XML and CSV files into the platform's canonical stock model.
Nothing behind the bridge changed. The security policy saw only SFTP. The supplier saw only FTPS. Files.com was the one component that spoke both.
Live Supplier Stock, With No Policy Exception
With the bridge in production, the wholesaler replaced manual stock uploads with the automated ingress the platform was designed around.
- The FTPS supplier is onboarded. The supplier changed nothing, and the SFTP-only policy holds across the estate with no exception granted.
- Supplier stock flows on the designed 10-to-15-minute refresh cadence instead of arriving whenever someone can upload it, so the platform matches pharmacy orders against current inventory. At the wholesaler's scale—tens of thousands of deliveries a week to thousands of pharmacies—that freshness is a business requirement, not a background technical detail.
- Every supplier remains isolated behind its own endpoint and its own credentials. No supplier can see another's data.
- Onboarding the next supplier no longer depends on its transfer protocol. The wholesaler's scripts stand up the endpoint, Files.com absorbs the protocol at the edge, and the pattern repeats for every supplier that follows.
One Standard Inside, Any Protocol Outside
Before the bridge, a security standard and a supplier's protocol were being reconciled by hand, one uploaded file at a time. Now the supplier pushes its stock file the way it always has, Files.com carries it across the protocol boundary, and minutes later a pharmacist orders against inventory that reflects it.
Related Customer Stories
A Pharmaceutical Company Verifies and Forwards Terabytes of GxP Acquisition Data With Files.com
A repeatable SFTP staging and verification workflow receives each counterparty’s data, reconciles it against the manifest by MD5 hash, and forwards it to Box and Veeva Vault on the deal’s deadline.
Read The Story
A Life-Sciences Supplier Retired Its Self-Hosted FTP Servers With Files.com at MuleSoft’s Transfer Edge
A UK-locked landing zone now handles machine traffic from FTP-only counterparties while MuleSoft continues to orchestrate the integrations behind it.
Read The Story
A Digital Health Company Configures Dozens of Health Plan SFTP Connections in Files.com, Not Custom Code
Files.com Remote Servers and automations now move regulated clinical reports from AWS to payer-owned endpoints while operations staff handle routine delivery.
Read The Story
Get The File Orchestration Platform Today
4,000+ organizations trust Files.com for mission-critical file operations. Start your free trial now and build your first flow in 60 seconds.
No credit card required • 7-day free trial • Live in minutes