The Long Tail of Freight Doesn't Come Through an API
Modern freight platforms get evaluated on integrations. How many shippers? How many TMS connections? How many EDI partners? It's a fair question, and we like our answer -- HOPTEK is integrated with 200 unique shipper sources, and that number grows every month.
But integrations alone don't tell the full story of where biddable freight actually lives.
A meaningful share of every asset-based carrier's addressable opportunity sits behind portals that were never built to be programmatically accessed. Mid-market shippers running their own portal. Brokers exposing loads through web interfaces only. Regional 3PLs with login-gated load boards. The freight is real. The volume is material. It just doesn't come through the front door.
Carriers have historically faced two bad options.
Option one: stand up your own scraping stack. Hire engineers, run proxies, maintain a browser farm, and accept that every Monday morning a vendor's portal redesign will break something. This is expensive and pulls engineering capacity away from the work that actually differentiates the carrier.
Option two: buy a point-solution scraping vendor. This is faster to deploy, but you've now bolted a separate system onto your stack -- one that produces a feed of loads disconnected from your network position, your contract book, and your cost-to-serve. The data arrives. The decisions still happen somewhere else.
Neither option treats scraped freight the way it should be treated: as just another stream of inbound opportunity, evaluated alongside every other stream against the same context.
That's what we built.
Load scraping inside Freight Finder is now generally available. It is fully managed -- no infrastructure for the carrier to provision or maintain. It surfaces loads from the portals that matter to your freight team, normalized into the same load object that an EDI tender would produce.
And critically, every scraped load lands in the same context graph that powers the rest of HOPTEK. When a load shows up -- from EDI, from API, from scraping, doesn't matter -- it is evaluated against your fleet position, your RFP commitments, your historical win rates, your cost-to-serve on the lane. The decision quality is the same. The source is invisible.
Hirschbach is the launch customer.
Hirschbach has migrated off their legacy scraping provider and is now running production on HOPTEK. The migration wasn't about replacing one feed with another. It was about consolidation -- removing a separate vendor relationship that produced data outside the system where decisions actually get made.
That's the pattern we expect to see repeated. Carriers running scraping as a point solution are paying for a feed. Carriers running scraping inside Freight Finder are extending the coverage of the platform where their freight team already works.
Where we go from here.
If you're an asset-based carrier paying a separate vendor for scraped freight that doesn't talk to the rest of your stack, we'd like to show you what consolidation looks like.
Reach out: media@hoptek.ai