Every carrier tells you about their leg. We connect TMS, WMS, carriers and customs into one shipment record, so an exception surfaces while there is still time to do something about it.
SHShipment recordONE SHIPMENT · ALL LEGSIn transit
Booking & orderTMS
Warehouse handoffWMS
Departure & arrivalCarrier EDI
Customs clearanceBroker
One tracking model
Four systems ·one shipment
Where it breaks
A shipment is a different object in every system that touches it.
The TMS has a booking, the WMS has a handoff, the carrier has a tracking number and the broker has a declaration. Four records, one physical box, and no agreement on what to call it.
No identifier survives the whole journey
A leg changes carrier and the reference changes with it. Stitching the journey back together happens in a spreadsheet, by someone who knows which column to trust.
What we do
One canonical shipment with every party's reference attached to it, matched as the events arrive.
Exceptions arrive after they matter
Status is pulled on a schedule, so a missed connection surfaces hours later. By then the recovery options that existed at the terminal have gone, and the conversation is about credit rather than delivery.
What we do
Events stream in as they happen, with exception rules that fire the moment the event lands, without waiting for the next poll.
Your support desk is a tracking API
Customers and internal teams call because they cannot see for themselves. Every enquiry is someone re-reading a screen the caller could have read, if it existed.
What we do
One shipment API behind your portal and notifications, so the update reaches them before the call does.
How it works
Every party keeps their own reference. You get one shipment.
We normalise each event, match it to a shipment, check it against the plan and publish it to whoever is waiting on it.
Scroll the diagram sideways →
Built on published standards
EDI 214 and 204, EDIFACT IFTSTA and IFTMIN, carrier REST APIs and portal scrapes where there is nothing better. Adding the next carrier is a mapping against the same model.
Your cloud, or at the depot
The runtime sits on your cloud tenancy, in your data centre, or locally at sites with unreliable connectivity, so scanning and load events queue until the link returns.
Monitored after go-live
Carrier feed health, event lag and unmatched references land on one dashboard, so you spot a silent carrier before a customer reports it.
Products
Products that arrive already connected
MetricMonitor, Easy-Invois and DwaniAI read the same shipment model, so a consignment is the same consignment in all three.
Most deployed
Observability
MetricMonitor
Shipment throughput, SLA breaches, carrier feed health and integration pipeline status on one screen, with alerts on the thresholds your operation cares about.
Freight billing and e-invoicing across carriers, forwarders and brokers, with multi-country tax rules and reconciliation against the freight that moved.
Where-is-my-shipment questions answered over chat and voice from the same live record your operations team sees, with escalation when the answer is not good news.
A carrier is not live until the event counts reconcile.
Every new feed runs beside whatever you use today. Both receive, your team compares a full week of traffic against the carrier's own portal, and the old route stays open until you close it.
Parallel running is the default
It is included in every engagement. Every carrier onboards this way, on the first and on the fiftieth.
Your counts are the test
A feed is correct when your reconciliation says so, checked against the events you were already receiving.
A quiet feed still shows what it knew
When a feed goes quiet the shipment shows its last known state and the time it was known, rather than an empty screen nobody can interpret.
Recent work
Many carriers, one consignment, no one view
Anonymised at the client's request
A freight forwarder held each carrier in its own portal and each customer in its own spreadsheet. Answering where a consignment was meant opening several windows and trusting the person who had done it longest.
We defined one shipment model, matched every party's reference against it, and put exception rules on the events rather than on a nightly report. Carriers moved across in waves, each running in parallel until the counts agreed.
Through API-led middleware, usually webMethods or Apache Camel depending on what you already run. Each system maps into one canonical shipment and event model rather than into each other, so the number of platforms you operate stops driving the number of interfaces you maintain.
Get started
Book an assessment
Tell us which systems and carriers you are trying to join up. An integration architect reviews it and comes back within two working days.
A read of your current systems, carriers and feeds
Where visibility breaks and what it is costing you
A sequenced plan with effort ranges, written for your engineers