The problem, before.
Indian sellers who ship at volume do not have a logistics problem — they have six of them, one per carrier. Delhivery, Shiprocket, BlueDart, DTDC, XpressBees: each with a different API, different label format, different tracking vocabulary and different failure modes. The operational cost of that variety lands in the seller’s day, not the carrier’s.
Before
Merchants logged into separate carrier dashboards to dispatch and track. Tracking numbers were copy-pasted into spreadsheets. When a parcel misrouted, the merchant called each carrier in turn. Onboarding a new courier meant weeks of integration work and re-training the ops team on a new vocabulary.
After
One platform. One internal contract. One tracking experience. Merchants dispatch and track across every carrier through the same surface. A new carrier is an adapter module — written and tested in hours, not weeks.
ShipSarthi was briefed to be that one interface. The system had to handle real volume without ceremony, and recover cleanly when upstream carriers misbehaved — which they do, daily.
“Uddit took the time to understand our fleet tracking processes before proposing any changes. That level of diligence is rare in technical consultants.”
The spine — high-level architecture.
The design is deliberately boring in its shape: a gateway, a core, a ledger, and a fan-out. Boring scales. The interesting behaviour lives at the edges — in the adapters and the webhook choreography.
Each carrier sits behind an adapter. Adapters normalise the wild variety of upstream APIs into a single internal contract: quote → book → label → track → cancel. The rest of the system doesn’t know which carrier it’s talking to.
Building a logistics or multi-vendor integration?
I've shipped the above as a single operator. If you're integrating couriers, payment gateways or any multi-vendor API surface into your product, a 30-minute call is usually enough to map the architecture for you.
State machine — the life of an order.
An order is a state machine, and the platform’s job is to never lose track of which state a shipment is in. Every transition is logged to an event ledger — append-only, queryable, replayable.
State transitions are driven from two sources: merchant actions (books, cancels) and carrier webhooks (picked, scanned, delivered, returned). The ledger is the source of truth. The database is a materialised view.
Webhook choreography.
The platform receives thousands of webhooks a day from multiple couriers. Webhooks are rude: they arrive out-of-order, duplicate themselves, sometimes lie. The router enforces three disciplines — idempotency, ordering by vendor timestamp, and quarantine for malformed payloads.
The queue is partitioned by AWB so events for the same shipment are processed strictly in order, even while thousands of unrelated shipments fan out in parallel. Duplicate deliveries collapse to a single apply via a processed-set in Redis.
Theory of strong design.
Strong systems aren’t the ones with the most components. They are the ones whose components agree on fewer, sharper contracts.
The design philosophy for ShipSarthi rested on three commitments: narrow contractsbetween internal services; wide adapters against the messy outside world; and an immutable history in the middle. A new carrier onboarding is a single adapter module, roughly 200 lines. A new merchant feature rarely touches more than one service.
When something goes wrong — a misrouted parcel, a phantom status update — you walk backwards through the ledger. The ledger is the system’s memory. Everything else is recomputable.
How it was built.
Build timeline
- Discovery & architectureWeek 1–2
Merchant workflow map, carrier API audit, state-machine design, adapter contract locked.
- Core + first carrierWeek 3–5
Order service, webhook router, event ledger, Delhivery adapter live end-to-end.
- Additional carriersWeek 6–8
Shiprocket, BlueDart, DTDC, XpressBees — each adapter in days, not weeks.
- Merchant portal & ops consoleWeek 9–10
React front-ends, dispatch UX, tracking views, internal ops tooling.
- Hardening & go-liveWeek 11–12
Load testing, idempotency audit, HMAC verification, observability, production cutover.
Timeline reflects the phased shape of the build. Exact durations for your project depend on scope.
Outcome.
1,200+ orders routed through the platform to date. Six carriers live behind one contract. Onboarding a new courier is now a focused adapter build measured in hours, not weeks. Merchants see one unified tracking experience regardless of which carrier actually moves the parcel. The spine holds.
“Straightforward, reliable, and technically sharp. He delivered exactly what was discussed with zero ambiguity. Would bring him back for any logistics-tech project.”
Need something like this built?
I build logistics platforms, marketplaces, AI agents and production full-stack systems for startups and SMBs. 30-minute scoping call, fixed-price or monthly retainer. Same-week start in most cases.