Integration · Inbound logistics

Knowing where inbound freight actually is

Inbound visibility is the problem every warehouse says it has already solved. Then you ask how they know a shipment is late, and the answer is that somebody checks.

4 carrier integrations
4 exception queues
10 min refresh cycle
Confidential client & operation

Built for the inbound receiving operation of a contract-logistics site handling returns and inter-facility transfers.

Inbound freight visibility: carriers in, exceptions outFour carrier lanes, three of them REST APIs and one a portal driven in a browser session, feed an integration engine that refreshes every ten minutes and writes status and revised arrival dates onto the open shipment record. Anything that is not routine is routed to one of four exception queues, carrier hold, wrong destination, past transit allowance and receipt mismatch, each with an owner.CARRIERS · EXTERNAL SYSTEMSCarrier lane AREST API · OAuth2Carrier lane BREST APICarrier lane CREST APICarrier lane DNo API: its portal is driven in abrowser session, boundedand retriedWHAT WE BUILTIntegration enginePolls every lane on a 10-minute cycleWrites status and the revised arrival datestraight onto the open shipment recordActs only while a shipment is still in anearly state: once a person has moved it,the machine leaves it alonePlaceholder and error text from a failedlookup is never read as a status, and a blankdestination is never read as a wrong one.Every field edit is logged with the old value,the new value, the user and the time.SYSTEM OF RECORDOpen shipment recordstatus · revised arrivalchange log on every fieldEXCEPTION QUEUES · OWNEDCarrier holdparked; released when the carrierresumesWrong destinationoutranks delivered: freight stillneeds workPast transit allowanceswept into a research queueReceipt mismatchescalated only after a dwell periodexceptions
Four carrier lanes feed one integration engine. Routine updates land on the open shipment record; anything that needs a person lands in a queue that has an owner.

How do you know an inbound shipment is late without checking?

You know an inbound shipment is late when its carrier status, revised arrival date or transit allowance says so, with nobody opening a carrier website. Four carrier integrations refresh every ten minutes and write status onto each open shipment; holds park in their own queue, wrong-city deliveries outrank 'delivered', and overdue freight lands in a research queue with an owner.

Open shipments arrived as a spreadsheet attached to a recurring email. Someone opened it, and for anything that looked late, opened the carrier's website and pasted in a tracking number.

Three failure modes fell out of that, and all three cost real money. Freight put on carrier hold looked identical to freight in normal transit, so nobody called until it was days late. Freight delivered to the wrong city was discovered when it didn't show up. And completed lines never fell off the report — the source system kept every line of an order visible while any line stayed open — so the list grew until people stopped trusting it.

What we built

Direct integrations with the major carriers, the core of any carrier tracking integration, refreshed on a cycle, writing status and revised arrival dates straight onto the open shipment record. One carrier had no API at all — that lane is handled by driving their portal in a real browser session, with retries and bounded workers, so one slow source cannot stall the rest of the pipeline.

The integration was the easy half. The half that changed the operation was giving every shipment an owner.

  • Carrier hold language detected and parked in its own queue, then released automatically when the carrier resumes
  • Delivery to an unexpected destination flagged for human action — outranking 'delivered', because wrong-city freight still needs work
  • Shipments past their transit allowance swept into a research queue
  • Receipt quantities reconciled against the warehouse system, with mismatches escalated only after a dwell period

Automation that never overwrites a person's decision

Automation that overwrites human judgment gets switched off within a week. Every automated update is scoped so it can only act on shipments still in an early state — once a person has advanced something, the machine leaves it alone.

The same care applies to bad data. A failed carrier lookup returns text, and text is easy to mistake for a status. Placeholder and error responses are explicitly excluded from ever being read as evidence that a hold was released, and a blank destination is never treated as a wrong destination. Every field edit is written to a change log with the old value, the new value, the user and the time.

The result

The dashboard answers the questions the spreadsheet couldn't: what is overdue, what is expected today, what is stuck and whose problem it is. With exception alerting, exceptions surface on their own instead of waiting to be found, and the report shrinks when work is done rather than growing forever. The same data can feed customer portals and visibility dashboards when a customer wants to see it too.

Carrier websites or carrier integrations

FailureSpreadsheet and carrier websitesIntegrated tracking
Freight on carrier holdLooked like normal transit until days lateParked in its own queue, released when the carrier resumes
Delivered to the wrong cityFound when it did not show upFlagged for a person ahead of 'delivered'
Completed linesNever fell off the reportThe report shrinks as work is done
Who acts on itWhoever opened the emailEvery shipment has an owner

Questions about this build

How do you track a carrier that has no API?

By driving the carrier's own portal in a real browser session, bounded and retried so a slow website can never stall the rest of the pipeline. Its results land on the same open shipment record as the API lanes, and, as on every lane, placeholder and error responses are never read as evidence that a hold was released.

Why does a wrong-city delivery outrank 'delivered'?

Because freight delivered to the wrong city still needs work. A delivery to an unexpected destination is flagged for a person to act on, ahead of the carrier's 'delivered' status, so it surfaces when the carrier reports the delivery rather than when the freight fails to show up. A blank destination is never treated as a wrong one, which keeps the flag from firing on missing data.

Built with

  • Python
  • Carrier REST APIs (OAuth2)
  • Selenium browser automation
  • SQL Server
  • HTML canvas charts (hand-rolled)
  • Scheduled workers

On the details we left out

Client, location, system names and volumes are withheld deliberately. We're happy to go deeper on architecture and approach on a call.

Services this draws on

Workload Optimization

Squeeze more throughput out of the hardware and licenses you already pay for.

See Workload Optimization →

System Integration

Connect aging systems to modern APIs, data platforms, and SaaS tools.

See System Integration →

Carrier Integration

Rate, tender, label, track, and audit across every carrier you ship with — parcel, LTL, and truckload.

See Carrier Integration →

More projects

Automation · Warehouse systems

Automating a system that has no API

The warehouse platform offered no write interface, so every transaction went in by hand. We automated the screens themselves — carefully enough to trust with live inventory.

Read the story →
Automation · Inventory transfers

The order builds itself from the attachment

Inventory transfer requests arrived as spreadsheets attached to email, in as many shapes as there were requesters, and were keyed in line by line. Now the attachment becomes a validated, reference-numbered order on its own.

Read the story →
Planning · Outbound fulfilment

Turning a flat order backlog into a plan the floor can pick

A daily backlog feed said what had been ordered — not what could be built, released or picked. We built the pipeline that turns it into a wave plan, a queued pick order, and a screen that says where each one got to.

Read the story →
Get in touch

How many carrier tabs are open on your dock?

List the carriers and how you hear about a hold today. Free assessment.

Prefer to talk?

Call 832-598-8234 or email msco@stoneagesoftware.com. Houston, Texas — serving Houston, The Woodlands, Conroe, Sugar Land, Katy, Pearland, and the Greater Houston metro.

What happens next

We read your message, an engineer replies with questions or a straight answer, and if a call would help, we book one. From the first reply on, you're talking to the people who'd do the work.

No obligation — we reply within one business day. This form sends your details to Stone Age Software LLC so we can respond to you. See our privacy policy for how we handle them. This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.