A Restaurant Chain Added a File Layer to Its API-First Strategy—and Cut Vendor Routing From 10 Steps to 3

A quick-service restaurant chain operates and franchises hundreds of restaurants across the US.

Feeding, staffing, and reconciling hundreds of restaurants takes a long tail of counterparties: food suppliers sending invoices, a payroll processor, point-of-sale and EDI partners moving operational data. The chain's integration strategy handles those connections API-first. Where a vendor exposes an API, the systems connect directly, vendor to vendor. But plenty of counterparties will never expose one. Their invoices, payroll files, and data feeds still have to move as files, and they have to land cleanly in internal systems that include a Microsoft Great Plains ERP and a file host. That remainder is where the problem lived.

The chain's API-first strategy therefore needed a deliberate second lane: a common file layer for every exchange the vendors and internal systems could not handle directly.

Ten Steps to Move One File

Without a common exchange layer, each of those exchanges ran as its own multi-hop routing chain. The chain's senior director of IT operations and infrastructure describes processes that took ten or more steps: files went one place for one task, somewhere else for the next, then came back to be picked up again. Every new vendor meant another bespoke path into internal systems, built and maintained on its own. Onboarding was not a repeatable configuration task; it was another integration build.

The chains persisted because the company controlled neither end of them. The vendors were heterogeneous: some connected over SFTP, some over FTP, and one partner could only send files by email. The internal consumers were legacy: Great Plains consumed vendor invoices from files, and EDI data was processed out of folders on the Windows server. Those systems collect files from known locations. They were never going to reach out to an arbitrary vendor endpoint, and no vendor was going to change how it sends. With both ends fixed, every exchange got wired up the long way around.

What the company needed was a single point both sides could treat as their own. Vendors needed one place to deliver, reachable over whatever they already speak, with each vendor walled into its own folder. Internal systems needed one place to collect from, over protocols they already run. And the routing between arrival and pickup needed to happen inside that layer, not in scripts strung between systems. The chain made Files.com that exchange point.

A Scoped Account for Every Counterparty

On the vendor side, every counterparty gets its own SFTP or FTP account, scoped so that logging in lands the vendor directly inside its own working folder. The chain's Boomi integration platform reaches the payroll processor's folder over SFTP. Even the partner that can only email files is covered: files arriving by email are routed onto FTP automatically, so the flow downstream looks the same as every other vendor's.

On the internal side, nothing had to be modernized. Vendor invoices flow from Files.com into Great Plains over WebDAV. Scripted jobs using the Files.com CLI pull EDI files into their processing folders on the file host. Vendors deliver into Files.com the way they already know how, and internal systems collect from it over protocols they already have. Neither side needs to know anything about the other.

The chain's team designed and stood up each of these workflows itself, one workload at a time.

One Feed In, Two Processes Served

Routing moved into the platform too. One vendor's feed has to be consumed by two separate downstream processes. Rather than ask the vendor to send twice, the team built Files.com Automations that duplicate each inbound file into two destination folders for independent pickup. The vendor sends once, exactly as it always has, and adding a second consumer to a feed became a routing rule inside the platform instead of a request to the vendor.

From Ten Steps to Three

With Files.com as the standing exchange point, the chain replaced a bespoke build per counterparty with one repeatable pattern.

• Routing chains that took ten or more steps now run in roughly three. A file comes in, gets what it needs, and goes out. The shuttling between intermediate systems is gone.
• One inbound vendor feed serves two independent downstream processes, and the vendor never had to change anything on its end.
• Onboarding the next counterparty, whether it speaks SFTP, FTP, or only email, is a scoped account and a folder rather than another multi-step integration build.

The File Layer an API-First Strategy Still Needs

Today the chain's integration architecture has two lanes, and both are deliberate. Where a counterparty offers an API, systems connect directly. Everywhere else, the exchange runs through Files.com: the supplier that only speaks FTP, the partner that emails files, the payroll processor, the EDI feeds bound for a 2016-era Windows server.

The chain never expected file transfer to disappear. Even a deliberately API-first strategy leaves a remainder of counterparties that will never expose an API, and that remainder does not shrink on its own. The chain's answer was to stop treating each one as its own project and give them all a single destination. Vendor file exchange stopped being integration engineering and became configuration: when the next counterparty arrives without an API, the team doesn't design a ten-step path. It hands out a folder.