WMS, TMS and portal integration, with one record of every handoff.
Your WMS says the order was picked. Your TMS says the load is booked. The client's portal says it shipped yesterday. The client says it never arrived. Each system is right about its own step, and nobody owns the gaps between them. Most WMS and TMS integration for 3PLs is about moving data between systems. We build the record of every handoff for an order instead, with the proof behind each one.
Example workflow. Not client work.
All warehousing and 3PL problemsInbound receiving visibility
Why nobody can say which status is true
An order passes through several systems on its way out. The WMS (warehouse management system) records the pick and pack. The TMS (transportation management system) or a shipping tool books the carrier and prints the label. The client’s store or portal shows a status to the end customer. Each updates on its own trigger, and some of those triggers are not physical events: a portal often marks an order shipped the moment a label is created.
So statuses disagree, and nobody’s job is to notice. When a client asks where an order is, a coordinator opens three screens and a carrier website and pieces it together. The honest answer is often “we think it left”, because the one thing that proves it, a signed BOL (bill of lading) or a pickup scan, is on paper or in a driver’s app.
What we would build
- Input. The handoffs that matter to you, named with your team: for example picked, packed, staged at the door, loaded, picked up by the carrier and dispatched to the client. For each, which system records it and what evidence counts.
- Capture. Status changes are read from each system through its API or export, where it offers one. The physical handoffs the systems cannot see are captured on the floor: a scan when a pallet is staged, a photo of the signed BOL and the trailer seal when the carrier leaves.
- Check. Every handoff for an order is lined up in time, with who did it and the evidence. The record compares what each system claims with what was physically captured.
- Exception. When two sources disagree for longer than your rule allows, for example a portal showing dispatched with no pickup scan and no signed BOL, the order is flagged to the person who owns that handoff, with both sides shown.
- Record. Each order keeps one timeline your coordinators, and if you choose your clients, can open. When a client asks where an order is, the answer comes with the scan, the photo and the time.
How it fits beside what you run
- Nothing is replaced. Your WMS, TMS and client portals keep doing their jobs. The record reads from them and does not overwrite their statuses.
- Only what each system offers. Where a system has an API, the record reads it as statuses change. Where it only offers an export, the record reads the export and shows how current that data is. Where it offers neither, that handoff is captured on the floor instead. The timeline your coordinators open is one of the custom internal tools we build, not a dashboard bolted onto a product. Cargohold itself publishes a versioned REST API with signed webhooks, which is the kind of interface we look for in the systems we read from.
- On devices you already own. Floor scans and BOL photos run on your existing scanners, phones and tablets.
Where your team decides
You decide which handoffs are tracked, who owns each one and how long a disagreement may sit before it is flagged. When systems disagree, the record shows both sides; the person who owns that handoff decides which is right and fixes it in the system where it went wrong. What a client sees, and when, is your account team’s call.
Sample handoff record
Line up one fictional order's handoffs across three systems.
Interactive simulation · sample data
A fictional order, HG-9040, moving through a fictional WMS, a fictional TMS and a client portal. Pick what happened.
Choose what happens
Pick one above. Nothing here is live: no call is placed, no message is sent and nothing is saved.
Questions
Which systems can it read from?
Any system that offers an API or a data export. You might run a WMS such as ShipHero, Extensiv or a homegrown system, a TMS or a shipping tool, and a client’s store or portal. What we can read from each depends on that system’s API or export, and we check it before the fixed quote, not after.
Isn't this just another integration?
An integration moves data from one system to another. This keeps a record of what each system claimed and what physically happened, and flags the gap to a person. It does not change any system’s status by itself.
What does it do when two systems disagree?
It shows both sides and flags the order to the person who owns that handoff. It does not pick a winner and it does not overwrite a status, because the fix usually belongs in the system that went wrong. How long a disagreement may sit before it is flagged is your rule, set per handoff.
Do we have to replace anything?
No. The default is to sit beside what you run. We replace a system only where the system is spreadsheets, or something you want gone.
Who owns it?
You own the code and the repository. Every account and API key it uses belongs to you.
Where does an order's status stop being certain?
Tell us which systems an order passes through and where your team loses track of it. Someone from our team replies within one business day.