Shipping Aggregator and Label Automation

Aggregator-based fulfilment is the default for sellers across India and South East Asia, and for good reason: one contract, many carriers, serviceability by pin code, and rates that beat direct carrier accounts at low volume. The cost is a second system. Orders live in Zoho Inventory, shipments live in the aggregator dashboard, and a human moves data between them all day.

The daily reality looks like this. Someone opens a sales order in Zoho, retypes the delivery address into the aggregator panel, checks which carriers serve that pin code, picks one on price or expected delivery, books it, downloads a label PDF, prints it, then goes back into Zoho to type the AWB number into a note or a custom field so support can find it later. Multiply by a few hundred orders a day and the errors are inevitable: transposed pin codes, weights entered from memory, labels printed against the wrong package, AWB numbers that never made it back into Zoho at all. Then the exceptions start. An NDR sits in a dashboard nobody watches until the customer calls. An RTO comes back and nothing in Zoho reflects that stock is in transit to your warehouse rather than delivered. COD remittances arrive as a lump sum against a settlement report that has to be matched to hundreds of orders by hand. Weight discrepancy charges appear on the aggregator ledger with no corresponding bill in Zoho Books, so shipping cost per order is a guess.

What ECOSIRE builds

A connector that makes the aggregator invisible to your operations team. They work in Zoho; the shipping happens underneath.

Booking from the record you are already looking at

We build a Sigma widget embedded in the Zoho Inventory Sales Order and Package detail pages. It reads the shipping address, weight and dimensions from the record, calls your aggregator account through Deluge invokeurl over an authenticated connection, and returns live serviceability and rate options for that destination. You pick a service — or let a configured rule pick for you on cheapest, fastest, or a preferred carrier per zone — and the booking is placed. No retyping, no second browser tab.

Labels and AWB back on the Zoho record

On a successful booking the connector writes the AWB number, carrier, service level, expected delivery window and booked freight cost onto the Zoho Inventory Shipment record and its linked custom fields, and creates the Shipment against the Package so stock movement stays correct. The label PDF is retrieved and stored to Zoho WorkDrive, then attached to the Shipment and, where you want it, to the Zoho Books invoice, so it is available from either side. Manifests are generated in bulk for a day's bookings, and pickup requests are raised in the same action.

Tracking that updates without anyone refreshing a dashboard

A Zoho Creator REST endpoint receives status callbacks from the aggregator and maps raw carrier scan codes to a normalised milestone set on the Shipment record — manifested, picked up, in transit, out for delivery, delivered, NDR raised, RTO initiated, RTO delivered. Where callbacks are not available for a service, a scheduled Deluge function polls the tracking API on an interval you set. Milestone changes drive downstream behaviour: Zoho Flow notifies the customer, updates the linked Zoho CRM record where you use it, and moves the sales order through your fulfilment stages.

Exceptions handled as work, not as noise

NDRs land in a queue in a Zoho Creator application with the customer's contact details, the carrier's reason code and the reattempt deadline. Your team acts from that queue — reattempt, update address, convert to RTO — and the action is pushed back to the aggregator through the API. RTO shipments create the corresponding inbound movement in Zoho Inventory so returning stock is visible before it lands, and the sales return and credit note flow in Zoho Books is triggered on your configured rules rather than remembered.

The money side, reconciled

COD remittance files are imported and matched against Zoho Books payments through a clearing account, with unmatched lines held in an exception report instead of being force-fitted. Freight charges, weight discrepancy adjustments and RTO charges from the aggregator's ledger are posted as vendor bills in Zoho Books against the accounts you nominate, and allocated per shipment so that shipping cost per order and per SKU becomes a real number in Zoho Analytics rather than an estimate at month end.

Rules you control

Carrier selection rules, packaging and weight defaults per SKU, zone mapping, service level by order value or customer tier, and cut-off times are configuration held in Zoho Creator forms. Your operations lead changes them without a developer. Every booking, cancellation and status change is written to an audit log with the API request and response retained, so a disputed shipment has evidence behind it.

Who this is for

Sellers shipping tens to thousands of orders a day out of Zoho Inventory who use an aggregator rather than direct carrier contracts: D2C brands, marketplace sellers with their own storefront, and distributors running B2B dispatch alongside retail. It is most valuable where COD is a meaningful share of volume, because the reconciliation work is where the manual hours actually go.

How delivery works

1. Scoping call. We confirm which aggregator account you hold and what its API exposes to you, your order and package flow in Zoho Inventory, your carrier selection logic, your COD settlement format, and which Books accounts freight and adjustments should post to. 2. Fixed quote. A written scope naming every integration point, rule and report in build, at a fixed price. 3. Build. The Sigma widget, Deluge functions, Creator application, webhook endpoint and Flow orchestrations are developed against your sandbox aggregator credentials where available, or against a rate-limited test account on your live one. 4. Test organization. Everything is installed into a sandbox Zoho Inventory and Books organization and run end to end: rate check, booking, label, tracking through to delivery, an NDR, an RTO, and a COD settlement import. 5. Production install. Applied to your live organization, with a pilot period where a subset of daily orders ships through the connector alongside your existing process. 6. Support window. We stay through your first full settlement cycle so the reconciliation is proven against real money, not test data.

Boundaries worth stating

This is built to order after a quotation, with a typical lead time of two to four weeks. It is not a downloadable app and there is no trial version, because there is nothing pre-built to trial. The connector works against the API your aggregator contract actually gives you — if a capability such as rate shopping, label retrieval or webhook callbacks is not exposed on your plan, we will tell you during scoping rather than after the build, and scope the polling fallback instead. We do not resell shipping, negotiate rates, or hold your carrier relationship; that stays entirely yours.