Lippert Bridges the Fixed-Filename Mismatch Between Salsify and Pinterest

Lippert, the operating business of LCI Industries, manufactures engineered components for the recreation and transportation markets: chassis, axles, slide-outs, awnings, and dozens of other product lines for the OEMs that build RVs, boats, trailers, and manufactured homes. The company operates manufacturing and distribution facilities worldwide.

Lippert is not only an OEM supplier. It sells into the aftermarket through retail dealers, wholesale distributors, and service centers, and directly to consumers online, under brands including Furrion, CURT, and Ranch Hand. A catalogue that broad, sold under that many names, makes product data an operating concern in its own right: the data has to stay current on every platform where buyers encounter Lippert products. And those platforms are third-party SaaS products. Lippert configures them. It does not control how they behave.

A Daily Feed Neither Platform Could Deliver

One of those flows runs from Salsify, which holds Lippert's product data, to Pinterest, which ingests that data as a file. The feed is simple to describe: once every 24 hours, a CSV of product data leaves Salsify, and Pinterest picks it up. Building it turned out to be impossible on the two platforms' own terms.

Pinterest pulls exactly one fixed filename. It cannot chase a new timestamped file each day. Salsify, on the other side, exports on a schedule but offers no way to edit a file in place or control its naming dynamically on the way out. Each platform demands a static file at a fixed name, and neither vendor bends. No combination of settings on either end completes the handoff.

That left Lippert with an integration gap it could not close from either side. Without something in the middle, the feed could not run at all. The fallbacks were the usual ones: a custom script that somebody writes, hosts, and owns forever, or a person moving a file by hand every day.

Even the obvious storage-side workaround failed inspection. Rotating timestamped files and sweeping old ones out with an expiration rule creates a race, where a scheduled deletion can land at the same moment as Salsify's next upload. Lippert ruled that design out before building it.

What the Layer in the Middle Had to Do

The fix could not be configured on either endpoint, so it had to live between them. Whatever sat in the middle had to accept Salsify's scheduled SFTP push exactly as Salsify sends it, hold the result at one fixed filename, keep that file stable and present for Pinterest's pull, and do it unattended every day, with no custom development on either side and no cleanup job that could collide with an upload.

Lippert selected Files.com to be that layer.

One Filename, Overwritten in Place

The design Lippert built is deliberately plain. Salsify pushes its product-data CSV over SFTP into a Files.com folder every 24 hours. Each upload lands under the same name and overwrites the previous day's file in place, so the path Pinterest watches never changes. Fifteen minutes after each upload, Pinterest pulls that fixed filename, and the day's handoff is done.

Because each day's file replaces the last rather than accumulating beside it, there is nothing to clean up: no expiration rule, no renaming step, no script. To Salsify, Files.com is an ordinary SFTP server it can push to on schedule. To Pinterest, it is a stable address where the same filename is always present and always current. The mismatch between the two platforms is absorbed entirely by the layer in the middle.

The Feed Runs Itself

With Files.com in the middle, Lippert turned an integration that could not be built directly into a daily, unattended exchange.

• Product data moves from Salsify to Pinterest every day with no one touching it, on a 24-hour cycle with a 15-minute handoff.
• Neither vendor changed anything, and Lippert wrote no code. There is no script to host, no parser to maintain, no cleanup job to watch.
• A workflow that had no direct path now runs as standard configuration on a supported platform instead of as custom infrastructure someone has to own.

The Fix for Two Rigid Endpoints Isn't on Either End

Files.com gave Lippert a neutral point that both platforms treat as an ordinary file server: rigid exactly where they demand rigidity, one static file under one fixed name, and invisible everywhere else. When two SaaS platforms both insist on terms the other can't meet, the fix isn't on either end. It's the layer between them.