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

Krystal has been selling its square slider hamburgers since 1932, which makes it the oldest hamburger chain in the South and one of the oldest in the United States. Today the company, a division of SPB Hospitality, operates and franchises roughly 300 quick-service restaurants across 13 states.

Feeding, staffing, and reconciling 300 restaurants takes a long tail of counterparties: food suppliers sending invoices, a payroll processor, point-of-sale and EDI partners moving operational data. Krystal'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 Windows Server 2016 file host. That remainder is where the problem lived.

Krystal'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. Francois Russ, Krystal's Sr. 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 Krystal 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 Krystal 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. Krystal 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. Krystal'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 Windows Server 2016 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.

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

“You pointed to the documentation earlier, and your documentation is so nice and easy to use.”

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, Krystal 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, Krystal 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.

That pattern is now the standing rule for how Krystal integrates:

“Whatever can't be done vendor to vendor, we will be doing it in Files.com.”

The File Layer an API-First Strategy Still Needs

Today Krystal'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.

Krystal 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. Krystal'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.