A Hospitality and Entertainment Company Brings Vendor File Transfer In-House With One Files.com SFTP Endpoint

A hospitality and entertainment company operates a portfolio of attractions, hotels, and venues.

An operation that varied runs on a lot of systems: ticketing for its attractions and venues, gift cards sold across every property, and the hospitality and back-office applications behind all of it. Those systems trade data constantly with the outside vendors that run them, and that data moves as files, on schedules, machine to machine. When one vendor proposed a recurring fee to host a required daily exchange, the company chose instead to establish one company-owned endpoint that later became the shared connection point for gift card, ticketing, vendor, and internal integrations.

A Daily File Exchange, and a Monthly Fee to Run It

In 2019, the company was implementing a new application that had to trade files with its vendor every day, in both directions. The company had no SFTP service of its own to carry the exchange. The vendor had an answer ready: it would stand up and operate the transfer mechanism itself, for a recurring monthly fee.

The fee was the smaller problem. The pattern was the larger one. Accept it once, and every future integration that needed file exchange would arrive with the same proposition. The company's data exchange with outside parties would run on infrastructure it didn't own, priced per vendor, per month, indefinitely.

The alternative was to own the capability, and owning it traditionally meant operating it: standing up an SFTP server, securing it, patching it, and keeping it reachable around the clock for outside parties, including a partner whose firewall team needed a fixed address to allow-list. The company's IT organization runs a hospitality and entertainment business, not a file-transfer business. What it needed was an endpoint the company owned in every way that mattered — its own domain, its own credentials, a stable IP — speaking standard SFTP so any vendor's system could connect, without adding a server for the team to babysit.

The company selected Files.com to be that endpoint.

One SFTP Endpoint the Company Owns

Files.com became the fixed exchange point that every integration since has connected to: a hosted SFTP endpoint on the company's own branded domain, with a dedicated static IP. The static IP is load-bearing, because at least one integration depends on the counterparty allow-listing that exact address. The domain and the address are the company's. The servers, the patching, and the uptime are Files.com's.

The traffic is scheduled and machine to machine. The original application vendor drops and collects files daily. The platform behind the company's gift card program deposits reporting files nightly, which internal processes pull down and share onward with third parties. An associated organization sends a recurring data feed that lands on the endpoint and is ingested into the company's ticketing system. Internal applications use the same site for data drops between each other. The company's own scheduled jobs collect files off the endpoint into downstream systems, so every party, inside and out, writes to and reads from one place.

More Than Six Years in Production, and the Fee Was Never Paid

With the endpoint live, the company replaced a per-vendor hosted-transfer proposition with a single exchange point it owns.

• The application vendor's recurring monthly charge was never paid. The daily exchange went live on the company's own endpoint instead, and it still runs there.
• Every integration since has connected to the same endpoint — nightly gift card reporting, the ticketing feed, internal application-to-application drops — without new file-transfer infrastructure.
• The service has run continuously in production for years, with the original use case still running.

Owning the exchange point once turned every subsequent integration's file transfer from a recurring charge into a connection.