intelligent.pageDocs

Delhivery WMS

Delhivery Fulfilment and WMS: 7 Mn sq ft of multi-tenant warehouses with no public inventory or inbound API, integration agreed per client contract.

Delhivery sells two quite different things to the same brand. One is parcel transport, which has a genuinely public API and is documented at /connectors/delhivery. The other is fulfilment: Delhivery stores your stock in its own multi-tenant fulfilment centres, receives your inbound consignments, picks and packs each order and hands it to its own parcel network. That second product is what this page is about, and it has no public API. Delhivery publishes a developer portal, and everything on it is transportation. There is no documented endpoint for an inbound advice, for stock on hand at a fulfilment centre, for releasing an order to be picked, or for a storage or handling invoice. This page records exactly what was checked, what the integration actually looks like in practice, and what to demand in writing before a brand commits stock to a Delhivery warehouse.

At a glance

Note

Do not confuse the Client Warehouse API on the transport side with warehouse management. POST /api/backend/clientwarehouse/create/ registers a pickup address so a shipment can be manifested against it. It creates an address record, not a stock location, and it returns nothing about inventory. See /connectors/delhivery for its fields.

What it is

Delhivery Private Limited, listed on the NSE and BSE since May 2022, runs the largest integrated logistics network in India. Warehousing is one of its published service lines, sold as "Warehousing" on the corporate site and as "Fulfilment service" in its own case studies. Delhivery's own figure, on a page whose operational metrics are dated May 2026, is more than 7 million square feet of multi-tenant warehousing infrastructure, distributed across India so that a brand can hold stock closer to demand and trade storage cost against delivery speed.

The proposition is that the fulfilment centres are operated on Delhivery's own software and are already wired into its parcel, freight and cross border networks, so an order picked in a Delhivery warehouse ships on a Delhivery waybill without a second integration. Delhivery describes the same warehouse management system as multi-location and multi-tenant, and integrated with "all major partners and demand channels", which is the vendor's way of saying that channel integration is something its team configures rather than something you call.

This is a 3PL, not a marketplace. In the unified model a Delhivery fulfilment centre is a locations row of type fulfilment_centre, it is the source of inventory rows for the SKUs held there, it sets fulfilment_type to 3pl on the orders it ships, and it produces shipments and inbound returns receipts. It never produces listings.

Three surfaces, only one of them public

API access

For fulfilment there is no route to credentials that does not go through a commercial conversation. What was checked on 2026-09-22:

  1. The public Express reference publishes a machine readable index at https://delhivery-express-api-doc.readme.io/llms.txt. Every entry in it was read. The complete list is pincode serviceability, bulk and single waybill fetch, order creation and manifestation, order tracking, tracking push webhook, edit order, cancel order, invoice and shipping charge, packing slip, pickup request creation, client warehouse create and edit, asynchronous NDR package action, and plugin guides for Magento, OpenCart, WooCommerce and Shopify. There is no inventory, stock, inbound, ASN, GRN, putaway, cycle count, pick, pack or storage invoice entry.
  2. The newer portal at one.delhivery.com/developer-portal was fetched and its application bundle parsed for its route table. It carries two document sets, document/b2c/detail/* and document/b2b/detail/*. The B2C set is shipment and pickup oriented; the B2B set is part truckload. The words inventory, ASN, inbound, GRN, putaway and stock do not occur anywhere in the bundle. The portal's own overview page opens with "Welcome to the Delhivery B2C Transportation API Documentation", which is the honest summary of its scope.
  3. getos1.com/developer points at docs.getos1.com, which now answers 403 from object storage, so those docs have been withdrawn. An archived copy from December 2024 was read. The OS1 platform services are apps and solutions, authentication and authorization, file management, secure data storage, messaging, notification, dispatch, participant, container, workflow, state machine, movement tracking, maps, entity, location, order and work order management, scheduler and webhooks. There is no warehouse or inventory service. OS1 is a dispatch and transport platform, not a WMS.
  4. No first party OpenAPI file, Postman collection or SDK for Delhivery fulfilment was found in public code search.

So the practical answer for an engineer: you cannot build a Delhivery fulfilment connector from documentation. You build it from a specification the Delhivery integration team hands over after the warehousing contract is signed, and you should treat that specification as the deliverable to chase.

Authentication

Not published for the fulfilment surface. Do not design a credential store around a guess.

What is known, and worth carrying into the onboarding call as the likely starting point, is the transport model: a client name, a user id and a long lived API token, sent as Authorization: Token <api-token> on every request, with no expiry and no refresh. That token is issued per client account, and multi brand or multi entity setups get one client account each rather than one token with several scopes.

  the transport API credential model, documented, for reference only
curl -s "https://track.delhivery.com/api/v1/packages/json/?waybill=12345678901" \
  -H "Authorization: Token 0000000000000000000000000000000000000000"

Questions to get answered in writing during onboarding, because each one changes the connector:

  • is the fulfilment interface the same client token, or a separate credential
  • is it REST, SFTP flat file, or a shared spreadsheet operated by the account team
  • what is the base URL, and is there a UAT environment with a separate credential
  • does a token expire, and who rotates it

Objects we can read

Orders

No published endpoint. An order released to a Delhivery fulfilment centre becomes visible to you only once it is manifested as a package, at which point it is readable through the transport tracking API on its waybill. There is no documented way to read the pre-shipment states that matter in a warehouse, allocated, picked, packed, awaiting pickup, so order to ship turnaround inside the warehouse cannot be measured from public APIs.

Inventory

No published endpoint, and this is the most significant gap on the page. Stock on hand by SKU by fulfilment centre, reserved quantity, quarantine and damaged buckets, inbound in transit and cycle count adjustments are all visible in the WMS panel and none of them are documented. Ask for a stock on hand extract, its cadence, and whether it is a snapshot or a movements ledger. A snapshot only feed makes reconciliation of shrinkage impossible.

Shipments and tracking

Fully readable, on the transport API, because a fulfilment order ships as an ordinary Delhivery package. Endpoints, sample responses, status codes and the scan push webhook are all on /connectors/delhivery. This is the one object where the fulfilment connector needs nothing extra.

Returns and cancellations

Partially readable. A customer return moves as a reverse pickup package, and reverse pickup status is readable on the same tracking API, including the Pickup package type and the RVP quality check flow described in the public reference. What is not readable is the warehouse side of the return: what was received, what passed inspection, what went back to sellable stock and what was written off. That sits in the WMS.

Payments and settlements

No published endpoint for storage and handling invoices. COD remittance has no API on the transport side either. Fulfilment fees arrive as invoices, so plan on a document or spreadsheet ingestion path rather than an API for the settlements table, and expect the fee lines to be storage by volume or pallet, inbound handling, pick and pack per order or per unit, packaging material, and returns handling.

Locations

Readable only as address records, and only the pickup addresses you registered yourself. There is no endpoint that enumerates the Delhivery fulfilment centres your stock sits in, so seed locations from the contract annexure and keep the Delhivery facility code that appears on manifests as channel_location_id.

Writing back: listings, price and stock

Delhivery is not a sales channel, so there is nothing to list or price. The two writes that a fulfilment connector needs are both undocumented:

  • Inbound advice, telling the warehouse that a consignment of known SKUs and quantities is arriving so it can be received against an expectation rather than blind. Ask whether this is an API call, a file drop, or an email to the site.
  • Outbound order release, pushing a customer order into the warehouse to be picked. For brands on Shopify, Magento, WooCommerce or a marketplace, Delhivery's stated position is that its WMS is already integrated with the major demand channels, which means the release path is usually Delhivery pulling from your storefront or order management system, not you pushing to Delhivery. That is a meaningful design difference: your connector may end up observing a lane it does not control.

The manual route, which always exists, is the WMS panel at wms.delhivery.com: upload an inbound file, download a stock report, action returns. Treat panel exports as the fallback data source and assume they are CSV with unstable column order.

Webhooks and notifications

None published for fulfilment. There is no event for goods received, stock adjusted, order picked or return inspected.

What you can subscribe to is the transport scan push, which Delhivery configures for you against an HTTPS endpoint you supply, with no self serve subscription endpoint and no signature scheme. Delhivery quotes five to six working days to deploy it. Because it fires on every scan, it is enough to drive shipments and their events[] but tells you nothing about the warehouse.

Polling plan in the absence of anything better:

Rate limits and pagination

Not published for fulfilment. On the transport side Delhivery publishes no numeric rate limit either; the practical guidance on /connectors/delhivery is to keep tracking pulls batched by waybill list and to treat the scan push as the primary signal. When you negotiate the fulfilment extract, agree a file cadence rather than a request rate, because a nightly file is far likelier than a paginated endpoint.

Mapping to the unified model

Gaps and open questions

  • The entire fulfilment interface. No endpoint, no field list, no authentication model is public. Everything in this page's read and write sections that concerns the warehouse is marked not published, and that should be taken literally rather than as a gap in the research.
  • Whether an API exists at all for clients. It is plausible that large fulfilment clients receive REST documentation under NDA and that smaller ones get files. Nothing public distinguishes these, so ask.
  • Direction of the order release lane. Delhivery states its WMS is integrated with major demand channels. If Delhivery pulls orders from the storefront directly, your connector observes rather than drives, and duplicate order creation is a real risk if you also manifest shipments yourself.
  • Whether the transport token authorises anything on the fulfilment side. Untested, and not worth guessing at in code.
  • OS1's future. The OS1 documentation host now returns 403 and the last readable copy is from December 2024. Do not plan on OS1 as the eventual public API for warehousing; it has no warehouse module in any version that was published.
  • Scale figures. The 7 million square feet figure is from Delhivery's own marketing page, whose metrics footer is dated May 2026. Fulfilment centre counts, SKU capacity and per site throughput are not published; take current numbers from the annual report.

Sources