Shippeo Connects the 90% of Carriers That Can't Use an API Through Files.com

Shippeo is a real-time transportation visibility platform. Large shippers and logistics providers use it to see where every shipment is, across road and ocean, with predictive ETAs. It tracks more than 90 million shipments a year across 150 countries, its network integrates with over 228,000 carriers and 1,100 TMS and telematics systems, and it was named a Leader in the Gartner Magic Quadrant for Real-Time Transportation Visibility Platforms two years running. Unusually for the category, Shippeo contractually guarantees its tracking rates and the speed at which it onboards carriers.

That last point is where this story starts. Shippeo works with the carrier network its customers already have. It does not get to pick the carriers, and a customer's network includes small road-transport businesses alongside global container lines. Visibility only exists for the carriers Shippeo can actually connect. Connecting every carrier, whatever its technical capability, is the load-bearing problem of the entire product.

Files.com gave Shippeo a repeatable exchange layer for the long tail, while its engineers built every internal interface against one surface.

Most of the Carrier Network Cannot Consume an API

The clean way to connect a carrier is a direct API or TMS integration, and Shippeo has that path for the carriers that can run one. Most road carriers cannot.

“They could go by API if they were technically capable, but they aren't. So we put JSON files there, and they just pick them up. That's probably 80% to 90% of the users.”

For the overwhelming majority of the network, an API strategy connects nobody. Every carrier that cannot be reached is a blind spot in a customer's supply chain, a shipment the shipper cannot see. And because Shippeo guarantees onboarding speed by contract, a carrier that is slow or impossible to connect is not an edge case. It is a broken promise.

The constraint is that the counterparties cannot change. Shippeo cannot mandate API adoption across a network of small transport businesses, and it cannot improve the servers those businesses run. What the long tail has is file transfer: an SFTP client here, an FTP server there, sometimes nothing but email. The partner servers that do exist are unreliable and different in every detail. Integrating directly against each one would have made every carrier connection a bespoke, fragile project, repeated for every new carrier and nursed through every partner outage, and the pace of integration engineering would have capped the growth of the network itself.

As the network grew, Shippeo needed a repeatable pattern instead of hundreds of point-to-point connections. The layer had to speak every protocol the long tail already runs, including SFTP, FTP, FTPS, AS2, and inbound email. It had to keep each partner in its own separated space, operate under Shippeo's own name, reach out to unreliable partner servers so their failures stayed outside Shippeo's pipeline, and be dependable enough to build the entire internal data pipeline against. Shippeo built that layer on Files.com.

Every Partner Connects the Way It Already Can

Each carrier and shipper partner gets its own interface account and folder structure on Shippeo's Files.com site, which runs under Shippeo's own domain. From the partner's side, the connection is whatever they already operate. Carriers drop and collect JSON tracking, order, event, and proof-of-delivery files over SFTP, FTP, or FTPS using the client they already have. Trading partners that require EDI exchange transport-status messages over Files.com AS2 connections, with a signed receipt on every message. Customers that can only email send attachments to an address on Shippeo's own domain, and a Files.com inbox catches them and lands them in the same folder structure as everything else.

For partners that run their own SFTP servers, roughly 80 scheduled Files.com remote server syncs poll those servers and pull the files in. The polling and the retrying happen on Files.com's side, so a partner server that is down for an hour is absorbed by the sync schedule instead of breaking something inside Shippeo's pipeline.

The whole exchange also runs on IP addresses Shippeo owns, for inbound and outbound traffic, so when a downstream customer needs firewall rules, Shippeo coordinates the whitelisting under its own addresses.

One Surface Every Internal Interface Builds Against

When a file lands, Files.com webhooks feed Shippeo's real-time processing pipeline. Talend retrieves files over the REST API for order, event, and EDIFACT processing, while Files.com Automations push processed files to Google Cloud Storage and partner destinations.

An interface built once against Files.com works for every partner behind it, because every partner lands its files in the same place: the carrier that cannot use an API, the forwarder that mandates AS2, and the customer that only emails.

“This is business critical for us as most our ETL flows are using Files.com to get data.”

Ten Million Calls a Day Through One Repeatable Pattern

With Files.com as the exchange layer of the product, Shippeo replaced per-partner integration engineering with one pattern that every carrier connection follows. The results show at the scale of the network, not of any one carrier:

• 80 to 90% of the carriers Shippeo connects reach the platform through Files.com. The file layer is the product's primary on-ramp, not its fallback.
• Roughly 80% of carriers in France are connected to Shippeo, a level of coverage that depends on reaching the carriers no API strategy would ever touch.
• Files.com usage grew 300% in a single year, with peak days near 10 million calls, almost all of it SFTP and FTP connections. The growth was absorbed with no new per-carrier engineering.
• Single partner folders have grown to hold millions of files, and one ocean carrier's upload folder receives two to three new files a minute, all handled by the same automations that handle everything else.

The compounding result sits underneath those numbers. Onboarding a new carrier or shipper is now an account and a folder structure, giving Shippeo a repeatable path for delivering the onboarding speed it guarantees. Roughly ten new partner interface accounts go live every month on that pattern. Every future internal interface targets the same layer the existing ones do.

“We use this mechanism a lot because it's easier for us to build all our interfaces only to files.com and files.com is more reliable than our partners' sftp.”

The Front Door, Not the Fallback

Today, a carrier that has never called an API in its existence drops a JSON file into an SFTP folder, and its customer sees the shipment moving. What used to mean a bespoke connection to an unreliable partner server, built and maintained one carrier at a time, is now the standard path onto the product, and it is the path most of the network takes.

The lesson travels well beyond logistics. When most of your partners cannot consume an API, a governed file-exchange layer is not the legacy compromise sitting next to the real integration. It is the real integration. Shippeo built its product's front door where its carriers already are, and that front door is Files.com.