Zoho Inventory + Shiprocket: Automate Shipping for Indian E-Commerce

Indian e-commerce sellers face a specific logistics problem that platforms built for Western markets do not solve well: managing COD remittances, RTO-heavy last-mile networks, multi-courier serviceability across 19,000-plus pin codes, and reconciling AWB numbers back into inventory records. Zoho Inventory handles the order and stock side well. Shiprocket aggregates 17-plus courier partners including Delhivery, BlueDart, DTDC, Ekart, and Ecom Express under one API. The gap between the two is where orders fall through, shipment statuses go untracked, and COD payments arrive without matching entries in your books.

This guide walks through a production-grade Zoho Inventory Shiprocket integration that automates AWB generation the moment an order is confirmed, syncs tracking status back into Zoho Inventory, handles COD remittance events, and creates a structured RTO workflow so returned stock lands back in your warehouse records without manual intervention. If you are already using Zoho Inventory for Indian e-commerce, this integration is the natural next step to close the fulfilment loop.

How the Integration Architecture Works

The integration runs on three communication channels between Zoho Inventory and Shiprocket.

• Zoho to Shiprocket (outbound): When a sales order reaches Confirmed status in Zoho Inventory, a Deluge custom function calls Shiprocket’s REST API to create the shipment and assign an AWB number.
• Shiprocket to Zoho (inbound webhooks): Shiprocket fires status-change webhooks at your endpoint. A serverless function (hosted on Zoho Catalyst or a small AWS Lambda) receives these events and updates the corresponding sales order in Zoho Inventory via the Zoho Inventory API.
• COD remittance channel: Shiprocket’s remittance webhook fires when COD collections are settled. This triggers a Zoho Books payment receipt entry via the Zoho Books API, closing the payment loop without manual reconciliation.

This three-channel model keeps both platforms as sources of truth for their respective domains: Zoho Inventory owns stock and order data; Shiprocket owns shipment execution and courier selection.

Step 1: Shiprocket API Setup and Authentication

Shiprocket uses JWT-based authentication that expires every 24 hours. Your integration must handle token refresh automatically.

Getting Your API Credentials

1. Log into your Shiprocket account and go to Settings > API.
2. Note your registered email and password. These are the credentials you use to generate JWT tokens.
3. For production workloads, use a dedicated Shiprocket sub-account email so credential rotation does not break integrations tied to your main account.

Token Generation

POST to https://apiv2.shiprocket.in/v1/external/auth/login with your email and password. The response contains a token field valid for 24 hours. Store this token in a Zoho Catalyst KV store or an AWS Secrets Manager secret with a 23-hour TTL so it refreshes before expiry.

POST https://apiv2.shiprocket.in/v1/external/auth/login
Content-Type: application/json

{
  "email": "your-email@company.com",
  "password": "your-password"
}

All subsequent API calls include the header Authorization: Bearer <token>. Build a token helper function that checks token age and refreshes automatically. This prevents the most common production failure: 401 errors from expired tokens mid-fulfilment.

Step 2: Zoho Inventory Webhook for New Orders

Zoho Inventory supports outgoing webhooks triggered by record events. You need a webhook that fires when a sales order status changes to Confirmed.

Configuring the Webhook in Zoho Inventory

1. Go to Settings > Integrations > Webhooks in Zoho Inventory.
2. Create a new webhook with the trigger: Sales Orders > On Status Change.
3. Filter condition: status == "confirmed".
4. Set the endpoint URL to your Catalyst function or Lambda URL.
5. In the payload, map these fields: salesorder_id, salesorder_number, customer_name, shipping_address (line1, line2, city, state, zip, country), line_items (item_name, sku, quantity, unit_price), payment_terms (to identify COD vs prepaid), cf_awb_number (custom field for tracking).

Custom Fields to Add in Zoho Inventory

Before the integration goes live, add these custom fields to the Sales Orders module in Zoho Inventory:

Field Label	API Name	Type	Purpose
AWB Number	cf_awb_number	Text	Stores the Shiprocket AWB
Shiprocket Order ID	cf_shiprocket_order_id	Text	Shiprocket internal order reference
Shipment Status	cf_shipment_status	Dropdown	Pending / Picked / In Transit / Delivered / RTO
Courier Partner	cf_courier_partner	Text	Delhivery, BlueDart, DTDC, etc.
COD Remittance ID	cf_cod_remittance_id	Text	Links to Zoho Books payment receipt

Step 3: Automated AWB Generation via Shiprocket API

This is the core outbound flow. When your webhook endpoint receives a confirmed order from Zoho Inventory, it executes three sequential API calls to Shiprocket.

3a: Serviceability Check

Before creating the order, verify that at least one courier can service the destination pin code. POST to /courier/serviceability/ with the pickup and delivery pin codes, weight, and COD flag. If no couriers are available, update the Zoho Inventory order status to a custom “Serviceability Failed” stage and alert your operations team via Zoho Cliq or email.

POST https://apiv2.shiprocket.in/v1/external/courier/serviceability/

{
  "pickup_postcode": "400001",
  "delivery_postcode": "560001",
  "weight": 0.5,
  "cod": 1
}

3b: Create Shiprocket Order

Call /orders/create/adhoc with the full order payload. Map Zoho Inventory fields to Shiprocket fields carefully. The payment_method field must be "COD" for cash-on-delivery orders and "Prepaid" for all others. The order_date should use IST (UTC+5:30). The sub_total is the order value in INR.

POST https://apiv2.shiprocket.in/v1/external/orders/create/adhoc

{
  "order_id": "ZI-10045",
  "order_date": "2026-06-14 10:30",
  "pickup_location": "Primary Warehouse",
  "billing_customer_name": "Priya Sharma",
  "billing_address": "12 MG Road",
  "billing_city": "Bengaluru",
  "billing_pincode": "560001",
  "billing_state": "Karnataka",
  "billing_country": "India",
  "billing_email": "priya@example.com",
  "billing_phone": "9876543210",
  "shipping_is_billing": true,
  "order_items": [
    {
      "name": "Stainless Steel Bottle 1L",
      "sku": "SSB-1L",
      "units": 2,
      "selling_price": 499
    }
  ],
  "payment_method": "COD",
  "sub_total": 998,
  "length": 20,
  "breadth": 15,
  "height": 10,
  "weight": 0.5
}

On success, Shiprocket returns a order_id (Shiprocket’s internal ID) and shipment_id. Store both back on the Zoho Inventory sales order via the Zoho Inventory API PATCH endpoint.

3c: Assign AWB Number

Call /courier/assign/awb with the shipment_id and your preferred courier ID (or let Shiprocket auto-assign based on your configured rules). The response includes the awb_code, courier_name, and routing_code.

POST https://apiv2.shiprocket.in/v1/external/courier/assign/awb

{
  "shipment_id": "123456789",
  "courier_id": 1
}

Write the awb_code and courier_name back to cf_awb_number and cf_courier_partner on the Zoho Inventory sales order. This gives your support team instant visibility into the carrier and tracking number without leaving Zoho Inventory.

Multi-Courier Selection Logic

Rather than hardcoding a courier ID, build a selection function that reads from a priority table you maintain in Zoho Sheet or a Catalyst datastore. Typical logic for Indian sellers:

• COD orders to Tier-1 cities (Mumbai, Delhi, Bengaluru, Hyderabad, Chennai, Pune): Delhivery or Ecom Express for cost efficiency.
• COD orders to Tier-2 and Tier-3 cities: Ekart or DTDC for wider reach.
• High-value prepaid orders (above INR 2,000): BlueDart for reliability and faster SLA.
• Heavy shipments (above 5 kg): XpressBees or Delhivery Surface.

The serviceability response includes a courier recommendation list with charges and estimated delivery days. Your function ranks these against your priority table and picks the best match. This logic alone can cut average shipping cost by 8-15% compared to fixed courier assignments.

Step 4: Shipment Status Webhook Back to Zoho Inventory

Shiprocket supports outgoing webhooks for shipment status changes. Configure these in Shiprocket under Settings > Webhooks. Add your endpoint URL and select the following events: Pickup Scheduled, Picked Up, In Transit, Out for Delivery, Delivered, RTO Initiated, RTO Delivered.

Webhook Payload Handling

Each Shiprocket webhook POST contains an awb field, a current_status string, and a shipment_track_activities array. Your endpoint handler must:

1. Look up the Zoho Inventory sales order by querying cf_awb_number == incoming_awb via the Zoho Inventory search API.
2. Map the Shiprocket status string to your cf_shipment_status dropdown value.
3. PATCH the sales order with the updated status.
4. For Delivered status, also trigger a check on payment method. Prepaid orders can be marked as closed. COD orders stay open until the remittance webhook fires.

Status mapping reference for Indian courier networks:

Shiprocket Status	Zoho Inventory Status	Action Required
PICKUP SCHEDULED	Pickup Scheduled	None
PICKED UP	Picked Up	None
IN TRANSIT	In Transit	None
OUT FOR DELIVERY	Out for Delivery	None
DELIVERED	Delivered	Close order (prepaid); await COD remittance (COD)
RTO INITIATED	RTO Initiated	Alert ops team; prepare receiving workflow
RTO DELIVERED	Returned	Restock item; create purchase receipt reversal
LOST	Lost in Transit	Raise courier insurance claim

This real-time status flow means your operations team can track every shipment from the Zoho Inventory dashboard without switching to the Shiprocket portal. For context on wider logistics integration patterns, the approach here is comparable to how a ShipStation integration works, but adapted for Indian courier networks and COD requirements.

Step 5: COD Remittance Tracking

COD remittances are the most common source of reconciliation errors for Indian e-commerce sellers. Shiprocket batches COD collections and remits them on a cycle (typically every 7-15 days depending on your plan). Each remittance covers multiple orders.

Remittance Webhook Configuration

Shiprocket fires a COD_REMITTANCE webhook event when a remittance batch is processed. The payload includes a remittance_id, remittance_date, bank_transfer_amount, and an array of orders each containing the awb, order_id, cod_amount, and deducted_charges.

Automated Zoho Books Entry

Your remittance handler should:

1. For each order in the remittance batch, look up the Zoho Inventory sales order by AWB number.
2. Create a payment receipt in Zoho Books against the corresponding invoice using the Zoho Books API.
3. Set the payment amount to cod_amount - deducted_charges (net remittance after Shiprocket fees).
4. Use the remittance_id as the payment reference number for audit trail.
5. Update cf_cod_remittance_id on the Zoho Inventory sales order with the remittance_id.

Shiprocket deducts handling charges, COD charges (typically 1-2% of order value or INR 45-75 per shipment), and any reverse logistics charges before remitting. Your Zoho Books entry should record the gross COD amount as revenue and the deductions as a separate expense line to keep your P&L accurate. This matters especially if you are already using Amazon Seller Central integration alongside Zoho Inventory, since consistent payment reconciliation logic across channels prevents reporting discrepancies.

Step 6: Returns and RTO Workflow

RTO (Return to Origin) rates for Indian e-commerce can run 15-30% for COD orders, making a structured RTO workflow critical. The integration handles this through a combination of Shiprocket status webhooks and Zoho Inventory automation.

When RTO Initiated Fires

Your webhook handler receives the RTO_INITIATED event. At this stage:

• Update cf_shipment_status to “RTO Initiated” on the sales order.
• Send an internal notification to your operations team via Zoho Cliq or email so they can proactively contact the customer.
• Do not restock inventory yet. The item is still in transit back to your warehouse.

When RTO Delivered Fires

The RTO_DELIVERED event confirms the shipment is back at your pickup location. Your handler should now:

1. Update the sales order status to a custom “Returned” stage in Zoho Inventory.
2. Create a purchase receipt in Zoho Inventory to add the returned quantity back to the originating warehouse (or a designated returns warehouse if you segregate returned stock).
3. If the original order was invoiced in Zoho Books, create a credit note against the invoice to reverse the revenue entry.
4. For COD orders where remittance was never paid (Shiprocket will not remit for RTO orders), ensure no open accounts-receivable entries remain in Zoho Books.

Initiating Returns from Zoho Inventory

For customer-initiated returns (not RTO), use Shiprocket’s /orders/return API endpoint. Your Deluge custom function can trigger this from a button on the Zoho Inventory sales order. The integration creates a reverse pickup request in Shiprocket, assigns a return AWB, and tracks the return shipment through the same status webhook pipeline. Following solid inventory management best practices means capturing returned stock in the correct warehouse bin and triggering quality inspection workflows before the item goes back to sellable inventory.

Step 7: Putting It Together with Zoho Flow (Simpler Alternative)

If building and hosting custom webhook handlers feels too complex for your current engineering capacity, Zoho Flow provides a no-code alternative for the basic integration path. Zoho Flow supports Shiprocket as a connector with pre-built actions for order creation and AWB assignment.

Zoho Flow Setup for Basic Integration

1. Trigger: Zoho Inventory > Sales Order Status Changed to Confirmed.
2. Action 1: HTTP connector > POST to Shiprocket /orders/create/adhoc. Map Zoho Inventory fields to the Shiprocket payload using Flow’s field mapper.
3. Action 2: HTTP connector > POST to Shiprocket /courier/assign/awb using the shipment_id from Action 1’s response.
4. Action 3: Zoho Inventory > Update Sales Order. Write AWB and courier name back to custom fields.

The Zoho Flow path covers the outbound direction (Zoho to Shiprocket) well. For inbound status sync, you still need a webhook endpoint to receive Shiprocket’s status events. You can use a Zoho Flow webhook trigger connected to Zoho Inventory update actions to close this loop without custom code. For reference on how similar webhook-based sync works across Zoho integrations, the WooCommerce stock sync pattern uses an equivalent inbound webhook approach.

Limitations of the Zoho Flow Approach

Zoho Flow works well for 20-100 orders per day. At higher volumes or when you need the multi-courier selection logic, COD remittance automation, or the full RTO restock workflow, the custom Deluge and Catalyst function approach gives you the control and performance you need.

Monitoring, Error Handling, and Operational Checklist

A shipping integration that fails silently is worse than no integration. Build these safeguards from the start.

Error Scenarios to Handle

• Serviceability failure: Notify ops team immediately; do not leave order stuck in Confirmed status.
• AWB assignment failure: Retry once after 5 minutes; if still failing, alert ops and fall back to manual AWB assignment via Shiprocket dashboard.
• Webhook delivery failure: Shiprocket retries webhooks up to 5 times with exponential backoff. Ensure your endpoint returns HTTP 200 within 10 seconds. For long-running operations (Zoho Books entries), use async processing: accept the webhook, queue the work, return 200 immediately.
• Duplicate order creation: Shiprocket returns an error if you attempt to create an order with an order_id that already exists. Check for cf_shiprocket_order_id before calling the create endpoint.
• Token expiry during processing: Wrap all Shiprocket API calls in a token-refresh check. Store the token expiry timestamp alongside the token value.

Pre-Launch Checklist

Item	Check
Shiprocket test environment tested	Use Shiprocket staging credentials before pointing at production
Webhook endpoint reachable over HTTPS	Shiprocket rejects HTTP-only endpoints
Custom fields created in Zoho Inventory	AWB, Shiprocket Order ID, Shipment Status, Courier, COD Remittance ID
Pickup location configured in Shiprocket	Name must match exactly what you send in the API payload
COD vs prepaid detection tested	Confirm payment_method mapping works for both order types
RTO restock function tested with dummy order	Verify purchase receipt creates correctly in target warehouse
Error notification channel set up	Zoho Cliq channel or email for integration failures

For a full overview of all available options, explore our complete guide to Zoho integrations.