Shiprocket WMS

Shiprocket Fulfilment is the warehousing arm of India's largest shipping aggregator. A brand ships its stock into Shiprocket's fulfilment centres, connects its sales channels, and Shiprocket picks, packs and dispatches each order on one of its carrier partners. The carrier and order side of Shiprocket has a fully public API and is documented at /connectors/shiprocket; this page is only about the fulfilment and warehousing surface. The honest summary is that the fulfilment product has no API of its own. Shiprocket's published Postman collection has twenty seven folders and not one of them mentions a warehouse, an inbound consignment, a receipt or a stock location. What it does have is an account level product catalogue and a single account level stock counter, which is the closest thing to warehouse inventory you can read, and an order creation lane that doubles as the way orders reach the warehouse. Everything below was read from the official collection on 2026-09-22.

At a glance

What it is

Shiprocket Fulfilment is sold as a 3PL: D2C fulfilment, B2B fulfilment, marketplace fulfilment and returns management, run out of Shiprocket operated centres rather than the brand's own warehouse. The pitch is stock distribution for speed: hold inventory in several centres, be closer to the buyer, and offer same day, next day or four hour delivery with a delivery badge on the storefront.

Published scale, all from Shiprocket's own pages on 2026-09-22, and inconsistent between them:

Treat all of these as marketing figures. The useful part is the shape: a few dozen multi-tenant centres, integration with the usual storefronts and marketplaces, and the same carrier pool the aggregator already uses.

Fulfilment is one product in a wide portfolio that also includes domestic and international shipping, B2B cargo, hyperlocal, an omnichannel retail product, checkout and pre-order tooling, returns, tracking and a data product. That matters when reading the API: the endpoints are shared across the whole account, and nothing in them is labelled as belonging to fulfilment.

API access

There is no separate fulfilment API programme. You get one Shiprocket account, create an API user in the panel under Settings, API, Add New API User, and that credential reaches every endpoint your account is entitled to. Whether fulfilment specific screens appear in your panel depends on the commercial arrangement, not on the credential.

Two surfaces exist beyond the public API and both are login only:

• https://wms.shiprocket.in/, which answers HTTP 200 with a bare single page application titled frontend. This is the warehouse management front end. Nothing about it is documented publicly and it has no published API.
• The fulfilment views inside the main Shiprocket seller panel, reached after the fulfilment contract is live.

What was checked to establish that no fulfilment API is published:

1. The official collection was fetched as JSON from the Postman documenter and walked in full. Its folders are: Authentication API, Create Or Update Order, Couriers, Orders, Return and Exchange Orders, Shipments, Labels Manifests Invoice, Wrapper API, NDR, Tracking, Pickup Addresses, Hyperlocal (with Orders, Couriers, Tracking, Pickup Addresses), International (with Tracking), Account, Products, Listings, Channels, Inventory, Countries, Statement Details, Discrepancy Details, File Imports. There is no Fulfilment, Warehouse, Inbound, Receiving or Storage folder.
2. The strings inbound, ASN, GRN, putaway and consignment do not occur anywhere in the collection.
3. No first party OpenAPI document, SDK or fulfilment specific Postman collection was found. Third party collections named after Shiprocket exist in the public Postman index and are copies or partial forks of the official one; none of them add fulfilment endpoints, and none should be trusted as a source.

Authentication

Identical to the shipping API. There is no fulfilment scope, no second token and no per warehouse credential.

1. Create an API user in the Shiprocket panel. Use a dedicated address, not a human's login, because the token is minted from a password.
2. Exchange email and password for a JWT.
3. Send the JWT as a bearer token on every call.
4. Re-login when it expires. The token lasts 10 days and there is no refresh endpoint, so treat expiry as re-authentication rather than refresh.

curl -s -X POST https://apiv2.shiprocket.in/v1/external/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"api-user@brand.example","password":"..."}'

curl -s "https://apiv2.shiprocket.in/v1/external/inventory?page=1&per_page=100" \
  -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9..."

For several brands under one operator, expect one Shiprocket account and one API user per brand, and key your credential store on the account rather than on the warehouse.

Objects we can read

Orders

Orders inside a Shiprocket Fulfilment account are ordinary Shiprocket orders. The endpoints, filters, pagination and sample responses are on /connectors/shiprocket and are not repeated here. Two things are specific to fulfilment:

• The states that matter inside a warehouse, allocated, picked, packed, awaiting handover, are not exposed as distinct order statuses in the public API. You see the order, and then you see a shipment with an AWB once it has been manifested.
• Order to ship turnaround inside the fulfilment centre therefore has to be approximated from the gap between order creation and the first carrier scan.

Products and listings

The catalogue is account level and is the seeding surface for a fulfilment integration, because the warehouse works off SKU codes that must match yours exactly.

GET /v1/external/products and GET /v1/external/products/show/{product_id}:

{
  "data": [
    {
      "id": 17484610,
      "sku": "chakra123",
      "hsn": "441122",
      "name": "Kunai",
      "category_code": "default",
      "category_name": "Default Category",
      "weight": "0 kg",
      "cost_price": "0.00",
      "mrp": "0.00",
      "low_stock": 0,
      "ean": "",
      "upc": "",
      "isbn": "",
      "quantity": 41,
      "brand": "",
      "dimensions": "10 x 10 x 10 cm",
      "status": "INACTIVE",
      "type": "Single"
    }
  ]
}

Worth knowing for a fulfilment integration:

• POST /v1/external/products/qc-product-update/{productID} and the qc_details block on product creation turn a product into a quality check item, carrying product_image, brand, color, size, product_imei, serial_no, ean_barcode and check_damaged_product. This is the hook the warehouse and the doorstep quality check use, and it is the one genuinely fulfilment flavoured thing in the catalogue API.
• POST /v1/external/products/import takes a CSV and returns a job id. GET /v1/external/products/sample returns the template, whose columns are Category Name, Master Sku Code, Product Name, Low Stock Warning At, Description, Length, Width, Height, Weight, ean, upc, isbn, Color, Brand, Size, Tax Code, Image Url, Custom Detail Fields, MRP, Cost Price, Active, Type, HSN code. Use this for the initial SKU load before the first inbound.
• GET /v1/external/listings and the mapped and unmapped exports reconcile Shiprocket SKUs against channel SKUs. Get this clean before stock goes into a warehouse, because an unmapped listing is an order the warehouse cannot pick.

Inventory

One endpoint, one row per product, no location dimension.

GET /v1/external/inventory, with optional page, per_page, sort (ASC or DESC) and sort_by:

{
  "data": [
    {
      "id": 3448637,
      "sku": "BlackTshirt",
      "category_name": "Default Category",
      "is_combo": 0,
      "name": "Black tshirt XL",
      "type": "Single",
      "brand": "",
      "total_quantity": 12,
      "available_quantity": 12,
      "blocked_quantity": 0,
      "updated_on": "23 Jan 2019 12:03 PM"
    }
  ],
  "meta": {
    "pagination": {
      "total": 12080,
      "count": 2,
      "per_page": 2,
      "current_page": 1,
      "total_pages": 6040,
      "links": { "next": "https://apiv2.shiprocket.in/v1/external/inventory?page=2" }
    }
  }
}

Notes an implementer needs:

• blocked_quantity is the reserved bucket, so available_quantity is already net of it. Map the two separately rather than deriving one from the other.
• updated_on is a formatted string, not ISO 8601. Parse it explicitly.
• Pagination is a page number with a next link and a real total, so a full sweep is predictable: 12,080 products at 100 per page is 121 requests.
• There is no inbound quantity field. inventory.quantity_inbound has to come from your own inbound advice.

Shipments and tracking

Fully readable, and identical to the aggregator surface: shipments, tracking with scan history and proof of delivery, courier assignment. See /connectors/shiprocket.

Returns and cancellations

Return and exchange orders and NDR records are readable through the shared endpoints. What a fulfilment operator additionally needs, what was physically received back at the centre, whether it passed inspection, whether it went back into sellable stock or was written off, is not published. The only public signal that a return reached the warehouse is the reverse shipment being delivered, and the only signal that stock came back is available_quantity moving on the next inventory poll.

Payments and settlements

Statement Details and Discrepancy Details in the collection cover the shipping wallet and weight discrepancies. Storage and handling fees are not in them. From Shiprocket's own fulfilment pricing page the cost model has an inbound cost, an outbound cost, a packaging cost quoted per packaging type (corrugated box, polybag, bubble wrap as an add on), a per order cost, storage charges on items held in the centre, and extra charges for return to origin and for removal of goods. None of these arrive as an API object, so settlements.fees[] for fulfilment has to be built from invoices.

Locations

Pickup Addresses returns the seller's own pickup locations. It does not enumerate Shiprocket fulfilment centres, and nothing in the API does. Seed locations rows of type fulfilment_centre from the contract, and accept that you will not be able to join inventory to them.

Writing back: listings, price and stock

Shiprocket is not a sales channel, so there is no listing, price or marketplace stock write. Three writes matter for fulfilment, and only two of them are documented.

Stock counter, documented

PUT /v1/external/inventory/{product_id}/update

{ "quantity": 2, "action": "add" }

action takes add, replace or remove. product_id is the id from the inventory or products response, not the SKU. The response echoes the resulting counters:

{ "data": { "available_quantity": 51, "blocked_quantity": 0, "total_quantity": 51 } }

This is a bookkeeping counter for the account, not a warehouse adjustment. In a live fulfilment account the warehouse is the authority on stock, so writing here is the wrong direction of travel: use it for accounts where Shiprocket holds no stock, and treat it as read-only where it does. Agree which system owns the number before you enable any write.

Orders into the warehouse, documented

Pushing an order in is the ordinary order creation lane: POST /v1/external/orders/create/adhoc, or channel order import, then AWB assignment, pickup, label and manifest, or the Wrapper API which collapses those four. Full request bodies are on /connectors/shiprocket. In a fulfilment account the usual arrangement is that Shiprocket pulls orders from the connected channel itself, so check before you also create them, or you will duplicate.

Inbound consignments, not documented

There is no published endpoint to advise the warehouse that stock is arriving, and no GRN or receipt to read back. This is done in the panel or by file with the account team. Ask for: the inbound advice format, whether a purchase order or appointment reference is required, the receipt confirmation you get back and in what form, and how discrepancies between advised and received quantities are reported.

Webhooks and notifications

One webhook exists, and it is about parcels rather than warehouses. It is configured in the panel under Settings, API, Webhooks, with an optional shared secret sent as x-api-key, and it fires on tracking events. Details on /connectors/shiprocket.

Nothing pushes on stock. Poll on this cadence:

Rate limits and pagination

Shiprocket does not publish a numeric rate limit for any endpoint, and the fulfilment surface adds none. Pagination on inventory and products is page plus per_page with a meta.pagination envelope that includes total and total_pages, so sweeps are sizeable: plan the inventory sweep as a single paged job with a modest concurrency of two or three, and back off on any 429 or 5xx rather than assuming a published ceiling exists. The JWT lasting 10 days means the auth call is negligible in the budget; do not re-login per request.

Mapping to the unified model

Gaps and open questions

• Inventory has no location. Everything else on this page is a normal aggregator integration; this one omission is what makes Shiprocket Fulfilment hard to model honestly. If per centre stock is a requirement, it has to come from a panel report or a negotiated file, and that should be established before the connector is scoped.
• No inbound or receipt object. Inbound advice and goods receipt are undocumented, so the inbound leg cannot be automated from public information.
• No warehouse events. Received, putaway, picked, packed, inspected: none of these push or poll.
• Whether fulfilment adds endpoints to an entitled account. The collection is published once for everyone. It is possible that a fulfilment account exposes extra paths not in the public documentation. Unverified, and worth asking directly.
• Contradictory scale figures. 35 versus 42 centres, 19,000 versus 24,000 pincodes, 12 versus 25 channel integrations, all on the same site on the same day. Do not quote any of them without a date and a source.
• Who owns the stock number. The inventory write exists and is live with no sandbox. In a fulfilment account, writing it can desynchronise the warehouse from the storefront. Decide ownership first.
• Fee data. Storage and handling charges are quoted through a calculator and a sales conversation, not an API or a published rate card, so fulfilment economics cannot be reconstructed from the API alone.

Sources

• apidocs.shiprocket.in, the official Shiprocket API documentation, and the underlying collection JSON at https://documenter.gw.postman.com/api/collections/8407119/SzYW1zB2, fetched and walked folder by folder on 2026-09-22 for endpoints, request bodies, parameter descriptions and saved example responses
• fulfillment.shiprocket.in, the Shiprocket Fulfilment overview page, source of the 35 centres, same and next day delivery, D2C, B2B, marketplace and returns offerings
• fulfillment.shiprocket.in/network, source of the 42+ fulfilment centres and 24,000 pincode figures that contradict the overview page
• fulfillment.shiprocket.in/pricing, source of the inbound, outbound, packaging, per order, storage, RTO and removal cost model
• fulfillment.shiprocket.in/channel-integrations, source of the 25+ native integrations claim
• https://wms.shiprocket.in/, checked live on 2026-09-22: HTTP 200, login only single page application, no documentation
• The public Postman index, searched for Shiprocket collections. The only first party one is "Shiprocket API" published by Shiprocket Dev; the rest are third party copies and were not used
• /connectors/shiprocket, this catalogue's page for the aggregator and carrier surface, which carries the order, shipment, tracking, NDR, returns and wallet endpoints in full