LogistieX

LogistieX, legally Noetic Logistiex Pvt Ltd and branded "Noetic LogistieX", is an Indian logistics technology company rather than a carrier. It sells an orchestration layer that sits between a brand's order systems and a set of contracted Indian couriers (Ecom Express, Ekart, Shadowfax, Xpressbees, Delhivery, ATS, Blue Dart), normalising serviceability, shipment creation, manifesting, tracking and reverse pickups behind one API and one shipment state model. Today the company positions itself more broadly as "AI-native commerce backend infrastructure" spanning order management, fulfilment, transport and distribution intelligence, sold to enterprises as a configurable operating layer rather than as a self-serve shipping product.

For our purposes the useful surface is narrow and good: a first-party, machine-readable OpenAPI 3.0.1 specification for the shipping APIs, published at developer.logistiex.com, and a production host that is live and rejecting unauthenticated calls. Everything on this page is taken from that specification or from a live probe, not from the marketing site.

At a glance

What it is

LogistieX is a B2B logistics technology vendor, not a courier and not a marketplace. Its current site describes an "agentic commerce operating layer" built from composable modules: order management with availability-to-promise, allocation and exceptions; warehouse and store stock visibility; a transport layer covering "AWB, pickup, tracking, NDR and POD workflows"; 3PL orchestration; and distribution intelligence across secondary and tertiary distribution. Published use cases name a fashion and lifestyle retailer for 3PL orchestration and automotive spare parts for distribution intelligence. The site advertises ISO 9001, ISO 27001:2022 and SOC 2 posture, enterprise single sign-on over SAML or OAuth 2.0 into the panel, RBAC and MFA, and a 99.99 percent availability architecture.

Two of the site's own statements matter when reading it. It says integration classes shown are illustrative, and that "specific named integrations should be marked as live, certified, in progress or available through the adaptor framework only after technical confirmation". And it says LogistieX will bridge "CSV, SFTP, scheduled feeds and partner portals" where modern APIs are absent. Read the marketing surface as a capability map, and the OpenAPI document as the thing that actually exists.

There is history under the same domain. Web archive records from 2023 to 2025 show a much wider microservice estate on *.logistiex.com and *.dev.logistiex.com (oms-api, shippingapi, catalog-api, storefront-api, shopify-api, octopus-api, sanchar-api, vipatra-api, a Keycloak deployment at uacc, and a WooCommerce plugin service at woocom.logistiex.com exposing plugin install, order update and tracking routes). Those hostnames now resolve to the marketing site's Google front end, so the older seller-facing commerce stack appears retired or folded into the enterprise platform. The logistiex.com domain itself also carries unrelated captures from 2001 and 2002 belonging to a previous owner.

API access

• No self-serve route exists. There is no developer signup, no application registration, no pricing and no documented approval process. Access is via a commercial engagement, and the site's contact flow is a scoped-pilot conversation.
• The documentation site is fully public and does not require a login. It exposes llms.txt, a sitemap, and a per-endpoint OpenAPI 3.0.1 document, which is why this page can be specific.
• API versioning: the spec carries info.version: 1.0.0 with an empty title and description. No version segment appears in any path, there is no changelog and there is no deprecation policy. Endpoints carry an Apidog status field, and every one of the eighteen operations is marked released.
• No official SDK in any language, no Postman collection, no code samples. The Apidog project identifier is 623026 if a contact needs to be pointed at the same document.
• Several endpoints and fields are explicitly marked unfinished inside the spec itself: service_type on the shipment order ("Under development coming soon!"), recommend_courier and the recommended response flag ("This field is under development and not live"), and the whole webhooks group.
• The spec still contains leftover Pet, Category and Tag schemas under a "Sample Schemas" folder, which means it was started from the Swagger Petstore template. The shipping schemas themselves are original and detailed, but it is a sign the document is not kept under tight review.

Authentication

Authentication is the weakest documented part of the API and must be settled with LogistieX before any build.

1. The OpenAPI document declares securitySchemes: {} and security: [] both globally and on every operation, so formally the spec says the API is unauthenticated. It is not.
2. Every operation documents a 401 response whose Apidog name is "JWT Access token is missing or invalid", and a 403 named "Not Authorized to perform this operation". That is the only statement of the credential type anywhere in the published material.
3. A live unauthenticated request to the declared production host on 2026-09-22 confirmed enforcement. The error body is Spring Security shaped, which is consistent with the archived Keycloak deployment at uacc.logistiex.com acting as the identity provider.

curl -i https://api-playground.logistiex.com/
  #  HTTP/1.1 401
  #  {"message":"Full authentication is required to access this resource",
  #   "type":"AuthnError","code":1401}

Once a token is held, the call shape is ordinary. Assume Authorization: Bearer <jwt> until told otherwise:

curl -X POST https://api-playground.logistiex.com/serviceability/search \
  -H 'Authorization: Bearer <jwt>' \
  -H 'Content-Type: application/json' \
  -d '{"shipment_purpose":"SALE","origin_postal_code":"122001",
       "destination_postal_code":"134002","payment_mode":"PREPAID",
       "dimensions":{"length":9,"breadth":3,"height":9,"weight":3}}'

Objects we can read

Orders

There is no sales order object. The ShipmentOrder is the only order-shaped thing, and sales order context rides inside it as forward_shipment_detail.order_number, order_time, and per-item order_number, hsn_code, tax_info (with invoice_number, invoice_date, seller_gstin, consignee_gstin and a CGST, SGST and IGST split).

• POST /shipmentorders/search with a ShipmentIdentifier body, which accepts any of shipment_order_id (UUID), awb_number, courier_code or shipper_reference_token.
• GET /shipmentorders/{shipment_order_id}/ for a single order.

The ShipmentOrder response carries: id, shipment_purpose, origin, destination, return_location, forward_shipment_detail, reverse_shipment_detail, expected_pickup_slot, expected_delivery_slot, value_added_service, shipment_state, preferred_courier, service_type, auto_manifest, offload_shipment, offload_courier, offload_location, shipper_reference_token, assigned_courier_code, sort_code, packslip, volumetric_weight, billed_weight, expected_charges, courier_promised_pickup_slot and courier_promised_delivery_slot.

volumetric_weight and billed_weight are computed by LogistieX, with billed weight documented as the higher of dead and volumetric weight, which is exactly the number weight disputes turn on.

Enumerations worth hard-coding: ShipmentPurpose is SALE, NON_COMMERCIAL or RETURN. PaymentMode is COD, PREPAID, EXCHANGE or REPLACEMENT. AddressType is OFFICE, HOME or DROPBOX. CourierCode is ECOM, EKART, SHADOWFAX, XPRESSBEES, DELHIVERY, ATS, EKART_EXPRESS, DELHIVERY_EXPRESS or BLUEDART.

Order items

forward_shipment_detail.items[] is a proper line-item array: item_name, description, sku_code, category, subcategory, brand_name, quantity, order_number, order_time, hsn_code, item_url, item_image_urls[], item_value, per-item dimensions, essential, fragile, dangerous and tax_info. This is the richest item schema of any Indian carrier API we have looked at, and it is readable back on the shipment order.

Products and listings

None. LogistieX holds no catalogue in this API. Item attributes travel on the shipment only.

Inventory

None in the shipping API. The wider platform markets warehouse, store and in-transit stock visibility, but no inventory endpoint is published.

Shipments and tracking

Two routes return the same ShipmentStatus schema:

• GET /shipmentorders/{shipment_order_id}/status
• GET /status?courier_code=&shipper_reference_token=&awb_number=, all three optional, which is the lookup to use when we hold an AWB rather than a LogistieX UUID.

Both return an array of ShipmentStatus:

[
  {
    "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "shipment_order_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "shipper_reference_token": "clientref-123456",
    "awb_number": "713985308",
    "courier_code": "ECOM",
    "state": "DELIVERED",
    "notes": "Notes from courier for the state of the shipment",
    "timestamp": "2023-03-30T20:00:00.015Z",
    "latest_shipment_event": {
      "event": "SoftDataUploadedEvent",
      "sub_event_code": "SDP",
      "sub_event_code_name": "SOFT_DATA_PUSHED"
    }
  }
]

The state model is deliberately coarse: ShipmentState is only CREATED, DELIVERED, CANCELLED, IN_TRANSIT, LOST, FAILED or DAMAGED. Granularity comes from latest_shipment_event, where sub_event_code and sub_event_code_name carry the courier's detailed step. This matches the platform's claim that "all partner events map to one shipment state model", and it means NDR is not a state: a failed delivery attempt surfaces as FAILED or as a sub-event code, with no separate reason field.

Note what the schema does not give: a full event history array. ShipmentStatus exposes the latest event only. Building an event timeline means storing each poll or each webhook delivery ourselves.

Timestamps are ISO 8601 with milliseconds and a Z offset, which is a real improvement over most Indian carrier APIs.

Returns and cancellations

Reverse journeys are first class. shipment_purpose: RETURN plus reverse_shipment_detail creates a reverse pickup, and GET /qcquestions/ returns the list of supported quality-control questions to ask at the doorstep during a reverse pickup, which pairs with the doorstep_qc value added service. Cancellation and return initiation are done through shipment control events, described under writing back.

Payments and settlements

None. payment_info on the shipment carries payment_mode, collectable_amount, qr_code and payment_link, so COD collection is expressed per shipment, but there is no remittance, settlement, invoice or wallet endpoint.

Customers

No customer object. Consignee PII travels on the shipment inside destination.address (contact_person, address_line1, address_line2, city, postal_code, state, country, latitude, longitude, address_type) and destination.contact (primary_phone, alternate_phone, email, whatsapp_contact). All unmasked.

Locations

• POST /locations creates a pickup or drop-off location, with an Address, a Contact, a type such as WAREHOUSE or SELLER, and a shipper-supplied code such as BNP-LOC-1.
• GET /locations/{location_id}/ retrieves one, PUT /locations/{location_id}/ updates its address, contact and type.

There is no list endpoint, so keep our own map of location identifiers.

Serviceability and rates

POST /serviceability/search is both the serviceability check and the rate shop. The request takes shipment_purpose, origin_postal_code, destination_postal_code (the three required fields), plus optional return_postal_code, ISO 3166-1 alpha-2 country codes defaulting to IN, shipment_value, dimensions, payment_mode, essential, fragile, dangerous, expected_pickup_slot, expected_delivery_slot, value_added_service, preferred_courier_code, service_type and recommend_courier.

It returns an array of Serviceability, one per available courier:

[
  {
    "courier_code": "ECOM",
    "expected_charges": 99.45,
    "expected_pickup_sla": { "start_time": "2023-10-03T20:00:00.015Z", "end_time": "2023-10-05T20:00:00.015Z" },
    "expected_delivery_sla": { "start_time": "2023-10-03T20:00:00.015Z", "end_time": "2023-10-05T20:00:00.015Z" },
    "recommended": false,
    "rank": 1,
    "supported_vas": {
      "collect_on_delivery": true, "proof_of_delivery": true, "exchange": true,
      "doorstep_qc": true, "open_box_delivery": true, "installation": true
    }
  }
]

An empty array means no courier serves that pincode pair for those parameters. recommended and the recommend_courier request flag are both marked not live in the spec, so rank is the only ordering signal to trust today.

Note that proof of delivery appears only as a value added service flag, requested at creation and reported as courier-supported here. There is no endpoint that returns a POD document, signature image or receiver name.

Writing back: listings, price and stock

Not applicable, this is a carrier. LogistieX holds no catalogue, price or stock, so there is nothing to write listings, price or stock to. The write path is the shipment lifecycle.

auto_manifest: true books with the courier during creation; false leaves it to an explicit manifest call. Creation returns the ShipmentOrder including assigned_courier_code, sort_code, billed_weight, expected_charges and packslip. The label is inline, not a URL: Packslip is { "content": "<base64 byte-stream>", "fileFormat": "pdf" }, with PDF, PNG or JPEG named as possible formats. The AWB itself is in forward_shipment_detail.awb_numbers, an array, alongside packaging_serial_numbers, package_scan_action and eway_bill_number.

ShipmentControlEvent is the single most useful write in this API, and it is how pickup, NDR and RTO are actioned. It requires shipment_instructions[] and notes, and optionally carries alternate_contact_person, alternate_contact_number, alternate_delivery_address, alternate_pickup_address, alternate_delivery_slot, alternate_pickup_slot, escalated and cash_to_be_collected. The instruction vocabulary is:

The route is documented as asynchronous, so the POST acknowledges and the outcome is read back with the GET on the control event, or observed as a SHIPMENT_CONTROL webhook.

Webhooks and notifications

Designed, specified, and by the spec's own words not yet shipped. The POST /webhooks description reads "Webhooks are the notifications about ShipmentOrder and ShipmentStatus events. Under development and coming soon!", while the Apidog status field on the same operation says released. Treat that contradiction as the finding and confirm with LogistieX.

The design, as published:

• Three routes: POST /webhooks to register, GET /webhooks/{webhook_id}/ to read the config, PUT /webhooks/{webhook_id}/ to update it.
• WebhookEventType is *, SHIPMENT_STATUS, SHIPMENT_ORDER or SHIPMENT_CONTROL, and config.events[] takes an array, so one endpoint can take a subset.
• is_enabled toggles a registration without deleting it. No delete route is published.
• Verification is inverted relative to most platforms. There is no HMAC signature over the request body. Instead LogistieX authenticates itself to our endpoint using auth_type: BASIC_AUTH with username and password, or auth_type: API_SECRET with api_key and api_secret placed in either the HEADER or the QUERY string per api_key_position. Credentials in a query string are logged by every proxy in the path, so insist on HEADER, and terminate the receiver on TLS with a long random secret.
• No retry policy, delivery guarantee, ordering guarantee or replay endpoint is published.

Until webhooks are confirmed live, poll GET /status keyed on shipper_reference_token or awb_number. Because ShipmentStatus returns only the latest event, poll often enough not to miss intermediate scans: every 30 minutes for CREATED and IN_TRANSIT, stopping at DELIVERED, CANCELLED or LOST, and store every distinct latest_shipment_event we observe to reconstruct a history.

Rate limits and pagination

No rate limit is published: no numbers, no quota headers, no burst policy, no scope statement. The spec does define a 503 response named "Service Not Available" on every operation, which is the only back-pressure signal documented, so treat 503 as a retry-with-backoff instruction.

There is no pagination anywhere. POST /shipmentorders/search takes a ShipmentIdentifier, which is a single-shipment lookup by UUID, AWB, courier code or shipper reference, not a filtered list with a cursor. There is no date window, no page parameter and no list endpoint for orders, locations or webhooks. The practical consequence is the same as for most carrier APIs: LogistieX cannot be backfilled or reconciled from its own API, so the set of shipments to track must come from our own records, keyed on the shipper_reference_token we supplied at creation.

Mapping to the unified model

Gaps and open questions

• Authentication is the blocking gap. The credential type is only implied by a 401 description and confirmed by a live error. No token endpoint, lifetime, scope, client registration or refresh flow is published, and how one integration acts for several shippers is undocumented.
• The declared server is named api-playground.logistiex.com but labelled "Prod Env". Whether that is genuinely production, and whether a separate sandbox exists, must be confirmed.
• Webhooks are specified but described as "under development and coming soon" while simultaneously marked released. Confirm whether they deliver today, and get the retry and ordering policy in writing.
• No event history array: ShipmentStatus returns only the latest event, so a timeline has to be assembled client side. No rate limits, no pagination and no list endpoints are published either, so the API cannot be reconciled against itself.
• No proof of delivery retrieval. POD is a value added service flag at creation, with no endpoint returning the document, signature or receiver name. No COD remittance or settlement surface either, so cash reconciliation is out of band.
• No NDR reason field. FAILED plus a sub-event code is all the API gives, which is thin for an NDR workflow.
• The sub-event code vocabulary is not published. Only one example exists in the spec (SDP / SOFT_DATA_PUSHED). The full mapping table is needed before tracking states can be normalised.
• The spec still ships Petstore sample schemas, and several fields are marked not live, so the document is not tightly maintained. Re-fetch llms.txt before any build and diff it.
• Commercially, there is no published route in. The marketing site's route to engagement is a scoped pilot conversation, which implies a long onboarding rather than a self-serve connector.

Sources

• Noetic LogistieX Shipping APIs developer site and its llms.txt, read 2026-09-22. Eighteen endpoint documents fetched individually as OpenAPI 3.0.1 YAML, which is the source of every path, schema, enumeration and example on this page.
• Live probe of https://api-playground.logistiex.com/ on 2026-09-22, returning HTTP 401 with {"message":"Full authentication is required to access this resource","type":"AuthnError","code":1401}, confirming the declared production host is up and enforcing authentication.
• logistiex.com, read 2026-09-22. A client-rendered single page application; the positioning, module list, certification claims and the "illustrative integration classes" caveat were read out of its JavaScript bundle at /assets/index-CmRuQst0.js.
• Web archive index for logistiex.com and subdomains via the CDX API, queried 2026-09-22. Source of the retired microservice hostnames, the WooCommerce plugin routes at woocom.logistiex.com, the Keycloak deployment at uacc.logistiex.com, and the 2001 to 2002 captures belonging to a previous owner of the domain.
• DNS lookups on 2026-09-22 showing developer.logistiex.com delegated to Apidog and the former API hostnames now pointing at the marketing site's front end.