iThink Logistics

iThink Logistics is an Indian courier aggregator based in Mumbai. A seller pushes orders in, iThink's allocation engine picks a courier partner (Delhivery, Bluedart, Xpressbees, Ecom Express, Ekart, FedEx and others), and returns a waybill, a label and a tracking feed. Its documentation is genuinely public: docs.ithinklogistics.com serves a full reference for API v3 with request and response samples and code in five languages, no login required. That makes iThink one of the cheapest Indian carrier connectors to build, and the reference is detailed enough to design the whole shipment lifecycle from it.

At a glance

What it is

iThink Logistics is a courier aggregator and third-party logistics provider for Indian e-commerce sellers. As of 2026-09-21 its own site claims 37,000 or more customers, 40,000 or more daily shipments, coverage of 29,000 or more pincodes in India and international shipping to 180 countries. It positions itself for small sellers, social sellers, marketplace sellers and omnichannel sellers, with no platform integration fee, an allocation engine that picks the cheapest or fastest carrier, an automated NDR reattempt workflow, and weekly or next-day COD remittance.

It is an aggregator, not a carrier with its own fleet. The logistics parameter in the order create call names the underlying partners directly: delhivery, bluedart, xpressbees, ecom, ekart, with fedex appearing in the code samples. Reverse shipments are restricted to Delhivery, Bluedart and Xpressbees.

The documentation site is built by Depasser Infotech and carries a 2026 copyright, so it is actively maintained.

API access

• The reference is at docs.ithinklogistics.com with no login wall. A Postman collection download is offered from the same page. Separate Domestic and International tabs exist; this page covers Domestic v3.
• Three versions are published side by side (/index/1, /index/2, /index/3). v3 is the current one and is the only one to build against. No deprecation dates are stated for v1 or v2, which is itself a small risk: nothing tells you when they will be switched off.
• Base URLs:

• Credentials (access_token, secret_key) are issued by the iThink Logistics team, in the words of the docs: "You will get this from IThink Logistics team."
• No official SDK is published, but the reference ships working request samples in PHP, Python, Java, .NET and Ruby for every endpoint.

Authentication

There is no token exchange and no expiry. Two long-lived secrets are sent on every call, inside the body.

1. iThink issues access_token and secret_key for the seller account.
2. Every request is a POST with Content-Type: application/json and a body of the form {"data": { ... , "access_token": "...", "secret_key": "..." }}.
3. No scopes, roles or refresh are documented. Multi-account support is one access_token and secret_key pair per channel_account_id.

curl -X POST "https://my.ithinklogistics.com/api_v3/pincode/check.json" \
  -H "Content-Type: application/json" \
  -d '{"data":{"pincode":"400067","access_token":"'"$ITL_TOKEN"'","secret_key":"'"$ITL_SECRET"'"}}'

Objects we can read

Orders and order items

POST /api_v3/order/get_details.json returns full order detail, including the product lines, for a list of AWBs or for a date range.

The response is an object keyed by AWB. Trimmed:

{
  "status": "success",
  "status_code": 200,
  "data": {
    "4289479049381": {
      "awb_no": "12345678984394",
      "order": "9999_85155972",
      "sub_order": "",
      "order_date": "2022-04-10 08:57:27",
      "awb_created_date": "2022-04-11 10:50:27",
      "total_amount": "90.00",
      "customer_name": "Anjulika N",
      "customer_address": "gurugram palace, mumbai,",
      "customer_pincode": "100039",
      "customer_city": "Mumbai",
      "customer_state": "Maharashtra",
      "customer_country": "India",
      "customer_email": "anas@gmail.com",
      "is_billing_same_as_shipping": "Yes"
    }
  }
}

Customer name, both addresses, phone and email are PII.

Pagination is by date window and AWB list, not by cursor or page. The documented cap is 500 AWB details per request, so a backfill means walking the date range in slices.

Products and listings, inventory

Not applicable, this is a carrier. Product data exists only as line items on an order (product_name, product_sku, product_quantity, product_price, product_tax_rate, product_hsn_code, product_discount, product_img_url), capped at 40 products per shipment.

Shipments and tracking

POST /api_v3/order/track.json takes awb_number_list, a maximum of 10 AWBs per request.

{
  "status_code": 200,
  "data": {
    "1369010033902": {
      "message": "success",
      "awb_no": "1369010033902",
      "logistic": "Delhivery",
      "order_type": "forward",
      "cancel_status": "Approved",
      "current_status": "In Transit",
      "current_status_code": "UD",
      "ofd_count": "0",
      "return_tracking_no": "",
      "expected_delivery_date": "2017-06-07",
      "promise_delivery_date": "2017-06-07",
      "last_scan_details": {
        "status": "Undelivered",
        "status_code": "UD",
        "status_date_time": "2017-06-07 18:11:26",
        "scan_location": "Surat_Pandesra_Gateway (Gujarat)",
        "remark": "CONSIGNEE NOT AVAILABLE",
        "reason": "customer not available at the time of delivery"
      }
    }
  }
}

cancel_status takes Pending, Approved, Request Rejected or Refunded. ofd_count is the number of out-for-delivery attempts, which is the cheapest NDR signal available.

The status vocabulary is published in full. current_status_code collapses many statuses into a few codes, so store current_status as well, otherwise you cannot tell "Picked Up" from "Delayed":

Note that DL is reused for a forward delivery and for an RTO delivery, which are opposite business outcomes. Always branch on current_status, never on current_status_code alone.

The change feed is POST /api_v3/order/get_awb.json, which takes start_date_time and end_date_time and returns the AWBs whose tracking status changed in that window. The window cannot exceed 30 minutes.

{
  "status": "success",
  "Awb list": [ { "airway_bill_no": "7801XXXXXXXX" } ]
}

The response key is the literal string Awb list, with a space and mixed case. Handle it as such.

Rates and serviceability

• POST /api_v3/rate/check.json with from_pincode, to_pincode, dimensions in cm, shipping_weight_kg (documented maximum 10 kg), order_type (forward or reverse), payment_method (Prepaid or COD) and product_mrp. Each dimension is capped at 1000 cm. It returns one entry per courier with logistic_name, prepaid, cod, pickup, rev_pickup, rate, logistics_zone and delivery_tat, plus a top-level zone and expected_delivery_date.
• POST /api_v3/rate/... also has a zone-wise variant, documented as Get Rate Zone Wise.
• POST /api_v3/pincode/check.json takes a single pincode and returns a per-courier serviceability map:

{
  "status": "success",
  "status_code": 200,
  "data": {
    "400067": {
      "delhivery": {
        "prepaid": "Y",
        "cod": "Y",
        "pickup": "Y",
        "district": "MUMBAI",
        "state_code": "MH",
        "sort_code": "MUM/MAL"
      }
    }
  }
}

This is a per-pincode question, not a bulk list, so cache results rather than calling it per order.

Returns and cancellations

• POST /api_v3/order/cancel.json takes awb_numbers as a comma-separated string, maximum 100 per request.
• Reverse pickups are ordinary orders created with order_type: "reverse", restricted to Delhivery, Bluedart and Xpressbees, and prepaid only.
• RTO shows up in tracking as the RT code family, and return_tracking_no carries the return waybill when one exists.

NDR

POST /api_v3/ndr/add-reattempt-rto.json is the action endpoint. Body fields: awb_numbers, ndr_action (1 for reattempt, 2 for RTO), reattempt_date as Y-m-d, reattempt_time as H:i:s, reattempt_mobile_number, reattempt_address, reattempt_address_type (1 home, 2 office), and rto_remark, which is mandatory when the action is RTO.

There is no documented endpoint that lists open NDRs. Detect them from tracking instead: current_status of Undelivered plus last_scan_details.reason and a rising ofd_count.

Payments and settlements

POST /api_v3/remittance/get.json takes a remittance_date and returns the COD remittance summary:

{
  "status": "success",
  "status_code": 200,
  "message": "Data found.",
  "data": [
    {
      "remittance_id": "1",
      "remittance_date": "20 Apr 2021",
      "cod_generated": "0.00",
      "bill_adjusted": "0.00",
      "refund_adjusted": "0.00",
      "transaction_charges": "0.00",
      "transaction_gst_charges": "0.00",
      "wallet_amount": "0.00",
      "advance_hold": "0.00",
      "cod_remitted": "0.00"
    }
  ]
}

POST /api_v3/remittance/...details gives the per-shipment breakdown behind a remittance_id. This pair is unusual among Indian aggregators and is the most valuable non-shipment object on this API: it lets settlements be reconciled without a panel export.

Locations

POST /api_v3/warehouse/get.json returns registered pickup warehouses, optionally filtered by warehouse_id.

{
  "status": "success",
  "status_code": 200,
  "data": [
    {
      "id": "2474",
      "company_name": "ITL",
      "mobile": "+91 9876543210",
      "address1": "104, Shreeji Sharan",
      "address2": "Kandivali West",
      "pincode": "Kandivali West",
      "city_name": "Mumbai",
      "state_name": "Maharashtra",
      "country_name": "India",
      "status": "approved"
    }
  ]
}

The pincode value in the published sample holds a locality name rather than a pincode, which looks like a documentation error. Verify against a live response. POST /api_v3/warehouse/add.json registers a new one, and status shows whether iThink has approved it, so a newly added warehouse is not immediately usable.

Customers

No customer object. Consignee details are attributes of an order.

Writing back: listings, price and stock

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

The write surface is the shipment lifecycle:

Order create is the main call. The body nests data.shipments[], with pickup_address_id, return_address_id, access_token, secret_key, logistics, s_type and order_type at the data level. Key fields: order (your order number), order_date, total_amount, the consignee block (name, add, add2, add3, pin, city, state, country, phone, alt_phone, email), a parallel billing block when is_billing_same_as_shipping is no, products[], shipment_length, shipment_width, shipment_height, weight, the money fields (shipping_charges, giftwrap_charges, transaction_charges, total_discount, first_attemp_discount, cod_charges, advance_amount, cod_amount), payment_mode (cod or Prepaid, defaulting to COD when absent), eway_bill_number, gst_number and what3words.

Two traps in the published sample. first_attemp_discount is spelled that way in the API. The sample comments "weight" : "400" as being "in Kg" while dimensions are in cm; 400 kg for a t-shirt parcel is clearly wrong, so confirm the weight unit with iThink before sending anything.

The create response is keyed by index, one entry per shipment sent:

{
  "status": "success",
  "status_code": 200,
  "html_message": "",
  "data": {
    "1": {
      "status": "Success",
      "remark": "",
      "waybill": "1369010531020",
      "refnum": "GK0034",
      "logistic_name": "delhivery",
      "tracking_url": "https://ithinklogistics.co.in/postship/tracking/1369010531020"
    }
  }
}

The label call returns a URL rather than bytes: {"status":"success","status_code":200,"file_name":"https://.../uploads/shipping/b04f3619fc54612329b089c073a7d812.pdf"}. Fetch and store the PDF, do not store the URL.

Pickup is not a separate call. Handover is implied by pickup_address_id on the order.

Webhooks and notifications

No webhook registration endpoint is documented in v3. ClickPost's carrier matrix marks iThink Logistics (partner id 170) as supporting order creation, cancellation, tracking by polling and tracking by webhook, with labels generated by the carrier; that webhook column describes what ClickPost has arranged, not something a seller can self-register through the public API. ClickPost also marks POD and NDR as unsupported for iThink, which contradicts iThink's own published NDR endpoint. Treat the aggregator matrix as a hint, not a specification.

The intended polling pattern is a two-step loop, and it is efficient:

1. Every 20 to 25 minutes, call POST /api_v3/order/get_awb.json with a window strictly under 30 minutes. It returns only the AWBs whose tracking changed.
2. Call POST /api_v3/order/track.json for those AWBs in batches of 10.

That avoids polling every open shipment. Keep the windows contiguous and slightly overlapping, and persist the last window end so a restart does not lose events.

Rate limits and pagination

No rate limits or quota headers are published. The documented batch caps are the effective limits:

There is no cursor or page token anywhere. Pagination is by date window or by identifier list.

Mapping to the unified model

Gaps and open questions

• The tracking endpoint documents a different production host (api.ithinklogistics.com) from every other endpoint (my.ithinklogistics.com). Confirm which is correct.
• Tracking returns only last_scan_details, a single scan, not a scan history. If full event history is needed, it has to be reconstructed by storing each poll result, or requested from iThink.
• The weight unit on order create is ambiguous: the sample comments "in Kg" next to a value of 400 for a two-t-shirt parcel.
• The warehouse sample returns a locality name in the pincode field, which looks like a documentation error.
• No rate limits are published anywhere, only batch caps.
• No webhook mechanism is documented, and ClickPost's matrix and iThink's own docs disagree about NDR support. Ask whether a status push is available for larger clients.
• No deprecation schedule is given for v1 and v2, which are still published.
• Proof of delivery is not exposed as an object. ClickPost marks POD unsupported for iThink.
• The international API is documented on a separate tab and was not read for this page.

Sources

• iThink Logistics API documentation, v3, read 2026-09-21, together with the individual endpoint pages for order create, order details, tracking, get airwaybill, pincode check, rate check, cancellation, label, warehouse, remittance, sync order and NDR reattempt or RTO.
• iThink Logistics homepage, read 2026-09-21. Scale claims, carrier partner positioning, COD remittance cadence.
• ClickPost, iThink Logistics carrier integration, read 2026-09-21. Third-party capability matrix, partner id 170. It disagrees with iThink's own documentation on NDR support.