intelligent.pageDocs

ShipMozo

Shipmozo Indian multi-carrier shipping aggregator by Tensor Logistics; seller panel API exists but is not publicly documented, credentials come from the panel.

Shipmozo is an Indian multi-carrier shipping aggregator for e-commerce and direct to consumer sellers, operated by Tensor Logistics Private Limited of Gurugram, Haryana (CIN U63030HR2021PTC099653). It sits between a seller's sales channels and roughly 27 courier networks, pulling orders in, choosing a carrier, booking the waybill, chasing non-delivery and remitting cash on delivery money back to the seller. For a unified commerce database it is a shipments, NDR, RTO and COD remittance source, not a sales channel. It publishes no developer documentation, which is the main finding on this page.

At a glance

What it is

Shipmozo is one of the larger second-tier Indian shipping aggregators, competing with Shiprocket, NimbusPost, iThink Logistics and Pickrr. The commercial pitch is zero platform fee: "Shipmozo does not charge a platform or subscription fee. You pay only for the shipping cost per shipment." Revenue comes from the margin between the negotiated carrier rate and the seller rate. SMS and WhatsApp notifications beyond a free allowance are charged per notification.

Published coverage as of September 2026: more than 29,000 serviceable pin codes domestically and international shipping to more than 195 countries.

Named courier partners on the courier integration page: Delhivery, DTDC, BlueDart, Ekart, Amazon Shipping, Shadowfax, Xpressbees, FedEx, UPS, Aramex, TCI and Movin, out of a claimed 27-plus. The presence of Movin is notable, because Movin publishes no API of its own and is absent from ClickPost's and Unicommerce's carrier lists, so Shipmozo is one of the few documented routes to it.

Order sources, per the FAQ: manual upload, e-commerce platform integration (Shopify, WooCommerce, Magento), WhatsApp, Instagram, marketplaces and offline channels.

The operational features that produce data a commerce database wants:

  • COD remittance. "Shipmozo offers fast COD remittance with D+1 and D+2 payouts at no extra cost", with a dashboard showing pending, in-transit and settled amounts. That is an unusually fast cycle for the Indian market, where D+7 is common, and it makes Shipmozo a genuine settlement source.
  • NDR handling. "Structured reattempt scheduling (up to 3 to 5 attempts depending on the courier)" with free NDR calling support, managed from the dashboard.
  • AI courier allocation, selecting a carrier per shipment on pin code performance, cost and delivery speed.
  • Branded tracking pages with WhatsApp and SMS notifications to the buyer.
  • Weight dispute resolution, described as a documented process, though the FAQ does not set out the steps.

Shipmozo also sells adjacent products: Shipmozo Checkout (COD, saved addresses, own branding, no monthly fee), Appokart (a Shopify mobile app builder) and ShopSifu (a Shopify AI chat assistant). Those are separate surfaces and none of them is documented either.

API access

An API exists. Shipmozo's own blog on open shipping APIs lists the functions such an API covers, "Order and shipment creation, Serviceability checks, Rate and service selection, Label and document generation, Tracking and event updates, Cancellation, returns, and exception handling", and its marketing repeatedly refers to programmatic integration. But nothing about Shipmozo's own implementation is published.

Checks made, so that this is a finding rather than a guess:

  • docs.shipmozo.com, api.shipmozo.com, developer.shipmozo.com and seller.shipmozo.com do not resolve in DNS.
  • shipmozo.readme.io returns 404, so there is no ReadMe hub.
  • /api, /api-doc, /api-docs, /apidocs, /api-documentation, /api-integration, /developer, /developers and /docs return 404 on www.shipmozo.com and on app.shipmozo.com.
  • The published sitemap contains 20-plus product and resource pages and around 200 blog posts, and not one developer or API reference page among them.
  • The two pages that come closest, the blog post on open APIs and the encyclopedia entry on shipping APIs, are generic explainers. Both end by directing the reader to talk to an expert rather than to a reference.
  • app.shipmozo.com and panel.shipmozo.com both return 200 and are the seller panel, login walled.

The route to credentials is: register a seller account, then take the public key and private key from the panel.

Contact for the official specification: Contact@shipmozo.com, helpline 7375000072.

What the API surface actually looks like

The reference is not published, but the API is real and its shape can be established from evidence rather than guessed. A working WooCommerce plugin published on GitHub, chiranjitWeb/Shipmojo-for-woocommerce, wraps it, and its source states that it "Wraps every endpoint from the Shipmozo API documentation" (implying a documentation pack is given to integrators, just not published on the web).

Corroboration that this is genuinely Shipmozo's API and not an invention: the base URL the plugin uses, https://shipping-api.com, serves a page reading "Apporio Shipping, Welcome To shipmozo", byte-for-byte identical to the page served by app.shipmozo.com, and it links to shipmozo.com/privacy-policy, shipmozo.com/refund-cancellation and shipmozo.com/terms-conditions. Same application, two hostnames.

  • Base URL: https://shipping-api.com/app/api/v1
  • Headers: Content-Type: application/json, plus public-key and private-key

Endpoint names invoked by the plugin, relative to that base:

Request field names seen in the plugin's order push include name, sku_number, quantity per product, plus order_id and pickup_pincode at the top level. Responses are JSON with a result, message and data envelope; the plugin treats result of '0' as failure.

Warning

Everything in this subsection comes from a third-party plugin, not from Shipmozo. It is strong evidence, because it is working code against a host that demonstrably belongs to Shipmozo, but it is not a specification: there is no field-by-field contract, no error catalogue, no rate limit and no versioning guarantee. Use it to scope the connector and to ask Shipmozo precise questions, not as the contract itself. Be equally sceptical of any other third-party source; generated "API skill" repositories with fabricated endpoints are common for platforms in this segment, and this one was accepted only because the host could be independently tied back to Shipmozo.

Note also that the repository is named "Shipmojo" while everything inside it says "Shipmozo". If your catalogue carries a separate ShipMojo entry, it is almost certainly the same misspelling: no ShipMojo product exists. shipmojo.in is a parked GoDaddy domain, and shipmojo.com, .co, .co.in, .io, .net, .app, .ai, .org, .tech, .xyz, .us and getshipmojo.com do not resolve at all.

Authentication

Two static credentials, a public key and a private key, both issued from the seller panel and both sent on every request as custom headers. There is no token exchange, no OAuth flow, no documented expiry and no refresh endpoint.

  Header names as used by the Shipmozo WooCommerce plugin.
  Not confirmed against official documentation.
curl --location 'https://shipping-api.com/app/api/v1/get-warehouses' \
  --header 'Content-Type: application/json' \
  --header 'public-key: YOUR_PUBLIC_KEY' \
  --header 'private-key: YOUR_PRIVATE_KEY'

Both values are bearer-equivalent secrets despite the "public" name; neither is safe in client-side code. Multi-seller handling is straightforward: one key pair per seller account stored against your channel_account_id. Key rotation, revocation and lifetime are all undocumented, so ask.

Objects we can read

Everything below exists in the seller panel. Where an endpoint name is given it comes from the third-party plugin described above, not from official documentation, and no response schema for it is published anywhere.

Orders

Orders imported from connected channels (Shopify, WooCommerce, Magento, marketplaces, WhatsApp, Instagram, manual upload). Because the order originates on a sales channel, prefer reading it from that channel's own connector and use Shipmozo only for the shipping side. The one thing Shipmozo adds is the link between a channel order and the AWB actually used.

Order items

Present inside the order in the panel. Not documented.

Products and listings

None. Shipmozo holds no catalogue.

Inventory

None.

Shipments and tracking

The core object: AWB, courier, service, status and scan history, plus the branded tracking page. Serviceability and rating are both callable, as pincode-serviceability and rate-calculator, and rate-calculator returns per-courier rates good enough to drive a live checkout shipping option, which is what the WooCommerce plugin does with it. A volumetric weight calculator is published as a public tool, which tells you volumetric weight is part of the rating model, but the formula constants are not stated in a machine-readable form.

No tracking endpoint appears in the plugin. It builds a public tracking page at /track-order/?awb=... on the merchant's own site instead, which suggests tracking is consumed as a hosted page rather than as structured events. Whether a machine-readable tracking or scan-history endpoint exists is the most important open question on this platform.

NDR records carry the reattempt schedule (3 to 5 attempts depending on courier) and the outcome of the NDR calling service. RTO is tracked as a distinct outcome. Proof of delivery is not described on any public page.

Returns and cancellations

Reverse pickup and RTO are supported operationally. No documented object.

Payments and settlements

The COD remittance ledger, with pending, in-transit and settled amounts and a D+1 or D+2 payout cycle. This is the most valuable Shipmozo-only data: it reconciles cash collected at the door against money landed in the seller's bank, which no sales channel can tell you. Ask specifically whether the remittance ledger is exposed by API, and at what granularity, per shipment or per payout batch. Per payout batch alone is much less useful.

Customers

Buyer name, address and phone ride on each shipment. All PII. Shipmozo has no separate customer object.

Locations

Pickup warehouses are readable with get-warehouses and creatable with create-warehouse. Warehouse selection is per shipment, and the plugin pairs it with a pickup_pincode at the top level of the order push.

Writing back: listings, price and stock

Not applicable, this is a carrier aggregator. Shipmozo owns no listing, price or stock, and there is no endpoint that could change any of them. Catalogue and price writes belong to the sales channel connector.

The write path is shipment creation and cancellation, and it runs as a sequence rather than a single call:

  1. pincode-serviceability to confirm the destination is deliverable.
  2. rate-calculator to get per-courier rates.
  3. push-order to create the order in Shipmozo, with the product lines (name, sku_number, quantity), order_id and pickup_pincode.
  4. Either assign-courier with a chosen courier from step 2, or auto-assign-order to let Shipmozo's allocation engine decide. This is the step that produces the AWB.
  5. schedule-pickup to book the collection.
  6. get-order-label/ to fetch the label, returned as a base64 PNG rather than a PDF.
  7. cancel-order to cancel.

That four-call minimum (push, assign, schedule, label) is worth designing around: each step can fail independently, so the connector needs a per-order state machine, not a single try-and-retry. NDR actions (reattempt, update address, mark RTO) are real panel operations but no endpoint for them appears in the plugin, so ask Shipmozo whether the NDR surface is callable at all.

Webhooks and notifications

Not published. Shipmozo's notification story is buyer-facing: WhatsApp and SMS messages, and a branded tracking page. Whether the platform will POST shipment status changes to a seller's server is not stated anywhere public.

Until confirmed, plan for polling. For an Indian aggregator with 3 to 5 NDR reattempts and typical 2 to 6 day transit, polling active shipments every 2 to 4 hours during business hours captures every state change that matters, and polling COD remittance once daily is enough given a D+1 or D+2 cycle. Never poll delivered, cancelled or RTO-completed shipments.

Rate limits and pagination

Not published. No quota numbers, no headers, no page sizes, no 429 semantics. Treat the API as fragile until measured: serialise requests, stay at one or two per second, back off on any 429 or 5xx, and agree a backfill window with Shipmozo before pulling history.

Mapping to the unified model

Field names cannot be given because none are published. The table below is the target shape to request, and every right-hand entry is unverified.

orders

order_items

Not documented. Read from the sales channel.

listings, inventory

Not applicable.

shipments

returns

RTO is the dominant return path in Indian COD e-commerce and Shipmozo tracks it. Map an RTO shipment to a returns row with reason taken from the NDR reason and received_at set when the RTO shipment is delivered back to the seller.

settlements

customers

Buyer name, phone and address ride on the shipment. PII, unmasked. No customer object.

locations

Pickup and warehouse addresses configured in the panel. Not documented.

Gaps and open questions

  • No official reference is published. The base URL, header names and endpoint names on this page come from a third-party plugin and are unverified against a specification. Field-level contracts, error codes, versioning and limits are all unknown. Ask Shipmozo for the documentation pack that plugin's author clearly had.
  • No tracking endpoint was found. The plugin consumes tracking as a hosted page. If Shipmozo does not expose scan events as structured data, the shipments.events[] part of the unified model cannot be filled from this connector at all, which would materially reduce its value.
  • No NDR endpoint was found. NDR handling is a headline product feature but no callable surface appears in the plugin.
  • Whether webhooks exist at all. This decides between a cheap push design and an expensive polling design across every active shipment.
  • Two hostnames, one application. shipping-api.com and app.shipmozo.com serve identical bytes. Which is the supported API host, and whether either is guaranteed stable, is not stated.
  • COD remittance granularity. Per shipment or per payout batch. Per shipment is what makes the data worth having.
  • Status vocabulary. Whether Shipmozo normalises statuses across 27 couriers or passes each courier's raw codes through. If it normalises, get the mapping table; if it does not, you need 27 mapping tables.
  • Weight disputes mutate cost after the fact. A shipment's charged weight and freight can change days after delivery. Any warehouse built on this data needs a restatement path, not an append-only assumption.
  • The 27-plus courier list is partially published. Twelve are named on the courier integration page; the rest are not. The full list matters for status mapping.
  • Proof of delivery. Nothing public describes whether a signature, photo or OTP confirmation is captured or retrievable.
  • Shipmozo Checkout. A separate product that would hold pre-order and COD decision data. Entirely undocumented.
  • No aggregator-of-aggregators route. Shipmozo is not listed on ClickPost or in Unicommerce's public integration list, so there is no indirect path to its data either.

Sources