eShipz

eShipz is an Indian multi-carrier shipping aggregation platform: one API in front of 450 or more carrier integrations, so a brand writes one shipment-creation call instead of one per courier. It is a software layer, not a carrier, which makes it unusually useful as a connector: a single eShipz account can cover Bluedart, Delhivery, DHL Express, Shiprocket and dozens more, and the tracking feed is already normalised into a common status vocabulary. The full API reference is published as a public Postman collection at apidocs.eshipz.com with request bodies, sample responses and an explicit throttling limit.

At a glance

What it is

eShipz describes itself as an all-in-one logistics automation platform. As of 2026-09-21 its site claims 320 or more brands, 457 or more carrier integrations, a 73 percent reduction in manual operations and a 4.1 out of 5 Capterra rating, with customer logos including Arvind, Snitch, Nalli, Fossil, Homelane, Savex, Flipkart, Lego, Under Armour and US Polo. The GitHub organisation behind it is logiq-labs.

Its own framing of the product is "a single API gateway to pre-shipping, shipping and post-shipping requirements", which maps onto the collection's structure: orders and serviceability before booking, shipment creation and labels at booking, and tracking, NDR, POD, manifests and analytics afterwards. It also carries a SMaRT allocation feature that picks a carrier per shipment from configured rules.

For a commerce database, eShipz is a good target precisely because it is an aggregator of aggregators: its slug field names the underlying carrier (bluedart, dhl_express, shiprocket), so one integration yields carrier-attributed shipment data across a brand's whole courier panel.

API access

• Reference: apidocs.eshipz.com. The underlying Postman collection is public and can be imported directly.
• API keys: the collection's own introduction says "Kindly reach out to us at hello@eshipz.com for your API Keys."
• POST /api/v2/partner-accounts/register exists for partner account registration, so there is a programmatic onboarding path for resellers.
• Base host: the collection uses a variable for the host. Published absolute URLs point at https://app.eshipz.com, and one recommendation endpoint is written in full as https://app.eshipz.com/api/v1/recommendations/serviceability. Some entries show a templated subdomain form, which suggests per-tenant hosts may exist. Confirm your base URL with eShipz rather than assuming app.eshipz.com.
• Versioning is in the path, and both versions of several endpoints are live at once. The collection explicitly marks Tracking v1 as deprecated, Duties Estimator as sunset, and Carrier Performance v1 as deprecated.
• No official SDK is published. The Postman collection is the artefact.

Authentication

1. POST /api/v2/login with Content-Type: application/json and {"email": "...", "password": "..."}.

{
  "email": "login@gmail.com",
  "embed_code": "08debcc4-6b98-413c-a60c-000000000000",
  "remark": "Success!",
  "status": 200,
  "token": "***********************"
}

2. Send the token value on every subsequent call in an X-API-TOKEN header.

curl -X POST "https://app.eshipz.com/api/v1/pincode-serviceability" \
  -H "Content-Type: application/json" \
  -H "X-API-TOKEN: $ESHIPZ_TOKEN" \
  -d '{"origin_zip":"560001","destination_zip":"600001"}'

3. A v1 login also exists at POST /api/v1/login, which additionally sends a fixed X-API-KEY: ESHIPZ header. Use v2.
4. No token lifetime, refresh flow, scope or expiry is documented. Multi-account support is one token per channel_account_id.
5. embed_code in the login response is a separate identifier, presumably for the embeddable tracking page. It is not the API token.

Objects we can read

Orders

• POST /api/v1/orders pushes orders in (see the write section).
• GET /api/v1/orders?per_page=10&page=1&ship_status=shipped lists them, with page-based pagination and a ship-status filter.
• GET /api/v1/orders/{id} fetches one.

Orders carry a store_name from the set woocommerce, magento, magento_1, prestashop, shopify, amazon, other, plus a numeric store_id mapping (shopify is 5, woocommerce 1, magento 2, magento_1 3, prestashop 4, amazon 6). For Shopify and Magento, the platform's own internal order id is mandatory, because eShipz writes tracking details back to the store.

Shipments

GET /api/v1/get-shipments with page, limit, min_date, max_date and filters on awb, order_id and order_source. The documentation also describes sorting and field-level response selection, so you can request only the fields you need.

Shipment creation returns the definitive record:

{
  "data": {
    "created_at": "2022-02-22T05:28:28.506542",
    "customer_reference": "22022022-1",
    "order_id": "EZ83935484",
    "slug": "bluedart",
    "status": "created",
    "tracking_numbers": ["89186510464"],
    "files": {
      "label": {
        "file_type": "pdf",
        "label_meta": {
          "awb": "89186510464",
          "box_count": 1,
          "master_label_count": 1,
          "url": "https://eazyship.s3.ap-south-1.amazonaws.com/eshipz/EZ83935484/89186510464.pdf"
        },
        "paper_size": "PAPER_4X6"
      }
    },
    "rate": {
      "charge_weight": { "unit": "kg", "value": 4.6 },
      "total_charge": { "amount": "", "currency": "INR" },
      "transit_time": null,
      "detailed_charges": []
    }
  },
  "meta": { "code": 200, "details": [], "message": "OK" }
}

order_id here is eShipz's own reference, prefixed EZ, distinct from the customer_reference you supplied and from the carrier AWB in tracking_numbers. Three identifiers, all needed.

Tracking

POST /api/v2/trackings with {"track_id": "..."} returns the full checkpoint history, already normalised:

[
  {
    "checkpoints": [
      {
        "city": "Delhi_shahpurJat (Delhi)",
        "date": "Tue, 28 Jun 2022 13:58:26 GMT",
        "remark": "Delivered to consignee",
        "subtag": "Delivered",
        "tag": "Delivered"
      },
      {
        "city": "Delhi_shahpurJat (Delhi)",
        "date": "Tue, 28 Jun 2022 08:19:44 GMT",
        "remark": "Out for delivery",
        "subtag": "OutForDelivery",
        "tag": "OutForDelivery"
      }
    ]
  }
]

tag is the normalised status, subtag the finer classification, and remark the carrier's raw text. This normalisation across 450 carriers is the main reason to integrate eShipz rather than each courier.

The deprecated v1 form takes {"q_num": "...", "carrier_id": "..."} and returns a richer envelope with delivery_date, expected_delivery_date, order_id, pod_link, slug, tag and tracking_number alongside the checkpoints. Observed tag values across both versions include InTransit, OutForDelivery and Delivered. The complete tag list is not published; derive it empirically and treat unknown tags as in-transit.

To track shipments not booked through eShipz, register them first: POST /api/v2/tracking/register takes a JSON array of registration objects with carrier_id, awb, order_id and optional order, sender, receiver and item detail. The docs note that for NDR to work the carrier must be configured and carrier_id takes a slug plus vendor_id form.

Proof of delivery

POST /api/v1/getPOD with {"awb": "..."}:

{
  "data": {
    "awb": "53420033236",
    "order_reference": "53420033236",
    "url": "https://ezship-track.s3.ap-south-1.amazonaws.com/eshipz/53420033236/53420033236_1659439324_pod.png"
  },
  "meta": { "code": 200, "message": "OK", "status": "success" }
}

POD is an image URL on S3. Fetch and store it rather than storing the link.

Serviceability and rates

• POST /api/v1/pincode-serviceability with origin_zip and destination_zip:

{
  "data": {
    "cod_delivery": true,
    "destination_zip": "700001",
    "is_mps_delivery": false,
    "origin_zip": "560001",
    "prepaid_delivery": true
  },
  "remarks": "Success",
  "status": "success"
}

Note the sample response echoes a different destination_zip from the request, which looks like a documentation slip. is_mps_delivery is multi-piece shipment support.

• POST /api/v2/services returns service availability.
• POST /api/v1/recommendations/serviceability is the SMaRT recommendation endpoint that suggests a carrier.
• GET /api/v1/services-master lists vendor services.

Analytics

• POST /prediction/predicted-sla/v1 predicts an estimated delivery date.
• GET /performance_score/cps_scores/v2 returns carrier performance scores. The v1 form under /scoring/carrier-performance/v1 is deprecated.

These are unusual and worth having: a carrier performance score per lane is exactly the kind of derived metric a commerce database wants and rarely gets from a carrier directly.

Locations and settings

GET /api/v1/warehouses/receiver_address returns warehouses, and GET /api/v1/package-settings returns dispatch package settings. GET /api/v1/getCountryCodes and GET /api/v1/getProvinceCodes/{country} are reference lookups.

Products, listings, inventory, settlements

Not applicable, this is a carrier aggregator. None of these objects exist. Item detail travels on orders and shipments as items[] or item_details[] with description, quantity, sku, hs_code, weight, dimensions and value.

Writing back: listings, price and stock

Not applicable, this is a carrier aggregator. eShipz holds no catalogue, no channel price and no sellable stock, so there is nothing to write back in the listings sense.

The write surface covers the whole shipment lifecycle:

Shipment creation body, trimmed:

{
  "billing": { "paid_by": "shipper" },
  "vendor_id": "9212052189",
  "description": "BlueDart",
  "slug": "bluedart",
  "purpose": "commercial",
  "order_source": "manual",
  "parcel_contents": "test bookings",
  "is_document": false,
  "service_type": "eTailPrePaidAir",
  "charged_weight": { "unit": "KG", "value": 67 },
  "customer_reference": "22022022-1",
  "invoice_number": "123",
  "invoice_date": "15/02/2022",
  "is_cod": false,
  "collect_on_delivery": { "amount": 0, "currency": "INR" },
  "shipment": {
    "ship_from": { "contact_name": "Test", "street1": "...", "city": "Bangalore", "state": "KA", "postal_code": "560011", "phone": "9999999999", "tax_id": "29AAHCP6046M1ZT", "country": "IN", "type": "residential" },
    "ship_to": { "contact_name": "Test Receiver", "street1": "...", "city": "Mumbai", "state": "MH", "postal_code": "400011", "phone": "9999999999", "country": "IN", "type": "business" },
    "return_to": { "contact_name": "Test", "street1": "..." }
  }
}

vendor_id and service_type are both account-specific: the docs point at app.eshipz.com/integrations/shipper-accounts/list to look them up. That means a connector needs a per-account mapping table of carrier slug to vendor id to service type, maintained from the panel, before it can book anything. type on an address takes residential or business, which affects rating with several carriers. what3words, lat and lng are accepted on addresses.

Pickup is a separate explicit call: POST /api/v1/pickup with vendor_id, pick_datetime, order_id as an array and slug. Cancellation also takes an array: {"order_id": ["EZ26828"]}.

NDR is an array of action objects:

[
  {
    "waybill": "53384...",
    "slug": "bluedart",
    "action": "RE-ATTEMPT",
    "comments": "",
    "action_data": { "deferred_date": 1677689880000 }
  }
]

Documented actions are RE-ATTEMPT, an edit-details variant and an RTO variant, all on the same endpoint. deferred_date is Unix epoch milliseconds. An NPR group covers the same pattern for pickup failures.

Webhooks and notifications

Tracking updates are pushed to an endpoint you define. Two payload versions are published.

The v2 body:

{
  "order_id": "C1508262E78B7",
  "tracking_status": "Delivered",
  "tracking_sub_status": "Delivered",
  "tracking_checkpoint_datetime": "2026-08-24T15:33:00",
  "tracking_number": "90632746960",
  "tracking_link": "https://track.eshipz.com/track?awb=90632746960",
  "tracking_msg": "SHIPMENT DELIVERED  at 2026-08-24T15:33:00",
  "carrier": "BLUEDART",
  "slug": "bluedart",
  "eshipz_ref_id": "EZXXXXXXXXXX"
}

v2 adds tracking_sub_status and tracking_checkpoint_datetime over v1. Use v2: without the checkpoint timestamp you cannot order events correctly when callbacks arrive out of sequence.

Registration of the callback URL is done with eShipz rather than through a documented subscribe endpoint. Shipments not booked through eShipz must be registered via POST /api/v2/tracking/register before they will generate callbacks.

Rate limits and pagination

The collection publishes one figure, in its response-codes section: 300 requests per 2 minutes, with HTTP 429 returned when it is breached. That works out to 2.5 requests per second sustained. No per-endpoint variation, no quota headers and no burst allowance are documented.

HTTP semantics are conventional: 2xx success, 400 for a bad request or wrong date format, 401 unauthenticated, 403 unauthorised, 404 not found, 429 throttled, and 500, 502, 503 or 504 for server errors.

Pagination:

Tracking and POD are keyed by identifier, not paginated.

Practical cadence: tracking webhooks as the primary feed; a nightly GET /api/v1/get-shipments sweep over a rolling three-day window for reconciliation; POST /api/v1/pincode-serviceability cached per origin and destination pair; carrier performance scores pulled weekly.

Mapping to the unified model

Gaps and open questions

• The base host is templated in the collection. Confirm whether it is app.eshipz.com for all customers or per-tenant.
• No sandbox is documented. Ask whether one exists before testing shipment creation, since a successful call books a real shipment.
• Token lifetime, expiry and rotation are undocumented.
• No webhook signature, retry policy or timeout is published.
• The complete tracking tag and subtag vocabulary is not published. Only InTransit, OutForDelivery and Delivered appear in samples.
• vendor_id and service_type must be looked up per account in the panel, with no documented endpoint to enumerate them beyond GET /api/v1/services-master. Confirm that endpoint returns enough to build the mapping automatically.
• The single published rate limit, 300 requests per 2 minutes, is account-wide as far as the docs say. Confirm whether it is per token or per endpoint.
• Several endpoints are marked deprecated or sunset (Tracking v1, Duties Estimator, Carrier Performance v1) with no removal dates.
• No COD remittance or settlement reporting appears anywhere, despite COD being fully modelled on shipments.
• The B2B, SMaRT warehousing automation and freight audit groups named in the introduction are thinner in the collection than the introduction implies. Ask for the B2B reference separately if that lane matters.

Sources

• eShipz APIs, published Postman collection, read 2026-09-21. The collection JSON was read directly for endpoints, request bodies, sample responses, the throttling limit and the response-code table.
• eShipz homepage, read 2026-09-21. Scale claims: 320 or more brands, 457 or more carrier integrations, 4.1 out of 5 Capterra, customer logos.
• Host probing on 2026-09-21: docs.eshipz.com, api.eshipz.com, doc.eshipz.com and developer.eshipz.com do not resolve. app.eshipz.com redirects to a login page. The documentation host is apidocs.eshipz.com.
• github.com/logiq-labs, the GitHub organisation identified in search results as eShipz. No public SDK found there.