Blue Dart

Blue Dart API: Apigee gateway with a ClientID and clientSecret login returning a 24 hour JWT, waybill generation and cancellation, pincode finder, pickup and tracking.

Blue Dart Express is India's premium air express carrier, majority owned by DHL, and the carrier a seller picks when the shipment is time sensitive, high value or headed somewhere the surface networks reach slowly. For a commerce database it is a carrier connector: no orders, no listings, no stock. What it gives us is serviceability and transit time for a destination pincode, a waybill number and a printable label when we book, a pickup registration, and a scan by scan tracking history. The modern API sits behind an Apigee gateway at apigateway.bluedart.com, uses a short lived JWT, and its reference documentation is behind a client login, so this page is built from what the live gateway itself confirms plus what production integrations show.

At a glance

Warning

Blue Dart's API reference is not public. Everything below that is not marked as verified live should be treated as a strong hypothesis to confirm against the documentation pack your Blue Dart account manager sends, before you write the connector. In particular, two independent production integrations disagree about whether the token travels as a JWTToken header or as Authorization: Bearer; the JWTToken header is the better supported of the two.

What it is

Blue Dart Express Limited was founded in 1983 and has been part of the DHL Group since 2005, trading on the NSE and BSE with DHL holding the majority. It operates Blue Dart Aviation, its own dedicated freighter fleet, which is the structural reason it can promise next morning delivery across a large part of India when surface carriers cannot. It covers roughly 56,000 locations domestically and reaches over 220 countries through the DHL network.

Positioning matters for how you will meet it in a seller's stack. Blue Dart is the premium option, priced accordingly, and is rarely a D2C brand's default carrier for low value parcels. It appears as the carrier for high value orders, for documents and for service level agreements that require air. Most small sellers reach it through an aggregator rather than directly: it carries courier_company_id 1 (Blue Dart) and 55 (Blue Dart Surface) inside Shiprocket, for instance, and similar identifiers inside every other aggregator. A direct Blue Dart integration implies a contracted account with real volume.

Products are named rather than numbered in the API: A for Apex (domestic priority air), D for Dart Apex, E for Express, with a sub product code distinguishing prepaid from cash on delivery variants. Confirm the exact code set for your contract, because the available products differ per account.

API access

There is no console, no signup and no free tier. The path is:

  1. Open a contracted Blue Dart account through a Blue Dart sales contact. You get a customer code and a contracted rate card.
  2. Ask for NetConnect API access. You receive a LoginID and a LicenceKey. These are the legacy NetConnect credentials and they are still required: they travel inside the request body of the modern JSON API, not just the old SOAP one.
  3. Ask for Apigee gateway credentials. You receive a ClientID and a clientSecret, which are what the token endpoint checks.
  4. Blue Dart provides the API documentation pack and the sandbox at apigateway-sandbox.bluedart.com at this point. Both hosts are live and respond identically to unauthenticated probes.

Verified live on 2026-09-22 by probing the gateway: exactly five API families are deployed under https://apigateway.bluedart.com/in/transportation/.

Anything outside those five (for example ewaybill, master, rate, booking) returns 404 from the gateway, so there is no rate quotation API and no settlement API on this gateway. Rates come from your contracted rate card, not from a call.

There are no official Blue Dart SDKs.

Authentication

Two credential pairs, used in two different places, which is the part people get wrong.

  1. GET https://apigateway.bluedart.com/in/transportation/token/v1/login with the headers ClientID and clientSecret.
  2. The response body is {"JWTToken": "<jwt>"}. Verified live: the endpoint responds, and the token it issues is an HS256 JWT whose exp minus iat is exactly 86400 seconds, so the token is valid for 24 hours.
  3. Send JWTToken: <jwt> as a request header on every business call. The gateway rejects a missing or invalid token with HTTP 401 and a body of {"status":401,"title":"Unauthorized","error-response":[{"msg":"Access to the method is not allowed."}]}.
  4. Additionally include a Profile object inside every request body, carrying LoginID, LicenceKey and Api_type. The gateway authenticates the caller; the profile authenticates the Blue Dart account the shipment belongs to.
curl -s 'https://apigateway.bluedart.com/in/transportation/token/v1/login' \
  -H 'ClientID: <your-client-id>' \
  -H 'clientSecret: <your-client-secret>'
curl -X POST 'https://apigateway.bluedart.com/in/transportation/waybill/v1/CancelWaybill' \
  -H 'Content-Type: application/json' \
  -H 'JWTToken: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...' \
  -d '{
        "Request": { "AWBNo": "12345678901" },
        "Profile": { "LoginID": "XXX00000", "LicenceKey": "<licence-key>", "Api_type": "S" }
      }'

Renewal is a fresh login; there is no refresh token. Cache the JWT for slightly under 24 hours and re-issue on a schedule rather than on 401, because a 401 from this gateway is ambiguous between an expired token and an unauthorised method.

Multi account: one ClientID and clientSecret pair is one Blue Dart API consumer, one LoginID and LicenceKey pair is one Blue Dart customer account. A platform shipping on behalf of several brands with their own Blue Dart contracts will hold several profiles and, probably, several gateway credentials. Confirm with Blue Dart whether one gateway credential may carry several profiles, because that decides whether your token cache is keyed per tenant.

Objects we can read

Shipments and tracking

GET /in/transportation/tracking/v1/shipment, as a query string rather than a JSON body. The parameter names are inherited from the legacy servlet:

The same query runs against the older host https://api.bluedart.com/servlet/RoutingServlet, which is still live: an unauthenticated call there returns <ShipmentData><Error>License Mismatch. Please contact your system administrator</Error></ShipmentData>, verified on 2026-09-22. That confirms the response root element and the licence based authorisation model, and it means a legacy integration you inherit may not be using the gateway at all.

The response is the XML document expressed as JSON. The shape, as parsed by production integrations:

{
  "ShipmentData": {
    "Shipment": [
      {
        "Status": "SHIPMENT DELIVERED",
        "Scans": [
          {
            "ScanDetail": {
              "Scan": "Shipment Delivered",
              "ScanCode": "000",
              "ScanDate": "22-Sep-2026",
              "ScanTime": "11:42",
              "ScannedLocation": "Mumbai"
            }
          }
        ]
      }
    ]
  }
}

There is no pagination and no "changed since" filter: this is a lookup by waybill number. ScanCode is the structured value, Scan is its label, and ScanDate and ScanTime arrive as two separate strings that you have to join and parse as IST.

Proof of delivery: the delivered scan is what you get. Blue Dart exposes signature images through its customer portal, not through this gateway family.

Pincode serviceability and transit time

Under /in/transportation/finder/v1/. The operation seen in production integrations is GetServicesforPincodeandProduct, taking pPinCode, pProductCode, pSubProductCode and the Profile object, and returning a GetServicesforPincodeandProductResult object with an IsError boolean alongside the service flags for that pincode. A companion transit time operation exists in the same family. Operation names here are from secondary sources only; the family prefix is verified.

Serviceability is the right thing to cache locally. It changes slowly, the finder family is the only pre booking check available, and there is no rate call to pair it with because pricing comes from your contracted rate card.

Orders, listings, inventory, returns, settlements

None. Blue Dart has no order object, no catalogue and no reverse logistics object on this gateway; a reverse shipment is simply a waybill booked in the other direction. COD remittance and freight invoicing are handled through the customer portal and finance files, not through an API.

Writing back: listings, price and stock

Not applicable, this is a carrier. There are no listings, no prices and no stock. The write path is the waybill lifecycle.

Generate a waybill

POST /in/transportation/waybill/v1/GenerateWayBill. The request body is a Request envelope plus the Profile object. Request groups the shipment into Consignee, Shipper and Services sub objects:

{
  "Request": {
    "Consignee": {
      "ConsigneeName": "Ramesh Kumar",
      "ConsigneeAddress1": "12, MG Road",
      "ConsigneeAddress2": "",
      "ConsigneePincode": "411001",
      "ConsigneeMobile": "9876543210"
    },
    "Services": {
      "ProductCode": "A",
      "ProductFor": "P",
      "CreditReferenceNo": "ORD-10231",
      "CustomerCode": "<customer-code>",
      "AreaCode": "",
      "PieceCount": 1,
      "ActualWeight": 0.5,
      "DeclaredValue": 999,
      "CollectableAmount": 0
    }
  },
  "Profile": { "LoginID": "XXX00000", "LicenceKey": "<licence-key>", "Api_type": "S" }
}

A Shipper object carrying the pickup address sits alongside Consignee in the full request; the excerpt above is trimmed to the fields two independent integrations agree on. The response carries AWBNo, the waybill number to store, and AWBPrintContent, the printable label. CollectableAmount is the COD amount, zero for prepaid. CreditReferenceNo is your own order reference and is the only field that joins a Blue Dart waybill back to an order.

Cancel a waybill

POST /in/transportation/waybill/v1/CancelWaybill with {"Request": {"AWBNo": "..."}, "Profile": {...}}. The path is verified live; the body shape comes from a production integration.

Register and cancel a pickup

POST /in/transportation/pickup/v1/RegisterPickup and POST /in/transportation/pickup/v1/CancelPickup, both under the verified pickup/v1/ family. The request carries the pickup date and time window, the pickup address, the expected piece count and weight, and the Profile. A successful registration returns a pickup token you quote when chasing a missed pickup. Field names were not verifiable from a public source.

Webhooks and notifications

None found. The gateway exposes no subscription endpoint, and only five API families are deployed, none of which is a notification family. Blue Dart's own tracking notifications to the consignee (SMS and email) are configured in the customer portal and do not reach your system.

Poll GET /in/transportation/tracking/v1/shipment. Because numbers accepts several waybills, batch them. With no published rate limits, a conservative starting point is 20 to 50 waybills per call at a 30 to 60 minute interval for in flight shipments, and stop polling once a shipment is delivered or returned.

Ask your account manager about a scan feed. Blue Dart does provide file based scan feeds to large clients under separate arrangements, and that is a better answer than polling at volume, but it is not part of this API.

Rate limits and pagination

Neither is published, and neither could be verified without credentials.

  • Pagination: there is none. Every read is a lookup by key.
  • Rate limits: not published. The gateway is Apigee, so per app quota policies are likely and will surface as HTTP 429 with an Apigee shaped error body. Implement backoff and expect to negotiate the quota with your account manager.
  • Token lifetime: 24 hours, verified from the issued JWT's own claims.

Mapping to the unified model

Blue Dart contributes shipments only. orders, order_items, products, listings, inventory, returns, settlements and customers have no source here.

ship_to_address on an order can be enriched from the Consignee block you sent, which is PII. location_id maps to the AreaCode and pickup address you send in the Shipper block; there is no warehouse registry to read.

Gaps and open questions

  • The reference is not public. Operation names, complete field lists, error codes and the product code set all need the documentation pack from your account manager. This page verifies the host, the five families, the login endpoint, the token lifetime and the 401 envelope, and is explicit about everything else being secondary.
  • Two contradictory auth patterns in the wild. One production integration sends JWTToken: <token>, another sends Authorization: Bearer <token>, and a third sends the client credentials as Authorization and Custom-Header on the login call itself. The JWTToken header is the most widely used. Resolve this on day one against the official pack.
  • No rate quotation. There is no rate family on the gateway, so a checkout time price for a Blue Dart shipment has to come from your own copy of the contracted rate card. That card is a spreadsheet, and it drifts.
  • No NDR API. A failed delivery shows up only as a scan. There is no way to defer, re-attempt or edit an address programmatically, unlike Delhivery or Shiprocket. Those actions are portal or phone calls.
  • No settlement or COD remittance API, and no billed weight in any response, so weight disputes cannot be automated from this API alone.
  • Legacy surfaces still live. api.bluedart.com/servlet/RoutingServlet responds and uses licence key authorisation with no JWT. If you are inheriting an integration, check which host it actually calls before assuming it is on the gateway. The older SOAP services under netconnect.bluedart.com/Ver1.9/ and /Ver1.10/ returned 404 and 500 respectively on 2026-09-22, so those WSDL paths appear to have moved or been retired.
  • Sandbox parity unverified. apigateway-sandbox.bluedart.com is live and answers identically to unauthenticated probes, but whether it exposes the same operations and the same data fidelity is unknown without credentials.
  • No webhook. Confirm whether a scan feed can be arranged contractually before committing to a polling design at volume.

Sources

Verified live on 2026-09-22 by direct request:

  • https://apigateway.bluedart.com/in/transportation/token/v1/login: responds, returns {"JWTToken": "..."}, and the issued HS256 token's own claims give a 24 hour lifetime
  • https://apigateway.bluedart.com/in/transportation/{waybill,pickup,finder,tracking}/v1/: deployed, returning HTTP 401 with {"status":401,"title":"Unauthorized","error-response":[{"msg":"Access to the method is not allowed."}]}. ewaybill, master, label, shipment, rate, booking and customer return 404, which bounds the API surface
  • https://apigateway-sandbox.bluedart.com/in/transportation/token/v1/login: live, same 401 envelope
  • https://api.bluedart.com/servlet/RoutingServlet: live, returns <ShipmentData><Error>License Mismatch...</Error></ShipmentData>
  • bluedart.com/api-integration, bluedart.com/developer, bluedart.com/bluedart-api: all 404, confirming there is no public developer portal

Secondary, production integrations read for request and response shapes, all cross checked against each other:

  • Hussyn72/logistics-rest-apis, bluedart/Bluedart_JWT_token_generator_script.php: the login call with the ClientID header and the JWTToken response key
  • shipnick/shipnick_2024, app/Jobs/OrderCancel_BluedartJob.php and app/Jobs/OrderStatusUpdate_Bluedart.php: the CancelWaybill request body, the Profile object with LoginID, LicenceKey and Api_type, the tracking query parameters and the ShipmentData.Shipment[].Scans[].ScanDetail response shape
  • XgeniousLLC/geniusCommerz, app/Services/Carriers/BlueDartCarrier.php: the sandbox host, the JWTToken request header, the GetServicesforPincodeandProduct finder operation and the same Profile object
  • mrshahbazdev/cashflow-cod, packages/couriers/src/adapters/bluedart.ts: the GenerateWayBill request envelope with Consignee and Services, and the AWBNo and AWBPrintContent response fields. This repository also contains mock adapters, so its detail was used only where a second source agreed