Aaj Swift

AAJ Swift is the pan-India express and part-truck-load transport arm of AAJ Enterprises, the Delhi NCR third-party logistics group that also trades as AAJ Supply Chain Management. It sells B2B PTL transportation with a stated 95 percent on-time record, transit insurance included on every consignment, a delay compensation guarantee, digital proof of delivery, and low out-of-delivery-area exposure across a pan-India pincode footprint. Since 2025 it has extended the same B2B line-haul network to ecommerce deliveries, which is why it appears in a commerce connector catalogue at all.

The parent group's warehousing, fulfilment and 3PL surface is covered separately at /connectors/aaj-enterprise. This page is only about the carrier: rates, serviceability, booking, tracking and POD.

AAJ Swift publishes no developer documentation of any kind. What it does have is a live, production API gateway that backs its own self-serve booking site, and this page documents what could be established about it from the first-party web application and from live probes on 2026-09-22.

At a glance

What it is

AAJ Swift is a carrier, not an aggregator and not a marketplace. It moves B2B part-truck-load freight door to door across India and, more recently, ecommerce parcels over the same network. Its own site names the goods categories it carries: healthcare and orthopaedic products, D2C and marketplace seller goods, cosmetics, electronics, industrial equipment, publishing, automotive parts, apparel and home decor. City landing pages exist for Delhi, Mumbai, Kolkata, Ghaziabad, Bangalore, Hyderabad, Chennai and Sonipat, which is a reasonable proxy for where its hubs sit.

The parent, AAJ Enterprises, describes itself as a full-stack supply chain partner with more than 200 brand customers, over 1 million square feet across 12 or more locations, 20,000 or more pincodes served and roughly 36,000 tonnes shipped annually as of financial year 2025-26. Warehousing, dark stores, omnichannel fulfilment and the group technology stack belong on the parent page at /connectors/aaj-enterprise rather than here.

The seller-facing flow AAJ Swift advertises is: check price, see a promised delivery date before booking, book, have the shipment picked up, track in real time, and pull the POD online afterwards. That flow is implemented on the public website by the API described below, which is the most useful fact on this page.

API access

There is no published API programme. Specifically:

• No developer portal, no API reference, no OpenAPI or Swagger document, no Postman collection, no SDK and no integration page. The site's full sitemap is 109 URLs, of which all but nineteen are blog posts, and none is developer material.
• api.aajswift.com is a CNAME to aaj-prod-apigateway.azure-api.net, which is Azure API Management. A request to the gateway root returns Azure's own { "statusCode": 404, "message": "Resource not found" }, confirming a live APIM instance. The matching Azure developer portal hostname does not resolve, so the self-service subscription surface that APIM can provide has not been switched on publicly.
• docs.aajswift.com, developer.aajswift.com, portal.aajswift.com, track.aajswift.com and crm.aajswift.com all resolve through what looks like a wildcard to the same Azure Web App, which serves a React application whose own meta description reads "Saas based application for Warehouse". That is the group's WMS, not documentation.
• AAJ Swift does not appear in ClickPost's public carrier list, which is a useful negative: the usual Indian aggregators have not published a certified integration for it.
• No API version, deprecation policy or changelog exists. The only version marker anywhere is the V1 suffix on the tracking route.

Authentication

Not published. What follows is observed behaviour of the first-party web client and of live probes, not documentation.

The web client selects one of four credential modes per call:

1. retail unauthenticated. Sends a static authkey header. Used for the public rate calculator and serviceability lookups.
2. retail authenticated. Sends the same static authkey plus Authorization: Bearer <token>, where the token is held in browser local storage under the key retailToken. This is the mode used for booking detail and tracking.
3. tms . Sends the static authkey plus a second static appKey header. This is the transport management lane.
4. apisetu. Sends X-APISETU-CLIENTID and X-APISETU-APIKEY against the Government of India API Setu platform, with a client identifier of com.aajscm. This is identity and GST verification during onboarding, not a shipping API.

The customer login sequence is a two-step mobile OTP exchange:

1. POST /retail/api/Auth/authenticatemobile with a mobile number. A live probe with an empty body on 2026-09-22 returned an ASP.NET Core validation problem naming the required field, which confirms both the route and the field name.
2. POST /retail/api/Auth/authenticatemobilewithotp exchanges the OTP for the bearer token that the client stores as retailToken.
3. POST /retail/api/Auth/validateProfile checks the profile state after login.

curl -X POST https://api.aajswift.com/retail/api/Auth/authenticatemobile \
  -H 'Content-Type: application/json' -d '{}'

  #  HTTP 400, ASP.NET Core problem details:
  #  {"errors":{"MobileNumber":["The MobileNumber field is required."]},
  #   "type":"https://tools.ietf.org/html/rfc7231#section-6.5.1",
  #   "title":"One or more validation errors occurred."}

Token lifetime, refresh, scopes and how a third party would be issued credentials at all are entirely unpublished. Multi-account handling is unknown; the observed model is one logged-in consignor per token, with api/Consignor/GetConsignorProfiles returning the profiles attached to that login.

Objects we can read

All routes below were read from the first-party bundle and then probed live on 2026-09-22. Request and response schemas are not published; only the envelope and a few field names could be confirmed without credentials.

The common response envelope on the /retail/ lane is PascalCase and does not use HTTP status codes to signal failure. A malformed request returned HTTP 200 with:

{
  "Message": "Response status code does not indicate success: 400 (Bad Request).",
  "IsSuccess": false,
  "ResultSet": null,
  "CacheValue": null,
  "MessageCode": ""
}

Branch on IsSuccess, read the result from ResultSet, and note that the gateway passes an upstream error through as a string rather than a code. Authenticated routes do use real status codes: {"message":"Unauthorized"} with HTTP 401.

Orders

There is no sales order object. The booking is the unit of work, read back through api/bookshipment/getbookingdetail. Its schema is not published and could not be captured without credentials.

Order items

Not observed. A PTL booking is expressed in boxes and weight rather than line items, so item detail may not exist at all on this API.

Products and listings, Inventory

None. AAJ Swift is a carrier and holds no catalogue or stock. The group's warehouse SaaS holds inventory, and that belongs on /connectors/aaj-enterprise.

Shipments and tracking

api/BookShipment/TrackBookingV1 is the tracking route. The tracking page's client code uses the parameter name DocketNo and builds a shareable link with a ?trackingNumber= query string, so the shipment key is the AAJ docket number. The response schema, the status vocabulary and whether a full scan history is returned or only a latest state are all unknown: the route requires credentials and no sample exists in the bundle.

Returns and cancellations

Not observed. No cancel route, no reverse pickup route, no RTO route and no NDR route appear in the web client. For a PTL carrier that is plausible, since returns are usually handled as a fresh booking in the reverse direction, but it must be confirmed.

Payments and settlements

Not observed. No COD, remittance, invoice or wallet route appears. AAJ Swift markets itself on B2B freight rather than COD ecommerce, so COD may not be part of the product; confirm before assuming it.

Proof of delivery

"Digital POD Access" and "Access PODs Online" are advertised on the home page as core features, and POD availability is a real differentiator for a PTL carrier where the signed delivery challan is the billing evidence. No POD endpoint appears in the public web client, so POD is presumably behind the customer login on the portal. Getting a POD retrieval route is the single most valuable thing to ask AAJ Swift for.

Locations

Pickup and delivery addresses are captured inside the booking. api/Consignor/GetConsignorProfiles returns the consignor profiles on an account, which is the nearest thing to a saved locations list. No dedicated location create, list or update route was observed.

Writing back: listings, price and stock

Not applicable, this is a carrier. AAJ Swift holds no catalogue, price or stock, so there is nothing to write listings, price or stock to.

The write path is the booking lifecycle, and it is narrow:

• POST api/bookshipment/CreateBookShipment creates a booking. The public flow that precedes it is rate calculation then serviceability check, and the site promises a delivery date at booking time, so the create response very likely carries a docket number and a promised date. Neither is confirmed.
• POST api/bookshipment/updatebookShipment amends an existing booking.
• POST api/bookshipment/Addbookingratings attaches a service rating, which is feedback rather than fulfilment.

No cancellation route, no pickup request route, no manifest route and no label or waybill generation route was observed. On a PTL carrier the label is often produced by the pickup crew rather than the shipper, which would explain the absence, but it needs confirming: a connector that cannot print a docket label cannot hand a consignment over unattended.

Webhooks and notifications

None. No callback registration, no event subscription, no signature scheme and no event list exists in any published or observed material. The web client is entirely request and response.

Poll instead, once credentials exist:

• api/BookShipment/TrackBookingV1 by docket number, one call per open consignment.
• PTL freight moves on a slower clock than parcel. Every 2 to 4 hours while a consignment is in transit is proportionate, daily once it is delivered pending POD, and stop once POD is retrieved. Do not poll at parcel cadence: there is no published rate limit and no quota header to warn us before a gateway policy bites.
• Because no event history has been confirmed, store every distinct state we observe so a timeline can be reconstructed regardless of what the route returns.

Rate limits and pagination

Neither is published, and neither could be established by probe.

The gateway is Azure API Management, which means a rate limit or quota policy may well be configured server side even though nothing is documented, and APIM rejects over-quota calls with HTTP 429 and its own JSON error body. Assume a throttle exists, handle 429 with exponential backoff, and settle the real numbers with AAJ Swift before any bulk run.

No pagination model was observed on any route. Every observed call is a single-record operation keyed on a docket number, a booking identifier or an account, so there is no list endpoint to page through and no way to reconcile our records against AAJ Swift's from the API alone.

Mapping to the unified model

Provisional. Field names below are the ones observed in the first-party client; everything marked as not confirmed needs a real response to pin down.

Gaps and open questions

• There is no published API and no published route to credentials. Everything here comes from AAJ Swift's own web client, which is not a contract. A partner conversation is the required first step, and it should start by asking whether a documented partner API exists privately.
• No request or response schema could be captured for any route that matters: booking create, booking detail and tracking all require credentials.
• The tracking status vocabulary is unknown, and so is whether tracking returns a full scan history or only a latest state.
• Proof of delivery is marketed prominently but has no observed endpoint. This is the highest-value thing to ask for.
• No cancel, no pickup request, no manifest and no label route was observed. Confirm how a consignment is handed over and who produces the docket label.
• No COD, remittance or settlement surface was observed. Confirm whether COD is offered at all on the ecommerce line.
• No returns, RTO or NDR surface was observed.
• No rate limits, no quota headers and no pagination. Azure API Management may be enforcing policies invisibly, so expect HTTP 429 without warning.
• No sandbox. Any test booking would be a real consignment.
• The /retail/ lane returns HTTP 200 with IsSuccess: false for upstream failures, which means naive status-code handling will silently record failures as successes.
• Static credentials are shipped to browsers in the public bundle, which is a security observation to raise rather than a mechanism to rely on. Per-integrator keys would be needed.
• AAJ Swift is absent from ClickPost's carrier list, so no aggregator shortcut exists today. Whether Unicommerce, EasyEcom or Shiprocket carry it privately was not established.

Sources

• aajswift.com home page and sitemap, read 2026-09-22. Service description, PTL and ecommerce positioning, digital POD, delay compensation, city coverage and the 109-URL site inventory.
• AAJ Swift's own first-party JavaScript bundles, in particular /_next/static/chunks/app/shipment-tracking/page-26df36c4ad0e8380.js and the shared vendor chunks, read 2026-09-22. Source of the API base host, the /retail/ and /tms/ route prefixes, all thirteen route names, the four credential modes and the DocketNo tracking parameter.
• Live probes of https://api.aajswift.com on 2026-09-22: the gateway root returning Azure API Management's { "statusCode": 404, "message": "Resource not found" }, POST /retail/api/Auth/authenticatemobile returning an ASP.NET Core validation problem naming MobileNumber, POST /retail/api/Validate/ValidatePostalCodeServiceable and POST /retail/api/Consignor/GetConsignorProfiles returning the IsSuccess envelope, and POST /retail/api/calculation/calculationshipmentcost and POST /retail/api/bookshipment/getbookingdetail returning HTTP 401.
• DNS lookups on 2026-09-22 showing api.aajswift.com delegated to aaj-prod-apigateway.azure-api.net, and docs, developer, portal, track and crm under aajswift.com all pointing at the group's Azure Web App.
• aajenterprises.com, read 2026-09-22, for the parent group's scale figures. Covered in full at /connectors/aaj-enterprise.
• ClickPost sitemap, checked 2026-09-22: no AAJ carrier page, so no aggregator has published a certified integration.