SqueezyDo: Real-Time Parts Tracking for 1,000+ Carriers

The Problem Nobody Talks About in Appliance Repair

A technician closes a job, orders a part, and then waits. The part is somewhere between a distributor, a regional carrier hub, and the customer's front door. The business owner has no idea where it is. The customer calls asking. The tech calls asking. Someone spends 20 minutes on hold with a carrier.

Multiply that by 30 open jobs. That's not an inconvenience. That's a broken operation.

Appliance repair businesses run on tight margins and fast job cycles. When a part sits untracked in transit, the job gets delayed, the customer gets frustrated, and the technician's schedule falls apart. The revenue from that job effectively pauses until the part arrives and someone notices.

SqueezyDo was built to close that gap. Real-time tracking across 1,000+ carriers, integrated directly into HouseCall Pro, the platform most appliance repair companies already use to manage their jobs.

Here's what it took to build it.

Designing for Carriers, Not Ideal Conditions

The first thing we learned: carrier APIs are not consistent. Not even close.

Some carriers offer webhooks with clean, structured payloads. Some offer polling endpoints that rate-limit aggressively. Some have documentation that hasn't been updated since 2019. A few smaller regional carriers had no API at all and required scraping their tracking pages, carefully and respectfully, within terms of service boundaries.

We built a carrier abstraction layer early in the project. Every carrier, regardless of how it communicates, gets normalized into a single internal tracking event schema. Status codes, timestamps, location strings, and delivery estimates all get translated into one format before anything else in the system touches them.

This sounds obvious in retrospect. It wasn't obvious at 2am when the sixth carrier's webhook was sending malformed JSON and breaking the event pipeline.

The abstraction layer meant that when a carrier changes their payload structure, only one file changes. The rest of the system doesn't feel it.

Making Webhooks Reliable at Scale

Webhooks fail. Servers go down, endpoints timeout, delivery attempts get lost. When you're processing tracking events across 1,000+ carriers for hundreds of active shipments, unreliable webhook delivery is a product-killing problem.

We built the ingestion layer around a queue-first architecture. Every incoming event, regardless of source, gets written to a persistent queue before any processing happens. If the processing service goes down, the events wait. Nothing gets dropped.

From there, events move through a processing pipeline that handles deduplication first. Carriers will send the same status update multiple times. Without deduplication, a part that says "Out for Delivery" five times creates noise that erodes user trust quickly. The system compares event hashes against a short-window cache before writing anything to the database.

For carriers that don't support webhooks, we built a polling service with adaptive intervals. Active shipments get polled more frequently. Shipments that haven't moved in 48 hours get polled less often. This kept API rate limits manageable without sacrificing freshness on the events that actually mattered.

The HouseCall Pro Integration

HouseCall Pro is where appliance repair businesses live. Scheduling, invoicing, customer communication, job history. If SqueezyDo couldn't connect to that workflow, it would be another tab the tech forgets to check.

The integration needed to do three things well. First, pull job and parts data from HouseCall Pro automatically so technicians weren't entering tracking numbers twice. Second, push status updates back into the job record so dispatchers could see part status without leaving their existing tool. Third, trigger notifications at the right moments, not every status change, just the ones that actually affect scheduling.

HouseCall Pro's API is solid but has rate limits that required careful management. We built a sync layer with exponential backoff on failures and a priority queue for outbound updates. When a part hits "Out for Delivery," that update to the job record gets prioritized over a routine status sync that can wait a few minutes.

The notification logic took the most iteration. Early versions sent too many alerts. Dispatchers started ignoring them within a week. We worked with early users to map exactly which transitions mattered: parts delayed more than 24 hours, parts arriving same day, and parts returned to sender. Everything else became a passive log entry, visible if you want it, silent if you don't.

What Broke and How We Fixed It

Three things failed harder than expected during the build.

Carrier normalization edge cases took longer than the initial estimates. Regional carriers in particular had inconsistent timestamp formatting that caused silent data corruption before we caught it with better input validation.

The HouseCall Pro webhook signature verification initially caused intermittent authentication failures under load. The fix was straightforward once diagnosed, but it took time to isolate because the failures weren't consistent.

Job-to-shipment matching logic had gaps when the same part appeared on multiple open jobs. The system initially linked to the wrong job in those cases. We rebuilt the matching with more explicit priority rules and added a manual override so dispatchers could correct edge cases without engineering support.

What to Take From This

If you're building a SaaS product that integrates with field service platforms or touches third-party logistics, the architecture decisions matter more than the features.

Normalize external data at the boundary. Build the queue before you build the processing. Tune notifications with real users before you ship, not after.

And expect the integrations to break. Plan for it, build recovery into the system from day one, and it won't stop you.