Trackon

Trackon Couriers is an Indian express logistics company founded in 2001, operating a large franchise based branch network for domestic document and parcel movement plus an international forwarding arm. It is a carrier, not a marketplace and not an aggregator: it carries other people's shipments and holds no catalogue, price or stock. For a seller it matters as a shipping option in the same bracket as DTDC and Professional Couriers, strong in tier 2 and tier 3 pincodes through its franchise branches, and it is offered as a carrier inside several Indian aggregator panels. Unusually for a courier of this vintage, Trackon runs an ASP.NET Web API whose auto generated help page is publicly reachable, so the endpoint inventory and the request and response schemas can be read without an account even though the endpoints themselves need credentials.

At a glance

What it is

Trackon Couriers Private Limited started in 2001 and describes itself as an express logistics company covering regional, national and international markets. Its published domestic products are a guaranteed next day and two day express service, standard and express parcel, air, rail and road freight, and heavy B2B consignments up to around 100 kg on pan India air. Value added services named on the domestic services page include a ToPay facility for contractual customers where freight is collected from the consignee, shipment insurance with a 2 percent non refundable risk surcharge of invoice value, or 0.2 percent where the customer carries their own insurance and only needs a Certificate Of Facts, and reverse pickup.

The network is franchise based, which is the operationally relevant fact: bookings and delivery runs are entered by branch staff, and several of the API endpoints are clearly branch or hub facing rather than shipper facing. The company is not a marketplace, has no seller catalogue, and takes no part in the commercial side of an order beyond collecting COD.

API access

Credentials are issued to onboarded contract customers. There is no developer console, no self serve key generation and no published application form. In practice the route is a Trackon sales or key account contact, who provisions a customer code, a portal user id and password, and an Appkey.

What can be established without an account:

• The API host is api.trackon.in, served by IIS. A GET of the host root returns 403 - Forbidden: Access is denied.
• api.trackon.in/help returns 200 and renders the standard ASP.NET Web API help page, titled "WELCOME TO API SUPPORT PAGE", with a single section called CRM listing 16 operations. Every row's description reads "No documentation available", so the help page gives you the contract but not the meaning.
• Model namespaces in the XML samples are http://schemas.datacontract.org/2004/07/CustomerAPI.Models.CRM, confirming the assembly is Trackon's own CustomerAPI project rather than a third party gateway.
• There is no API version in any path. There is no changelog, no deprecation notice and no stated support policy.
• No official SDK exists in any language. There is no Trackon owned GitHub organisation, no Postman collection published by Trackon, and no OpenAPI or WSDL document on the host. swagger, swagger/v1/swagger.json and Service.svc all return 404.

The full operation inventory, exactly as the help page lists it:

Note there is no rate or price quote endpoint anywhere in that list. Trackon does not publish a rating API. Freight is contracted offline and reconciled from invoices.

Authentication

There is no token step. Every call carries the same three secrets, and the only variation is where they sit and how they are spelled.

1. Obtain a customer code, portal userId, password and Appkey from your Trackon account contact. These are long lived static values. No lifetime, rotation policy or scope model is published.
2. For the POST endpoints, put Appkey, userId and password in the JSON request body alongside the business fields.
3. For the GET endpoints, put them in the query string.
4. There is no refresh, no expiry to handle and no per call signature. For multiple shipper accounts, store one credential triple per Trackon customer code and select on it; there is no notion of an application credential distinct from an account credential.

A serviceability call, which is the cheapest way to prove a credential triple works:

curl -X POST https://api.trackon.in/CrmApi/Crm/GetPincodeServiceability \
  -H 'Content-Type: application/json' \
  -d '{
    "Appkey": "YOUR_APPKEY",
    "userId": "YOUR_USER",
    "password": "YOUR_PASSWORD",
    "OrgPinCode": "110001",
    "DesPincode": "560001"
  }'

An authenticated tracking call, where the credentials ride in the query string:

curl 'https://api.trackon.in/CrmApi/t1/AWBTracking?AWBNo=123456789&AppKey=YOUR_APPKEY&userID=YOUR_USER&Password=YOUR_PASSWORD'

Objects we can read

There are no orders, order items, products, listings, inventory or customers in this API. It is a shipment and event store with two hub level reports attached. The sections below use the field names exactly as the help page declares them. Where the help page declares a response as HttpResponseMessage, the response shape is genuinely not published and is marked as such.

Shipments and tracking

GET CrmApi/t1/AWBTracking?AWBNo={AWBNo}&AppKey={AppKey}&userID={userID}&Password={Password}

One AWB per call. There is no bulk tracking endpoint, no date window filter and no pagination; the event list is returned whole. The declared response type is DocketResponce and the sample is published, so this is the best documented endpoint on the host.

{
  "summaryTrack": {
    "AWBNO": "...",
    "REF_NO": "...",
    "BOOKING_DATE": "...",
    "EDD": "...",
    "ORIGIN": "...",
    "NO_OF_PIECES": "...",
    "PINCODE": "...",
    "DESTINATION": "...",
    "PRODUCT": "...",
    "SERVICE_TYPE": "...",
    "CHARGED_WEIGHT": "...",
    "CURRENT_STATUS": "...",
    "CURRENT_CITY": "...",
    "EVENTDATE": "...",
    "EVENTTIME": "...",
    "TRACKING_CODE": "...",
    "NDR_REASON": "...",
    "PODUrl": "..."
  },
  "CustomersummaryTrack": { "...": "same shape as summaryTrack minus CHARGED_WEIGHT" },
  "lstDetails": [
    {
      "CURRENT_CITY": "...",
      "CURRENT_STATUS": "...",
      "EVENTDATE": "...",
      "EVENTTIME": "...",
      "TRACKING_CODE": "..."
    }
  ],
  "ResponseStatus": {
    "ErrorCode": "...",
    "Message": "...",
    "StackTrace": "...",
    "Errors": [{ "ErrorCode": "...", "FieldName": "...", "Message": "..." }]
  }
}

Points worth knowing before you build against it:

• All money, weight and date fields are typed as string, including CHARGED_WEIGHT, EDD, EVENTDATE and EVENTTIME. Date and time are separate fields, and no format or timezone is stated. Parse defensively and store the raw strings.
• TRACKING_CODE is the machine readable status and CURRENT_STATUS the human one. The code list is not published, so the status vocabulary has to be collected empirically from live traffic before it can be mapped.
• NDR_REASON sits on the summary, so a failed delivery reason is available from the same call as the events.
• summaryTrack and CustomersummaryTrack are near duplicates; the customer variant drops CHARGED_WEIGHT. AWBTrackingCustomer is the same endpoint restricted to that narrower view, presumably for exposing to an end consumer.
• ResponseStatus.StackTrace being part of the published contract means a server fault can return a .NET stack trace. Do not surface it.

GET CrmApi/Crm/CRMDocketStatusDetails?Appkey={Appkey}&docket={docket}

A lighter status lookup that needs only the Appkey and the docket number, with no user id or password. Returns a single summary plus a differently shaped status block.

{
  "SummaryProp": {
    "AWBNO": "...",
    "BOOKING_DATE": "...",
    "CURRENT_STATUS": "...",
    "CURRENT_CITY": "...",
    "DESTINATION": "...",
    "TRACKING_CODE": "...",
    "EVENTDATE": "...",
    "EVENTTIME": "...",
    "NDR_REASON": "...",
    "ORIGIN": "...",
    "PINCODE": "...",
    "REF_NO": "..."
  },
  "ResponseStatus": {
    "Message": "...",
    "Errors": "...",
    "ErrorCode": "...",
    "StackTrace": "...",
    "RemaningTotal": "...",
    "Status": true,
    "PODUrl": "...",
    "SIGNUrl": "...",
    "NDRUrl": "..."
  }
}

This variant hands back three document URLs, a POD, a signature image and an NDR document, which the richer AWBTracking does not. It also carries a RemaningTotal field on the envelope. The name suggests a remaining call allowance on the key, but nothing in the help page says so and it should be logged and observed rather than relied on.

Proof of delivery

GET CrmApi/t1/AWBPOD?AWBNo={AWBNo}&AppKey={AppKey}&userID={userID}&Password={Password}

Returns the POD image inline rather than as a link.

{
  "AwbNo": "...",
  "Base64POD": "...",
  "ResponseStatus": { "ErrorCode": "...", "Message": "...", "StackTrace": "..." }
}

One AWB per call. The image format inside the base64 is not stated; sniff the magic bytes. For bulk POD collection this is expensive, so prefer the PODUrl and SIGNUrl that come back from CRMDocketStatusDetails and fetch the image only when one is actually needed.

Pincode serviceability

POST CrmApi/Crm/GetPincodeServiceability

Request body is PincodeFinderProp: Appkey, userId, password, OrgPinCode, DesPincode. All five are strings. This is an origin and destination pair check, not a list of all serviceable pincodes, so there is no way to pull the serviceability master in one call; it has to be walked pair by pair and cached. The response is declared as HttpResponseMessage, so the reply shape is not published.

Delivery run and COD collection reports

These two cm1/ endpoints take nothing but a lowercase appkey and return arrays. They read as hub or branch facing feeds rather than per shipment lookups, and they are the only place in the API where money appears.

GET CrmApi/cm1/GetwbDeliveryReport?appkey={appkey} returns lstwbDeliveryReport[], a delivery run sheet level record. Sample is published; the 28 declared fields, all typed string, are DRNo, AwbNo, SerialNo, EntryDate, EntryTime, ByHub, DRTo, Area, Pcs, DocType, Weight, Topay, COD, ValueIf, Containts, RefNos, Remarks, Consignee, Address, EnterBy, EntryDateTime, RTOFlag, EntryId, UploadDate, Mobile, Favor, VAS and EntryType.

Consignee, Address and Mobile are consignee PII. RTOFlag marks a return to origin. Containts is a misspelling of contents and is part of the real contract.

GET CrmApi/cm1/GetwbDeliveryStatus?appkey={appkey} returns lstwbDeliveryStatus[], the COD remittance trail. Its 20 declared fields, again all string, are EntryDateTime, RefNo, NewNo, Status, Remarks, StatusDate, StatusTime, EnterBy, FromHub, ByHub, EntryId, UploadDate, VAS, TopayCollect, CODCollect, CollectDate, CollectNo, CollectBank, CODAmount and DRSNo.

CODAmount, CODCollect, CollectDate, CollectNo and CollectBank together give COD collected against a shipment and how it was banked, which is the closest thing Trackon exposes to a settlement record. Neither report endpoint declares a date window, a page parameter or a cursor, which is a problem: there is no published way to ask for only new rows or to page a large result. Assume an unbounded array scoped to whatever the key is attached to, and de duplicate on AwbNo plus EntryDateTime on your side.

Returns and cancellations

There is no returns object. A return shows up as RTOFlag on the delivery report and, for a shipment you are redirecting yourself, through the RTO address block on PickupRequest. Cancellation is a write, covered below.

Writing back: listings, price and stock

Not applicable, this is a carrier. Trackon holds no listings, no prices and no stock, so there is nothing of that kind to write. The write surface is shipment lifecycle only, and it is the larger half of this API.

Shipment create

POST CrmApi/Crm/CDSCourierOrderBooking, request body CDSCourierOrderRequest:

{
  "userId": "...",
  "password": "...",
  "Appkey": "...",
  "orderId": "...",
  "orderDate": "...",
  "mode": "...",
  "strBookingType": "...",
  "productDetails": [
    { "barcode": "...", "name": "...", "quantity": "...", "weight": "...", "SKUNumber": "..." }
  ],
  "destinationDetails": {
    "name": "...",
    "srnNo": "...",
    "phone": "...",
    "alternatePhone": "...",
    "addressLine1": "...",
    "addressLine2": "...",
    "addressLine3": "...",
    "addressLine4": "...",
    "city": "...",
    "state": "...",
    "pincode": "...",
    "country": "...",
    "EmailId": "..."
  }
}

The request carries your own orderId as the idempotency and reconciliation key, four address lines plus a country on the consignee, and a line item array with SKU and barcode. There is no origin address in the request, so pickup location is resolved from the account behind the credentials. The accepted values of mode and strBookingType are not published, and neither is the response, which is declared as HttpResponseMessage. In particular the AWB that the booking returns is not in any published schema, so the exact field name carrying it has to be confirmed against a live call during onboarding. There is also no label endpoint anywhere in the inventory: Trackon does not appear to return a printable label from the API, only a number.

POST CrmApi/Crm/CDSCourierOrderBookingCancel cancels by your own order id, not by AWB: body is Appkey, userId, password, orderId, Remarks.

Soft data upload

POST CrmApi/Crm/SoftDataUpload takes 22 fields entirely in the query string, including AwbNo, SerialNo, RefNo, ActionType, CustomerCode, ClientName, AddressLine1, AddressLine2, City, PinCode, MobileNo, Email, DocType, TypeOfService, Weight, InvoiceValue, NoOfPieces, ItemName and Remark. This is the classic Indian courier pattern where the shipper is allotted a stationery range of AWB numbers and pushes the shipment detail against a number it already holds, rather than being issued one. Because every field including the password travels in the URL, this endpoint is the one most in need of log scrubbing.

Pickup request

POST CrmApi/Crm/PickupRequest is the richest request body in the API, PickupModuleRequest, with 53 scalar fields plus an LBH array. Beyond the credentials it carries:

• Routing and service: ActionType, ServiceType, DocType, TypeOfService, PickupDate, PickupTime, CustomerCode, AwbNo, RefNo, CustRequestNo, IsSelfDrop.
• Pickup party: PickupLocCode, PickupCustName, PickupAddress, PickupPin, PickupCustPhone, PickupCity, PickupState, PickupHub.
• Delivery party: DeliveryLocCode, DeliveryCustName, DeliveryAddress, DeliveryPin, DeliveryCustPhone, DeliveryCity, DeliveryState, DeliveryHub.
• An alternate address block, AlternateCustName, AlternateAddress, AlternatePin, AlternateCustPhone, AlternateCity, AlternateState, AlternateHub.
• An RTO address block, RTOCustName, RTOAddress, RTOPin, RTOCustPhone, RTOCity, RTOState, RTOHub. Being able to declare the return address at booking time is genuinely useful and not every Indian carrier allows it.
• Consignment: ItemName, PaperWorkAttached, InvoiceValue (numeric), NoOfPieces, Weight, Remark, VAS, COD (numeric), Topay (numeric).
• LBH[], per piece dimensions: NoofPcs, ChildRefNo, Length, Breadth, Height, ActWt, Content. ChildRefNo per piece means multi piece shipments are first class.

POST CrmApi/Crm/PickupCancel cancels a pickup by AwbNo with Remarks.

UploadPickupRequestWithDockNo and UploadPickupRequestWithoutDockNo take a flatter 29 field body, effectively the soft data fields plus a pickup party block, and the pair differ on whether you already hold a docket number. UploadPickupRequestSoftData is the same again with everything in the query string. Four overlapping ways to raise a pickup is an artefact of the API growing over time; during onboarding, ask which one your account is expected to use and ignore the rest.

NDR action

POST CrmApi/Crm/NDRAction, body NDRActionRequest: Appkey, userId, Password, AwbNo, Action, Date, AlternatePhoneNumber, UpdatedAddress, Remarks. This lets you respond to a failed delivery with a reattempt date, a corrected phone number or a corrected address. The permitted values of Action are not published and must be confirmed with Trackon.

Webhooks and notifications

None. There is no subscription, callback registration or event endpoint anywhere in the 16 operation inventory, and no HMAC secret or signature header is described. Any claim that Trackon pushes status events is unsupported by the published API.

Polling is the only option, and the shape of the API constrains how:

• Per shipment status: CRMDocketStatusDetails is the cheapest call, since it needs only the Appkey and the docket, and it also returns the POD, signature and NDR document URLs. Use AWBTracking when the full event list or the charged weight is needed.
• A reasonable cadence for active shipments is every 3 to 6 hours, tightening to hourly for shipments in an out for delivery or NDR state and stopping entirely once a terminal status is seen. Because both tracking endpoints are one AWB per call, the cost scales linearly with open shipments, so an active shipment set is essential; never sweep history.
• For money, poll GetwbDeliveryStatus on a daily cycle and de duplicate on AwbNo plus EntryDateTime, since it has no incremental filter.
• If RemaningTotal in the CRMDocketStatusDetails envelope does turn out to be a remaining call allowance, that value should drive backoff. Record it from day one.

Rate limits and pagination

No numbers are published. There is no documented quota, no X-RateLimit style header described, and no statement of burst versus sustained behaviour.

• Pagination: none. No endpoint accepts a page, offset, cursor or date window parameter. The two array returning report endpoints return whatever the key is scoped to, in full.
• The RemaningTotal field on the CRMDocketStatusDetails response envelope is the only hint that a call allowance exists. Treat it as unconfirmed.
• Practical posture until a limit is agreed in writing: serialise per credential, keep concurrency at 2 or below, add jittered exponential backoff on any non 200 and on HTML error bodies, and cache serviceability pair results for at least 24 hours since the pincode master changes slowly. An IIS hosted API of this generation is far more likely to fail under concurrency than to return a clean 429.

Mapping to the unified model

Gaps and open questions

• Every endpoint on the live help page is marked "No documentation available". The contract is known, the semantics are not. Field meanings, mandatory versus optional, and accepted enum values all have to be settled with Trackon before a connector can be trusted.
• Most responses, including the one that matters most, CDSCourierOrderBooking, are declared as HttpResponseMessage. The field that carries the newly created AWB is therefore unknown. This is the single biggest blocker and the first thing to confirm with a live credential.
• No status code list. TRACKING_CODE has to be learned empirically, which means the connector needs an unmapped status bucket and an alert when a new code appears.
• No rate limit, no quota and no sandbox are published. Whether RemaningTotal is a call allowance is unresolved.
• No label. Nothing in the inventory produces a shipping label document, which implies labels are printed from the Trackon portal or from customer stationery. Confirm whether a label API exists outside this help page.
• No rating. Whether a price quote API exists privately is unknown; nothing public suggests one.
• Four overlapping pickup endpoints and two soft data endpoints exist with no statement of which is current. One of them is probably deprecated and still routed.
• Incremental extraction from the two cm1/ report endpoints is unsolved. Without a date filter, whether they return a bounded recent window or everything is unknown, and the answer determines whether daily polling is viable.
• The consumer facing tracking on trackon.in and the t1/ endpoints may not share a status vocabulary. Not verified.
• No shipment volume, revenue, branch count or pincode coverage figure could be verified from a first party source. The about page gives narrative only.

Sources

• Trackon API support page, live help index listing all 16 operations, read 2026-09-22
• Trackon per operation help pages under api.trackon.in/Help/Api/, read 2026-09-22, which supplied every request and response schema quoted above. Twelve were read: CDSCourierOrderBooking, CDSCourierOrderBookingCancel, GetPincodeServiceability, PickupRequest, PickupCancel, NDRAction, UploadPickupRequestWithDockNo, AWBTracking, AWBPOD, CRMDocketStatusDetails, GetwbDeliveryReport and GetwbDeliveryStatus
• Trackon about us, read 2026-09-22, for the 2001 founding date and positioning
• Trackon domestic courier services, read 2026-09-22, for product names, the ToPay facility and the insurance surcharge percentages
• Trackon sitemap, read 2026-09-22, which contains no developer or API page, confirming the help page is unlinked from the public site
• Live probes on 2026-09-22: api.trackon.in/ returns 403 from IIS; /help returns 200; /swagger, /swagger/v1/swagger.json, /Service.svc, /api, /rate, /booking, /tracking and /cancel all return 404
• susheelbhai/laraship, file src/Adapters/TrackonAdapter.php on GitHub, read 2026-09-22. Cited only as a negative finding: its endpoints do not exist on the live host
• ClickPost carrier integration sitemap, read 2026-09-22. Contains no Trackon carrier page, and clickpost.ai/carrier-integration/trackon returns 404