An On-Demand Delivery Company Replaced Manual Vendor File Delivery With a Files.com Hub Connecting Azure and Oracle Cloud ERP

An on-demand delivery company brings everyday goods directly to customers from its own fulfillment centers. The model is unusual: where competitors run marketplaces that connect users, drivers, and retailers, the company owns, stocks, and staffs its own fulfillment network end to end.

Owning the chain has a consequence for data. Its vendors and platform partners, along with the Oracle Cloud ERP that runs the corporate side, exchange files with the company directly. Across that network, every file needs a place to land.

With Files.com in production, the company replaced an exchange built on email exports and manual delivery with a standing pattern it repeats for every new counterparty: SFTP deliveries land directly in its Azure storage, where Oracle and other internal services process them continuously.

Exports by Email, Manual Deliveries by Engineers

When the company came to Files.com in 2021, its file exchange had not caught up with its business. Source systems could get data out one way: by email. And delivering vendor data to an external partner meant an engineer connecting to that partner's own SFTP server and pushing the files by hand, one counterparty at a time.

The cost was not any single transfer. It was that every exchange was a one-off. Onboarding a new vendor meant building another manual delivery routine. Connecting a new internal system meant another bespoke path. There was no governed place where a vendor, a partner, or one of the company's own services could drop a file and trust that the right downstream process would pick it up. Each new counterparty meant more engineering time spent doing courier work.

Vendors, Azure, and Oracle Did Not Share a Surface

The fix was not obvious, because the exchange spanned three worlds with no natural meeting point. External vendors spoke SFTP and FTP. The company's own estate ran on Azure, with Blob Storage holding the data and Azure Functions and Postgres behind it. And the corporate side ran on Oracle Cloud ERP, which consumed vendor files continuously through Oracle Integration Cloud.

Security narrowed the field further. The company treated Okta single sign-on as a hard gate: no production use until workforce access ran through it. Vendor connections had to authenticate with SSH keys. At least one vendor would accept inbound connections only from whitelisted IP addresses. And the data itself had to reside in the company's own Azure instance, not accumulate as a second copy somewhere else.

So the exchange point had to speak the protocols vendors already had, mount onto the Azure storage the company already ran, deliver outbound to vendor-controlled servers from fixed addresses, and put every account behind keys and single sign-on. The company selected Files.com to be that exchange point.

One Site All Three Sides Could Reach

Files.com became the surface all three worlds share: vendors reach it over the protocols they already use, Azure is the storage behind it, and Oracle polls it as the consumer.

On the inbound side, each vendor gets its own SFTP account, authenticated by SSH key and scoped to its own folder, on the company's own branded domain. Accounts are provisioned in bulk from the Files.com CLI, so standing up a new vendor is routine provisioning rather than an integration project.

Behind those folders, a Files.com Remote Server Mount links the site to the company's Azure Blob Storage. Files.com presents the folders and enforces who can reach them; the data resides in the company's Azure instance from the moment a vendor drops it. Nothing gets copied home afterward, because it is already home.

The company's Azure Function also reads and writes against the site over SFTP, while Oracle Integration Cloud polls it and picks up files as they are dropped, around the clock.

Outbound delivery runs through the platform too. For the vendor that requires IP whitelisting, an SFTP remote server on Files.com pushes files to the vendor's own endpoint using the site's dedicated IP addresses. The vendor whitelists those fixed addresses once, and no engineer ever logs in to deliver a file again.

A New Vendor Is a Keyed Account and a Folder

That standing pattern changed the work:

• Onboarding a vendor became provisioning: a keyed SFTP account and a scoped folder, instead of a new delivery routine built and run by an engineer.
• Vendor data lands directly in the company's own Azure storage the moment it is dropped, with no one carrying it downstream.
• Oracle Cloud ERP picks up files from the site 24/7, as they arrive, without a person in the loop.
• The same site carries the company's exchange with major delivery marketplaces, e-commerce platforms, and HR systems: the partner integrations its retail business depends on.

The pattern then outgrew its first problem. What began as a handful of human logins is now a site populated mostly by system accounts, services dropping, collecting, and routing files across multiple remote servers. Whole classes of internal system are built on it.

The Pattern the Company Now Builds On

Today, the file layer between the company's vendors, its Azure estate, and its Oracle ERP runs as one Files.com site instead of a set of one-off deliveries. A vendor drops a file. It already resides in the company's Azure. A service transforms it, and the ERP collects it before anyone has asked. The engineer who used to push files onto other companies' servers does not appear in that sentence, and that is the change. For a company that owns every step from vendor to doorstep, standardizing exchange on Files.com turned partner and system integration into something the company repeats, a keyed account and a folder at a time, instead of something it builds.