A Subscription-Box Operator Uses Files.com Instead of EDI to Connect Dozens of Fulfillment Partners

A subscription-box operator runs two editorially curated boxes, one monthly and one quarterly. What makes the business unusual is that the merchandising authority is editorial rather than retail. Each box is assembled against an editorial verdict, so the assortment turns over completely every cycle and has to be sourced fresh each time. There is no fixed catalog, and there is no fixed supplier list.

That shape decides how fulfillment works. Orders come in through Shopify and are managed in a Linnworks and SkuVault order management system, but the shipping runs through an outside network of dropship vendors, merchants, and third-party logistics providers. Many of those vendors are small businesses with warehouses and packing lines and no IT department. The operations team running the boxes has no IT department of its own either.

So the connective tissue of the business is order files: orders out to whichever vendor ships that product, shipping confirmations and tracking numbers back so the customer can be told the box is on the way. When the Director of Operations for the subscription-box business set out to build that network, none of it existed.

Files.com became the file interchange between the order management system, the storefront, and the entire fulfillment network: a lightweight substitute for EDI that runs without engineers on either side.

Two Boxes, Two Returns Processes, and No Way to Split an Order

There was no file-based integration to any vendor. An order that needed products from more than one fulfiller could not be split and routed to both. And returns files ran through two separate processes, one for each box, so a vendor serving both boxes ran both. The team wanted one process for both boxes, simple enough for every vendor and fulfillment house in the network to run.

The cost landed on people. Every new fulfillment partner meant another bespoke handoff to design and teach, and every handoff was time spent on process instead of on shipping boxes.

What made it hard to fix was who sat on each end of the exchange. The vendors were small suppliers with no technical staff, and the operations director is not an engineer. That ruled out the conventional answers to multi-vendor order routing before the conversation started: EDI, a custom API build per partner, an SFTP server maintained by somebody's IT department. Whatever carried the order files had to be something a non-IT person on the operator's side could hand to a non-IT person at a vendor and have it work, and it had to work the same way for every partner, across both boxes.

An Exchange a Non-IT Operator Could Hand to a Non-IT Vendor

The need was already growing. Merchants across the network were picking up and returning files every month, with more partners coming, and the two boxes needed one exchange process instead of two. What that exchange had to do was clear before any product entered the picture: deliver a custom CSV of orders to each vendor and only that vendor, take a confirmation file back, feed the tracking numbers into the systems the storefront ran on, and let a new partner join without a developer on either side.

The team selected Files.com to be that exchange layer.

Order Files Out, Tracking Numbers Back

The outbound flow started in Linnworks. The operations director configured it to split orders into separate custom CSV files, one per fulfillment vendor, delivered over SFTP into each partner's folder on Files.com. Every vendor had its own account with access to its own folder and nothing else, so a partner picking up the day's order file saw only the orders it was responsible for shipping.

The return flow followed the same path in reverse. When a vendor shipped, it dropped a confirmation file with tracking numbers back into its folder. Linnworks polled Files.com, collected the confirmations, and filed the tracking into Shopify, and the customer was notified that the box was on the way.

Onboarding was built deliberately for repetition. A new vendor received an email invitation from Files.com, created its own account, and was assigned access to its folder. There was no software project and no meeting between engineers, because there were no engineers. The team repeated that pattern partner by partner over the following years.

Dozens of Partners on One Repeatable Pattern

With the Files.com exchange in production, the business replaced fragmented per-vendor handling with one repeatable pattern, and the pattern has held as the network grew.

• Dozens of partner relationships now run the order-and-tracking exchange, every one onboarded through the same self-service invitation, with no IT involvement on either side.
• The exchange moves thousands of orders on a typical day and absorbs much larger spikes at the start of each month.
• Returns files for the vendor network serving both boxes move through one process instead of two.
• Adding the next fulfillment partner is an invitation and a folder, not an integration project.

Simplicity here is not a soft benefit. In a fulfillment operation it is the error-control strategy, because a confusing process eventually becomes a mis-shipped box and an apology to a customer.

Growing the Network Stopped Being an Integration Problem

A multi-vendor dropship network does not require EDI or an IT team on either end. It requires a file exchange simple enough that a non-technical operator can hand it to a non-technical supplier and have it work, and on Files.com that exchange scaled to tens of thousands of orders without either side ever hiring an engineer to run it.