Shipease

ShipEase, an Indian courier aggregator: REST API with the key in the request body, covering order create, ship, cancel, label, tracking and NDR.

ShipEase (shipease.in) is an Indian courier aggregator: a seller pushes orders in, ShipEase allocates a courier partner, returns a waybill and label, and reports tracking and NDR back. There is no public developer portal, but a Postman collection named "Shipease API" is published and reachable without a login, and every request in it points at www.staging.shipease.in, ShipEase's own staging host. That collection is the basis of this page. It gives the endpoint list, the request bodies and a few sample responses, but no authentication guide, no production base URL, no webhook mechanism and no rate limits.

At a glance

What it is

ShipEase is a courier aggregator serving Indian e-commerce sellers, competing with Shiprocket, NimbusPost, iThink Logistics and Shyplite. The sample data in its own API collection uses Surat, Gujarat addresses, which is consistent with a western-India operation.

Beyond that, very little could be verified. www.shipease.in returns a JavaScript-only shell to automated fetchers and returned HTTP 403 to some requests, so the company's own claims about courier partners, pincode coverage and seller count could not be read on 2026-09-21. Treat any figure you see quoted elsewhere as unverified.

Note

"ShipEase" is an overloaded name. There is an unrelated ServiceNow shipping application called ShipEase at shipease.io and store.servicenow.com, and an unrelated shipeasy.cloud. This page is about the Indian courier aggregator at shipease.in only. Check the host before you trust a search result.

API access

No developer console or self-serve key issuance was found. The API key is issued by ShipEase to the seller account, in the usual Indian aggregator pattern.
The only reference is a public Postman collection titled "Shipease API" (publisher id 12909554, published id Tz5wXaSR). A second Postman workspace, postman.com/divigo-india/workspace/shipease, contains a collection named "Integrations" with no description.
Base URL in every published request: https://www.staging.shipease.in/api. The production base URL is not published. The obvious guess is https://www.shipease.in/api, but do not assume it: ask ShipEase, because getting this wrong means booking real shipments against staging or the reverse.
No official SDK in any language was found.
No API version number appears anywhere. There is no /v1 path segment and no version header, so treat the surface as unversioned and expect breaking changes without notice.

Authentication

There is no token exchange, no OAuth and no expiry. A single long-lived API key authenticates every call.

ShipEase issues an API key to the seller account.
For every POST endpoint, include the key as a top-level ApiKey field in the JSON body alongside the request data.
For the label download endpoint, pass the key as an api_key query string parameter instead.
No refresh, scopes or roles are documented. Multi-account support is one key per channel_account_id.

curl -X POST "https://www.staging.shipease.in/api/order-track" \
  -H "Content-Type: application/json" \
  -d '{"ApiKey":"'"$SHIPEASE_API_KEY"'","AWBNumber":"CC0004926361"}'

Warning

Two things to handle carefully. First, the key travels in the request body and, for label download, in the URL query string, so it will land in any access log, proxy log or browser history that sees the request. Never call the label endpoint from a browser. Second, the published collection ships a real-looking 40 character key in every sample body; treat it as compromised and never reuse a key you found in a public collection.

Objects we can read

Orders

There is no order list or order search endpoint in the published collection. Orders can be created and cancelled, and looked up only through the tracking endpoints by order id or AWB. If you need the full order history, plan on keeping your own record of what you pushed in, or ask ShipEase whether a listing endpoint exists that is not in the collection.

Shipments and tracking

Four tracking endpoints, all POST:

Sample responses are not published for any of the four. The event vocabulary, the field names in the event list, the timestamp format and the delivered and RTO status values are all unknown. This is the single biggest gap for a connector, because the status mapping is the thing you must get right.

Returns and cancellations

Reverse pickup: POST /api/reverse-order-create, the same body shape as order create with OrderType set to reverse.
Cancellation: POST /api/order-cancel with ApiKey and OrderID.

{
  "status": true,
  "message": "Order cancelled successfully."
}

NDR

POST /api/ndr-order is both the read and write surface for non-delivery. The documented body:

{
  "ApiKey": "...",
  "awbNumber": "CC0004926361",
  "action": "reattempt",
  "reattemptDate": "15/04/2022",
  "comments": ""
}

Note the field casing changes here: awbNumber in lower camel case, against AWBNumber in the tracking endpoints and OrderID in cancel. The casing is inconsistent across the surface, so do not build a generic serialiser that assumes one convention. Permitted values for action beyond reattempt are not published. reattemptDate is dd/mm/yyyy.

Serviceability

POST /api/serviceable-pincode takes only ApiKey and no other parameter, which implies it returns the full serviceable pincode list for the account rather than answering a per-pincode question. The response is not published. Fetch it once a day and cache it, rather than calling it per order.

Products, listings, inventory, customers, settlements

Not applicable, this is a carrier. None of these objects exist in the API. Consignee name, both addresses and the contact number are carried on the order create request and are PII.

Writing back: listings, price and stock

Not applicable, this is a carrier. ShipEase holds no catalogue, price or stock, so there is nothing to write back in the listings sense.

The write path is the shipment lifecycle:

Order creation is a two-step model: create the order, then ship it. order-create-with-pickup collapses the two where a pickup should be raised at the same time.

The order create body, trimmed to one order and one product:

{
  "ApiKey": "...",
  "OrderDetails": [
    {
      "PaymentType": "prepaid",
      "OrderType": "forward",
      "CustomerName": "Vivek",
      "OrderNumber": "1025",
      "Addresses": {
        "BilingAddress": {
          "AddressLine1": "l.h.road surat",
          "AddressLine2": "KAPODRA",
          "City": "surat",
          "State": "Gujrat",
          "Country": "India",
          "Pincode": "395006",
          "ContactCode": "91",
          "Contact": "7965464213"
        },
        "ShippingAddress": { "AddressLine1": "...", "Pincode": "395006", "ContactCode": "91", "Contact": "7965464213" },
        "PickupAddress": {
          "WarehouseName": "Kapodra",
          "ContactName": "person",
          "AddressLine1": "l.h.road surat",
          "City": "surat",
          "State": "Gujrat",
          "Country": "India",
          "Pincode": "395006",
          "ContactCode": "91",
          "Contact": "7923464213"
        }
      },
      "Weight": "0.9",
      "Length": "11",
      "Breadth": "12",
      "Height": "13",
      "ProductDetails": [
        { "Name": "xyz", "SKU": "xrv_dr", "QTY": "12" }
      ],
      "InvoiceAmount": "1220",
      "EwayBill": null,
      "ShippingCharge": "12",
      "CodCharge": "15",
      "Discount": "20"
    }
  ]
}

Points worth noting: BilingAddress is spelled that way in the API and must be sent as spelled. Every numeric value, including weight, dimensions and money, is a string. PaymentType takes prepaid and cod in lower case. The pickup warehouse is supplied inline on every order rather than referenced by an id. ProductDetails[] is the only line-item structure and carries name, SKU and quantity but no per-item price.

The create response is an array, one entry per order in the request:

[
  { "order_id": 13971, "status": true, "message": "Order created successfully." },
  { "order_id": 13972, "status": true, "message": "Order created successfully." }
]

There is no documented per-order limit on how many entries OrderDetails[] can hold.

Webhooks and notifications

None published. The collection has no webhook registration endpoint and no callback documentation.

Until ShipEase confirms otherwise, poll:

Use the bulk tracking endpoints, not the single ones. Batch AWBs into one comma-separated string per call to keep call volume down.
Every 30 to 60 minutes for shipments not in a terminal state is the normal fit for Indian last-mile scan frequency.
Poll POST /api/ndr-order behaviour is unclear, since the documented body is an action rather than a query. Ask ShipEase how to list open NDRs, because there is no obvious read path for them.
Refresh POST /api/serviceable-pincode once a day.

Rate limits and pagination

Nothing is published. No rate limit numbers, no quota headers, no pagination model, and no documented cap on the size of a bulk request. Assume a conservative limit, throttle client-side, and keep the comma-separated bulk strings to a sensible length (a few hundred identifiers at most) until ShipEase states a number.

Mapping to the unified model

Gaps and open questions

The production base URL is not published. Every documented request targets www.staging.shipease.in. Confirm the live host before writing any code.
No tracking sample responses. The status vocabulary, event schema and delivered and RTO values are unknown, so the status mapping cannot be designed yet. This must come from ShipEase.
Identifier confusion in order-ship. POST /api/order-create returns a numeric order_id such as 13971, and POST /api/order-cancel is documented with "OrderID": "13971", but POST /api/order-ship and the manifest endpoints are documented with "OrderID": "CC0004926361", which matches the AWB format used by the tracking endpoints. Either the sample is wrong or order-ship takes a different identifier. Resolve this before building.
No way to list open NDRs is documented, only a way to act on one.
No webhooks are documented, which makes tracking a polling job of unknown cost.
The company itself could not be verified. shipease.in blocks automated fetches, so courier partners, coverage and scale are unknown.
No versioning. Nothing in the URL or headers identifies an API version.

Sources

Shipease API, published Postman collection, read 2026-09-21. The collection JSON was read directly for endpoints, request bodies and the few published sample responses. Every request targets https://www.staging.shipease.in/api.
https://www.postman.com/divigo-india/workspace/shipease/collection/24974480-c40ed7b6-3121-4e49-916b-76c7835d58cd, a second public collection named "Integrations" with no description, noted 2026-09-21 but not readable without JavaScript.
https://www.shipease.in/, attempted 2026-09-21. Returns HTTP 403 to some clients and a JavaScript-only shell to others; no readable content, no developer links.
Host probing of docs.shipease.in, api.shipease.in, app.shipease.in, developer.shipease.in, 2026-09-21: none resolve.