Multi-Marketplace Order Processing on Autopilot: Unicommerce Invoices, Labels & Manifests

We started by documenting the team's real manual process — every click, every download, every file name — and then reproduced it one real order at a time, per channel, in dry-run mode first. That's how the undocumented differences surfaced: Myntra and both Nykaa channels go straight to ready-to-ship on invoicing; Ajio leaves the shipment without a courier until a separate allocation call; Flipkart orders refuse invoicing until their processing time (8 PM) and are picked up in the next morning's slot; and Amazon returns labels as raw ZPL for thermal printers.

Dispatch is irreversible, so the system is built around a ledger. Each shipment moves through named stages — invoiced, ready-to-ship, dispatched — or parks at a named 'stuck' stage that's retried automatically next run. A dispatch is written to the ledger the instant the manifest call succeeds, before any document is downloaded, so a later network failure can never cause a shipment to be manifested twice.

Amazon's ZPL labels are rendered to PDF on our own server rather than through an online converter, so customer names and addresses never leave the system; we verified the rendered barcodes decode correctly. The team gets both the PDF and the original .zpl for their thermal printer.

The outputs fit how the team already works. Documents land in a Drive folder tree they can browse by date, channel and run time. The picklist is a Google Sheet laid out the way the warehouse reads it — per-channel blocks of SKU and quantity, sorted by SKU. And every dispatched shipment is appended to the team's existing per-channel master spreadsheets in their exact column format, de-duplicated by AWB. We validated that mapping by regenerating a full day's real rows from our exports and matching them value-for-value against the team's hand-typed entries.

It runs on a Linux server under cron, not on a laptop. On day one, one scheduled run failed before touching any order because Google revoked the Drive token it used — and the failure alert, which shared that token, failed with it. We re-ran the slot by hand within minutes, then separated the credentials: the core job's token now carries only the Drive scope, alerts go through an independent channel, and non-critical uploads can no longer crash a run. The next scheduled run completed and reported in cleanly on its own.

Within two weeks the system went from dozens of orders a day to 250+ on busy days. Flipkart went live (its best morning: 188 orders dispatched in under 25 minutes), unverified Amazon orders are now verified automatically by the same rule the team used, and the schedule grew to six order runs starting at 7:30 AM. Real volume brought real failures — a slow panel, a marketplace that changed its acceptance process overnight — and each one became a safeguard: chunked manifests with state checks after timeouts, a per-channel circuit breaker so one stuck marketplace can't hold up the others, and alerts that escalate only when the same order keeps failing.

We then added the brand's Amazon Vendor Central Direct Fulfillment orders, which don't go through Unicommerce at all. Three times a day a job signs in to Vendor Central (reading the one-time password from a dedicated mailbox when needed), downloads invoices and ZPL labels, creates the carrier handover reports, confirms shipment, files everything in Drive and appends the team's order-sheet rows. The client gets a plain-language email after every run listing what was dispatched and, separately, anything that needs a person — with what to do next. The team's role shifted from operating panels to packing boxes.