intelligent.pageDocs

TCI

TCI Express publishes no API docs: an api.tciexpress.in host exists but is credential-gated, so booking, tracking and POD run via the panel or an aggregator.

TCI Express Ltd is a listed Indian express logistics company, demerged from Transport Corporation of India in 2016 and traded as TCIEXP. It moves surface, air and rail express consignments for manufacturers, pharma, automotive and retail shippers, and sells an e-commerce express service on top of the same network. For a seller it is a carrier, not a sales channel: the objects that matter are rates and pincode serviceability, consignment booking with a docket number, pickup requests, tracking scans, proof of delivery and reverse pickups. TCI Express does not run a public developer portal, and this page records exactly what is and is not verifiable from outside a signed contract.

At a glance

What it is

TCI Express is a pure express business: no warehousing arm, no freight brokerage, a company-owned hub and sorting network built around surface trucking with air and rail overlays. The homepage claims 60,000 plus delivery locations across 766 districts, 73 plus air gateways, 28 sorting centres, about 5,000 express support vehicles and roughly 3,500 employees, as read on 2026-09-22. The service lines it names are Surface Express, Domestic Air Express, International Air Express, Rail Express, C2C Express for full truckloads, E-commerce Express, Cold Chain Express, Reverse Express and an MBG Express money back guarantee product.

The customer base is overwhelmingly B2B: distributor and dealer replenishment, pharma cold chain, auto spares. E-commerce Express and Reverse Express are the two lines a D2C seller would buy, and those are the ones an aggregator resells. It is not a marketplace and holds no seller inventory.

API access

There is no self-serve developer programme. Every public surface is a form on the marketing site or the logged-in customer panel:

Two pieces of evidence say a machine interface exists and is simply not documented publicly:

  1. api.tciexpress.in resolves to 124.7.209.75 and answers. Over HTTPS the root returns HTTP 404 with server: Microsoft-IIS/10.0 and x-powered-by: ASP.NET and a zero length body. /swagger, /swagger/v1/swagger.json, /api-docs, /docs and /health all return 404. That is an ASP.NET application with no anonymous discovery route, which is the normal shape of a partner-only integration host.
  2. track.tciexpress.in resolves to 210.210.3.72 and issues a 302 to https://www.tciexpress.in/trackingdocket.aspx, so the tracking hostname is a vanity redirect rather than a service endpoint.

Certificate transparency for tciexpress.in lists only www, insights, mbg and a wildcard, so api and track are served under the wildcard certificate and were never separately enrolled. No SDK, Postman collection or first-party sample was found.

The practical route to credentials is a contracted account: TCI Express arranges the customer code and panel access at the branch or key account level, and an API conversation goes through the same channel. Budget for a named contact rather than a signup form.

Reaching it through an aggregator instead

ClickPost publishes a TCI Express carrier integration page and states which capabilities it has wired up, which is the clearest public statement of what the carrier interface supports:

That set implies the underlying carrier interface covers booking with waybill allocation, label retrieval, cancellation, scan retrieval and reverse pickup. It does not tell you the transport, the authentication or the field names. If you integrate through ClickPost you code against ClickPost, documented at docs.clickpost.ai, and TCI Express becomes a carrier code inside it. See /connectors/clickpost for that interface.

Authentication

Not published. No first-party document describes a token endpoint, an API key header, a customer code plus password scheme or a signature. Do not assume one. The only thing observable is that the host runs ASP.NET on IIS and returns 404 rather than 401 at the root, which tells you nothing about the scheme in force on real routes.

The public tracking form is a classic ASP.NET WebForms postback and is the only mechanism you can exercise today without a contract:

POST /trackingdocket.aspx HTTP/1.1
Host: www.tciexpress.in
Content-Type: application/x-www-form-urlencoded

__VIEWSTATE=<opaque value from the GET>&__VIEWSTATEGENERATOR=<value>&__EVENTVALIDATION=<value>&dwbno=<docket number>&btnsubmit=Submit

The demo03 radio on the same page selects dwb for a docket number or ref for a customer reference number. __VIEWSTATE, __VIEWSTATEGENERATOR and __EVENTVALIDATION must be scraped from a fresh GET of the same page, and they rotate.

Warning

Scraping the WebForms tracker is not a supported integration. It has no rate limit statement, no uptime commitment and no stable contract, and the hidden state fields will break the moment the page is rebuilt. Treat it as a diagnostic aid, not a data pipeline. Ask for the contracted interface instead.

Objects we can read

Orders

Not applicable. TCI Express is a carrier and never holds a sales order. Orders come from the sales channel connector.

Order items

Not applicable.

Products and listings

Not applicable.

Inventory

Not applicable.

Shipments and tracking

Readable in principle, not documented. From the public surfaces the shipment identifier is the docket number, called DWB on the tracking form and CN in TCI's own copy, and a customer reference number is accepted as an alternate key. The homepage tracker takes up to 50 numbers in one submission, which is the only published batch size anywhere on the site.

Field names, status codes, the scan event shape and whether history is returned in full are all unpublished. Sample response not published. Do not model a schema until a contracted document is in hand.

Returns and cancellations

Reverse Express is a named service line on the marketing site. ClickPost lists cancellation and return webhooks as wired capabilities, so the carrier interface supports at least cancel and reverse pickup. No first-party schema.

Proof of delivery

The tracking page carries a Show POD button that opens showepod.aspx in a popup for the looked-up docket, so an electronic POD image exists in the system. Whether it is exposed as a URL or a base64 blob over the machine interface is not published.

Payments and settlements

Not applicable in the marketplace sense. Freight is invoiced against the customer code and the invoice arrives through the panel or accounts, not through an API. COD remittance terms for e-commerce customers are contractual and not published.

Customers

Consignee name, address and phone are carried on the consignment, so any contracted interface would expose them on booking and on tracking. All of it is PII. The public tracker does not show consignee contact details.

Locations

branch-locator on the website lists branches. Pincode serviceability is checked at pincode-enquiry. Neither is offered as a documented machine interface.

Writing back: listings, price and stock

Not applicable, this is a carrier. There are no listings, prices or stock levels to write.

The write path is the shipment lifecycle: create a consignment and receive a docket number, fetch the label, raise a pickup request, and cancel before handover. ClickPost's carrier page confirms manifestation, label generation and cancellation are supported by the TCI Express integration, and a Pickup Request link sits in the site navigation for panel users. No first-party endpoint, request body or response shape is published, so nothing more specific can be written here without inventing it.

Webhooks and notifications

TCI Express publishes no webhook mechanism. The return and all-status webhooks advertised against TCI Express are ClickPost's, fired by ClickPost after it polls or receives scans from the carrier, and verified by ClickPost's own scheme.

Without a contract, the only pull option is the public tracker, which is not a supported interface. With a contract, ask specifically for: push of scan events versus pull only, the event code table, whether a bulk status endpoint exists, and the delivery retry policy. If only pull exists, a sane cadence for a carrier of this type is every 30 to 60 minutes for in-transit consignments and daily for anything already delivered, but that number must be agreed, not assumed.

Rate limits and pagination

Not published. The only public number is the 50 tracking numbers per submission accepted by the homepage tracker, read on 2026-09-22. Nothing states a requests per minute ceiling, a quota header or a pagination model.

Mapping to the unified model

Only shipments has a real counterpart. The rest of the table is included to record explicitly that it does not apply.

Gaps and open questions

  • The interface behind api.tciexpress.in is completely undocumented in public. Transport, authentication, field names, status codes and limits all need a contracted document.
  • Whether TCI Express pushes scan events at all, or whether every integrator polls, is unknown.
  • COD is not advertised on the site. Whether TCI Express carries COD for e-commerce shippers, and on what remittance cycle, needs a commercial answer.
  • The POD popup proves an electronic POD exists. How it is exposed to an integrator is unknown.
  • No sandbox is mentioned anywhere. Assume integration testing happens against live with real dockets until told otherwise.
Warning

A third-party Laravel package on GitHub, susheelbhai/laraship, ships a TciExpressAdapter that posts to a rate route and a booking route on api.tciexpress.in with a bearer token, a customer_id and a cn_number in the response. The host is real, but the repository has no stars, no recorded testing against a live TCI account, and none of those field names appear in any TCI Express publication. Nothing in it is corroborated by a first-party source. Do not implement against it. It is recorded here only so the next person who finds it knows it was already looked at and rejected.

Sources