Tidal Wave Auto Spa Turns Hosted SFTP Into an Integration Layer for Workday, Snowflake, and Partners

Tidal Wave Auto Spa started as a single car wash in 1999. It now operates more than 260 company-owned express wash locations nationwide with 930 employees. Growth is the defining fact of the business.

A chain that large runs on enterprise software. Payroll and scheduling data flows through Workday. Employee training runs through the Docebo LMS. Operations and reporting data moves through Snowflake and Quickbase, alongside a Firebird database that predates the SaaS estate. These systems exchange CSVs carrying payroll, scheduling, training, admin, and customer-facing data.

And in enterprise software, many of those files move over SFTP. Workday exchanges its feeds through an SFTP server. Docebo ingests course and user files from an SFTP path. Outside partners expect encrypted file exchange. A company whose product is a clean car had, by virtue of the software it runs, acquired a standing requirement for file transfer infrastructure.

The Application Estate Needed an SFTP Endpoint Tidal Wave Didn't Have

The data these systems needed sat on Tidal Wave's own internal servers. The endpoints it had to reach were external SFTP servers operated by its software vendors and partners. Nothing in between provided the common exchange surface the estate needed.

Some transfers ran through an AWS S3 bucket instead. A bucket can hold files, but it did not provide the SFTP endpoint that Tidal Wave's counterparties expected without additional infrastructure. It could carry a leg of a transfer, but it could not serve as the exchange surface for the rest of the estate.

The obvious alternative was to stand up an SFTP server, and that was exactly what Tidal Wave did not want. An SFTP server is infrastructure. Someone has to harden it, patch it, manage its accounts and keys, and keep it available for every system that depends on it. Tidal Wave's IT team supports hundreds of car washes. Operating transfer infrastructure is not what that team exists to do, and as systems and partners multiplied, the one-off approach was headed in the wrong direction.

So the requirement was specific: an SFTP server that somebody else operates. It had to authenticate each integration with its own credentials and keys, keep each integration's files in its own folder, and connect outbound to the SFTP servers that Workday and other counterparties already ran. Tidal Wave selected Files.com to be that server.

With the Files.com site in production, what Tidal Wave bought as a hosted SFTP server became the transfer layer for its application estate.

A Service User, a Key Pair, and a Folder for Every Integration

What Tidal Wave built on Files.com was a single hosted site that its data crossed on the way between systems, with every integration isolated from every other.

Each integration received three things: a dedicated service user, a public/private key pair to authenticate it, and one folder it was scoped into. The Workday scheduling integration ran as its own service user, which could reach a single scheduling folder and nothing else on the site. Files landed in Files.com automatically, with a manual pulldown to Workday remaining in the workflow. Because each credential was confined to one folder, a rotated key or retired integration touched one flow, not the estate. Docebo used the same pattern to pull course and user files from its Files.com path into the LMS.

Partner exchange ran through the same site. Four outside partners, from service brands to suppliers, synced files with Tidal Wave using Files.com remote server sync, and Files.com applied PGP encryption and decryption automatically inside the transfer path. A file headed to a partner was encrypted with that partner's key as it moved. An encrypted file arriving from a partner was decrypted before it flowed onward. Nobody at Tidal Wave had to run an encryption script for each transfer, and the partner's encryption requirement was enforced by the folder rather than depending on a person remembering it.

Share links on the same platform covered ad hoc internal sharing, so one-off files could travel through the same controlled site as the recurring flows.

A Transfer Layer Without Transfer Infrastructure to Run

The S3 bucket that previously carried transfers on the Workday path came out of that loop. Files.com now serves as the transfer path among Workday, Snowflake, Quickbase, Docebo, and the Firebird database, giving payroll, scheduling, training, admin, and customer-facing files a central exchange point.

Four outside partners exchange files through the same site, with PGP encryption and decryption applied automatically. Most importantly, nobody at Tidal Wave operates, patches, or hardens a transfer server.

The SFTP Server That Turned Out to Be the Integration Layer

As Tidal Wave adds systems and partners, it can repeat a pattern that already exists: a service user, a key pair, and a scoped folder on the Files.com site. A new integration no longer requires another transfer arrangement worked out against internal servers or a bucket.

Tidal Wave never set out to buy an integration platform. It asked for an SFTP server somebody else would run, and for a business that lives on scheduled files moving between SaaS systems, that is what an integration platform is.