A Transportation Visibility Platform Connects the 90% of Carriers That Can't Use an API Through Files.com

A real-time transportation visibility platform lets large shippers and logistics providers see where every shipment is, across road and ocean, with predictive ETAs. Its network integrates with hundreds of thousands of carriers and more than a thousand TMS and telematics systems, and the company contractually guarantees its tracking rates and the speed at which it onboards carriers.

That last point is where this story starts. The company 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 the company can actually connect. Connecting every carrier, whatever its technical capability, is the load-bearing problem of the entire product.

Files.com gave the company 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 the company has that path for the carriers that can run one. Most road carriers cannot.

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 the company 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. The company 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, the company 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 the company's own name, reach out to unreliable partner servers so their failures stayed outside its pipeline, and be dependable enough to build the entire internal data pipeline against. The company 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 the company's Files.com site, which runs under the company'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 the company'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, dozens of 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 the company's pipeline.

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

One Surface Every Internal Interface Builds Against

When a file lands, Files.com webhooks feed the company'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.

Millions of Calls a Day Through One Repeatable Pattern

With Files.com as the exchange layer of the product, the company 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 the company connects reach the platform through Files.com. The file layer is the product's primary on-ramp, not its fallback.
• Roughly 80% of the carriers in one European country are connected to the platform, a level of coverage that depends on reaching the carriers no API strategy would ever touch.
• Files.com usage multiplied in a single year, with peak days running to millions of 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 new files every 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 the company a repeatable path for delivering the onboarding speed it guarantees. New partner interface accounts go live every month on that pattern. Every future internal interface targets the same layer the existing ones do.

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. The company built its product's front door where its carriers already are, and that front door is Files.com.