TruxCargo

Truxcargo is an Indian shipping aggregator and logistics services company operating from New Delhi. A seller uses one account and Truxcargo brokers each consignment out to partner carriers (Delhivery service tiers appear in its own serviceability responses), with a client panel covering orders, shipments, NDR and RTO. It is a carrier layer, not a sales channel: there is no catalogue, price or stock surface. It publishes no API documentation, but several of its endpoints are reachable unauthenticated because its own marketing site calls them from the browser, and those calls reveal a usable amount about the shape of the platform.

At a glance

What it is

Truxcargo Private Limited is a New Delhi company, listed on IndiaMART as a three year old GST registered business, with a product covering shipping, courier and transportation services. Its own site sells: a shipping rate calculator, pincode serviceability lookup, multiple order tracking (including a "master" tracking mode for consolidated consignments), a "Multiple Shipping Partner" aggregation story, and an operations dashboard described as covering "Orders to Shipments, NDR to RTO". The seller facing application is a separate client panel at b2b.truxcargo.com, titled "Trux Cargo | Client Panel", with its own login and registration.

It is a small operator. There is no published seller count, shipment volume or funding, and the marketing site is a React single page application whose content is served from the same PHP backend that serves the API.

One useful signal about the carrier panel: the pincode serviceability response returns Delhivery service tiers by name (Delhivery Dense, Delhivery Cargo, Delhivery Lite) with the serving centre, so at least part of the network is Delhivery resold under Truxcargo's own product names.

API access

There is no developer programme, no API key console and no published reference. Every route that would normally hold one was checked on 2026-09-22: api.truxcargo.com, app.truxcargo.com and docs.truxcargo.com do not resolve, and the marketing site has no developer or documentation page.

What is evidenced is that an API key concept exists. The marketing site's own JavaScript bundle contains a Shopify connection flow that:

1. Posts {sessionId, apiKey} to https://middleware.truxcargo.com/truxcargo/auth/session/apiKey and checks for data.Status === "OK".
2. On success, posts {sid, key} to https://b2b.truxcargo.com/api/shopify/auth.
3. Surfaces two distinct client side errors, "Incorrect KEY" when the middleware returns a message of KEY, and "Invalid API Key" otherwise.

So a seller does hold an API key, and there is a middleware tier in front of the client panel that validates it. How the key is issued (panel screen, support request, or only as part of the Shopify app install) is not published, and neither is what the key authorises beyond that handshake. A related https://b2b.truxcargo.com/api/shopify/authenticate/ path also appears in the bundle.

No SDK, Postman collection or OpenAPI specification is published in any language. No API version appears in any path and no deprecation policy exists. A search of the Shopify App Store for "truxcargo" on 2026-09-22 returned no listing, so the Shopify integration appears to be a custom or unlisted app rather than a public one.

Authentication

Not published. The only concrete facts, all observed rather than documented:

• An apiKey is exchanged together with a sessionId at POST https://middleware.truxcargo.com/truxcargo/auth/session/apiKey, and the response carries a Status field whose success value is the string OK and a message field carrying KEY for an incorrect key.
• The three endpoints the public website itself calls require no authentication at all: pincode serviceability, tracking and rate all answer to an anonymous request. That is a design choice of the public site, not necessarily the sellers' API surface.
• No token, header name, lifetime, scope model, rotation path or multi account mechanism is published for any authenticated call.

No authenticated request sample is given here, because the header or parameter that carries the credential on business calls is not known and a guess would be worse than nothing. Obtain the specification from Truxcargo before designing a credential store. What can be said is that the credential is per seller account and that a session identifier is paired with it, which suggests a stateful session rather than a stateless bearer token.

Objects we can read

Rates and serviceability

GET https://b2b.truxcargo.com/api/truxapi/pincode/{pincode} is live and unauthenticated. It returns the carrier services available at that pincode, with the serving centre and an out of delivery area flag:

{
  "status": true,
  "message": "Success",
  "data": [
    { "image": "https://b2b.truxcargo.com/assets/images/Logo_1.png", "title": "Dense", "vendor": "Delhivery Dense", "center": "Delhi_Mayapuri_L (Delhi)", "status": "Yes", "oda": "No" },
    { "image": "https://b2b.truxcargo.com/assets/images/Logo_1.png", "title": "Cargo", "vendor": "Delhivery Cargo", "center": "Delhi_Mayapuri_L (Delhi)", "status": "Yes", "oda": "No" }
  ]
}

status and oda are the strings "Yes" and "No", not booleans. oda is the out of delivery area surcharge flag, which matters for cost. Note this call takes a single pincode, not an origin and destination pair, so it answers "is this pincode served" rather than "is this lane served".

POST https://b2b.truxcargo.com/api/rate is the rate calculator behind the public Shipping Rate Calculator page. The body the site sends is {origin, destination, invoice_value, mode, weight, qty, width, length, height, login_id}. The dimension and weight fields must be arrays rather than scalars (a scalar produces the PHP sizeof() exception described above), which is consistent with multi package consignments. Sending well formed arrays yields {"status": false, "message": "Weight is Mandatory."}, so at least one further field or a different value type is required and the exact contract could not be determined without documentation. The response is read by the site as data, and login_id appears to be an optional seller identity that presumably switches the response from list rates to contracted rates.

Shipments and tracking

GET https://b2b.truxcargo.com/api/truxapi/tracking/{trackingNumber} is live and unauthenticated. An invalid number returns HTTP 400 with {"status": false, "message": "Wrong Tracking No"}. A valid one returns {"status": true, "data": {...}}, and the site reads data.tracking_no from it and de-duplicates on that field when several numbers are tracked at once.

A second form, GET .../api/truxapi/tracking/{trackingNumber}/master, exists for consolidated or master consignments, selected in the site by a trackingType of master. The site also splits user input on whitespace or commas and issues one request per number, so there is no multi number query parameter.

The full tracking response schema, including whether a scan or event history is returned and under what field names, could not be captured without a valid tracking number, and no sample is published. The site's tracking page renders an "Expected Date of Delivery", so an EDD field is present.

Orders, order items, products, listings, inventory, returns, payments and settlements, customers, locations

No endpoint is evidenced for any of these. The client panel plainly holds orders, shipments, NDR and RTO, since the site advertises a dashboard covering exactly those, but none of it is reachable or documented from outside. There is no settlement, invoice, wallet or COD remittance endpoint in evidence.

Writing back: listings, price and stock

Not applicable, this is a carrier aggregator. Truxcargo holds no catalogue, no price list and no stock.

The write path would be the shipment lifecycle, and no shipment write endpoint is evidenced at all. Nothing was found for create, cancel, AWB assignment, label generation, manifest, pickup request, NDR action or RTO. The only write style calls observed are the Shopify connection handshake (POST /truxcargo/auth/session/apiKey and POST /api/shopify/auth), which establish a session rather than move a shipment, and a newsletter subscription endpoint on the marketing site.

The practical position is therefore: the panel can do all of this, the API for it exists behind the middleware tier, and it is undocumented. An integration has to start with a request to Truxcargo for the specification, or with the Shopify app if the seller's storefront is on Shopify, since that path is already built.

Webhooks and notifications

Not published, and nothing in the site bundle suggests a callback mechanism. There is no subscription endpoint, no event catalogue, no signing secret and no retry policy in evidence.

What to poll instead, given only the endpoints that are known to work:

• Keep a local table of tracking numbers, since there is no list endpoint to enumerate shipments from.
• Poll GET /api/truxapi/tracking/{number} per open shipment. One number per call, so the call volume scales linearly with open shipments. Hourly per shipment is a defensible starting cadence for surface consignments.
• Use the /master variant for consolidated consignments rather than tracking each child number separately.
• Cache pincode serviceability aggressively. It changes slowly and the endpoint is unauthenticated, so there is no reason to call it repeatedly.

Because these endpoints are unauthenticated, treat them as a public convenience that could be rate limited, changed or closed without notice. Do not build a production status pipeline on an undocumented public endpoint without a written agreement from the vendor.

Rate limits and pagination

Nothing is published: no limits, no quota headers, no throttling response, no pagination model and no list endpoint. The framework in use (CodeIgniter REST_Controller) does support per key request limiting as a configuration option, so limits may well be enforced without being documented.

Observed error behaviour, which is what a client actually has to handle:

• Business failures arrive as HTTP 200 or 400 with {"status": false, "message": "..."}. Check the status boolean, not only the HTTP code.
• Malformed input can produce an HTML stack trace with a 500. A JSON-only client will throw on parse.

There is no backfill or recovery route. Record every tracking number at the moment it is issued.

Mapping to the unified model

Only what is evidenced is mapped. Everything else is recorded as not published rather than guessed.

Gaps and open questions

• No API documentation of any kind, and the authenticated surface is entirely unknown. Every shipment write operation, which is the whole point of a carrier integration, is unevidenced.
• The credential model is only half visible: an API key and a session id are exchanged at a middleware endpoint, but how the key is issued and how it is presented on business calls are both unknown.
• The tracking response schema could not be captured without a valid consignment number, so the event history shape, status vocabulary and EDD field name are all unknown.
• The rate request contract is incomplete. Array typed dimension fields are required, but a well formed array request still reports "Weight is Mandatory", so at least one field name or type differs from what the site sends.
• Serviceability is single pincode rather than origin and destination, so lane level serviceability has to be inferred from two calls or is not available at all.
• Production is running with PHP debug output enabled, leaking absolute server paths in stack traces. That is both a reliability problem for clients and a signal about operational maturity.
• The public endpoints are unauthenticated today, which is convenient and fragile. They should not be depended on without a written agreement.
• The Shopify integration exists in code but has no public App Store listing, so its distribution and support status are unclear.
• Recommended next step: request the integration specification from Truxcargo directly, and treat this catalogue entry as unusable for a production connector until that arrives. Unlike several peers in this segment there is no aggregator (Unicommerce, ClickPost) carrier page for Truxcargo to fall back on.

Sources

• truxcargo.com and its application bundle /static/js/main.2ddb0a01.js, read on 2026-09-22, for the endpoint hosts and paths, the API key handshake and the tracking, rate and pincode call shapes
• b2b.truxcargo.com, the "Trux Cargo | Client Panel" seller application
• Live probes on 2026-09-22: GET /api/truxapi/pincode/110001 returns the serviceability JSON quoted above, GET /api/truxapi/tracking/123456789 returns HTTP 400 with {"status":false,"message":"Wrong Tracking No"}, POST /api/rate returns an uncaught PHP TypeError stack trace for scalar dimension fields and {"status":false,"message":"Weight is Mandatory."} for array ones, and api., app. and docs.truxcargo.com do not resolve
• IndiaMART: Truxcargo Private Limited, New Delhi for the company location, age and GST registration
• Shopify App Store search for "truxcargo" on 2026-09-22, which returns no listing