How can I track Delhivery and Blue Dart shipments?

To track both Delhivery and Blue Dart shipments programmatically, developers typically have two architectural options: integrate directly with each carrier's developer portal using separate client libraries and credentials, or query both networks through a normalized multi-carrier tracking API like ClearTrack AI. Most fast-growing Indian e-commerce merchants and logistics aggregators use both carriers concurrently, allocating urgent express orders to Blue Dart and bulk surface or cash-on-delivery consignments to Delhivery.

This guide explains how Delhivery and Blue Dart tracking protocols differ, why maintaining dual direct integrations creates technical overhead, and how to query both couriers through a unified REST API endpoint returning consistent JSON payloads.

Why Indian Shippers Split Volume Between Delhivery and Blue Dart

In domestic Indian e-commerce fulfillment, logistics managers rarely rely on a single 3PL. Delhivery and Blue Dart specialize in distinct transport modes and delivery profiles, making dual-courier fulfillment standard across retail brands:

While splitting volume optimizes freight costs and fulfillment speeds, it fragments tracking data across two distinct systems, requiring operations teams to query different dashboards and development teams to maintain parallel API connectors.

Direct Integration Challenges: Delhivery vs Blue Dart

Building separate custom integrations for both couriers introduces three major technical hurdles:

1. Commercial Account Dependencies: Direct carrier developer APIs are generally offered to contracted commercial shippers. Obtaining developer credentials requires separate business onboarding, customer account codes, and enterprise sales verification with each provider.
2. Disparate Authentication and Headers: Delhivery uses API tokens passed in custom request headers or query parameters. Blue Dart systems require customer license keys, account credentials, and distinct request headers, forcing developers to build separate client wrappers.
3. Incompatible Status Enums: Neither carrier shares a common vocabulary for checkpoint milestones. An in-transit scan might be logged as In Transit or Dispatched by one courier, while the other records hub-specific scan remarks. Writing and maintaining regex rules to translate these strings into internal order statuses is ongoing work.

Comparison: Delhivery vs Blue Dart Tracking Specifications

The table below highlights the technical differences between Delhivery and Blue Dart tracking endpoints, along with how ClearTrack AI unifies them into a single REST interface:

Querying Delhivery and Blue Dart in ClearTrack AI

ClearTrack AI standardizes carrier queries into a single REST endpoint pattern: GET /v1/track/:carrier/:awb. By supplying the carrier parameter (delhivery or bluedart) alongside the tracking number, you query either network using one API key.

1. Querying a Delhivery Consignment

Submit a GET request with your API key to query a Delhivery waybill:

curl -s -H "X-API-Key: YOUR_API_KEY" \
  "https://api.cleartrackpromise.in/v1/track/delhivery/9990001112233"

2. Querying a Blue Dart Consignment

Use the identical URL pattern with the bluedart carrier slug:

curl -s -H "X-API-Key: YOUR_API_KEY" \
  "https://api.cleartrackpromise.in/v1/track/bluedart/7890123456"

Production TypeScript Integration Example

Below is a complete TypeScript module demonstrating how to track a batch of mixed Delhivery and Blue Dart shipments. It queries each consignment, extracts normalized milestone dates, and inspects delay metrics:

interface UnifiedShipment {
  carrier: string;
  trackingNumber: string;
  status: string;
  statusText: string;
  isDelivered: boolean;
  isStuck: boolean;
  hoursSinceLastScan: number | null;
  originCity?: string;
  destinationCity?: string;
}

async function fetchShipmentStatus(carrier: "delhivery" | "bluedart", awb: string, apiKey: string): Promise<UnifiedShipment> {
  const endpoint = `https://api.cleartrackpromise.in/v1/track/${carrier}/${awb}`;
  const res = await fetch(endpoint, {
    method: "GET",
    headers: { "X-API-Key": apiKey }
  });

  if (!res.ok) {
    throw new Error(`Tracking request failed for ${carrier} [${awb}]: HTTP ${res.status}`);
  }

  const payload = await res.json();
  return {
    carrier: payload.carrier,
    trackingNumber: payload.tracking_number,
    status: payload.status,
    statusText: payload.status_text,
    isDelivered: payload.is_delivered,
    isStuck: Boolean(payload.insights?.is_stuck),
    hoursSinceLastScan: payload.insights?.hours_since_last_scan ?? null,
    originCity: payload.origin?.city,
    destinationCity: payload.destination?.city
  };
}

// Example batch tracking mixed consignments
const ordersToTrack = [
  { carrier: "delhivery" as const, awb: "9990001112233" },
  { carrier: "bluedart" as const, awb: "7890123456" }
];

for (const order of ordersToTrack) {
  try {
    const result = await fetchShipmentStatus(order.carrier, order.awb, "YOUR_API_KEY");
    console.log(`[${result.carrier.toUpperCase()}] ${result.trackingNumber}: ${result.status} (Stuck: ${result.isStuck})`);
  } catch (err: any) {
    console.error(err.message);
  }
}

Standardized JSON Response Structure

Regardless of whether the consignment originated with Delhivery or Blue Dart, ClearTrack AI returns an identical JSON response format:

{
  "tracking_number": "9990001112233",
  "carrier": "delhivery",
  "status": "in_transit",
  "status_text": "In Transit: Dispatched to sorting hub",
  "is_delivered": false,
  "is_rto": false,
  "origin": {
    "city": "Gurugram",
    "state": "Haryana",
    "pincode": "122001"
  },
  "destination": {
    "city": "Bengaluru",
    "state": "Karnataka",
    "pincode": "560034"
  },
  "first_scan_at": "2026-10-18T08:30:00.000Z",
  "last_known_location": "Bhiwandi Sorting Center",
  "last_updated_at": "2026-10-19T14:15:00.000Z",
  "cached": true,
  "stale": false,
  "milestones": {
    "booked_at": "2026-10-18T08:30:00.000Z",
    "picked_up_at": "2026-10-18T11:00:00.000Z",
    "in_transit_at": "2026-10-18T14:20:00.000Z",
    "out_for_delivery_at": null,
    "delivered_at": null
  },
  "insights": {
    "transit_days_elapsed": 1.2,
    "hours_since_last_scan": 4.8,
    "is_stuck": false,
    "requires_attention": false,
    "current_stage": "in_transit"
  }
}

Handling Delivery Exceptions and NDR Verification

When an out-for-delivery attempt fails, both Delhivery and Blue Dart record non-delivery reports (NDRs) in their checkpoint history. Common failure reasons include customer unavailability, incorrect delivery address, customer refusal to pay cash-on-delivery amounts, or OTP verification failures at the doorstep.

Direct carrier payloads log disparate failure codes and unstructured remark strings. ClearTrack AI parses these remarks into a normalized delivery_attempts object containing the overall attempt count, exact attempt timestamps, and standardized reason categories. This enables engineering teams to trigger automated customer outreach workflows (such as an automated WhatsApp or SMS confirmation) immediately upon the first failed attempt, helping reduce return-to-origin (RTO) rates. To review standardized non-delivery reason classifications, read our guide on NDR reason codes.

Recommended Polling Cadence and Cache Invalidation

When polling tracking endpoints for open shipments across both Delhivery and Blue Dart, applying an adaptive polling frequency prevents unnecessary requests while ensuring customer tracking pages remain fresh:

• In Transit: Poll active shipments every 4 to 6 hours. Upstream hubs typically scan parcels only during departure and arrival sortation.
• Out for Delivery: Increase polling frequency to once every 1 to 2 hours during local business hours to capture final delivery confirmations promptly.
• Terminal Milestones: Once a shipment transitions to delivered or rto, cease polling entirely. ClearTrack AI caches terminal states permanently.

In ClearTrack AI, in-transit responses are cached for up to 30 minutes, protecting your application from upstream rate limits and burst traffic spikes.

Automated Delay and Stuck Shipment Detection

A major operational challenge when managing both Delhivery and Blue Dart packages is identifying dormant shipments before customers submit complaints. Indian domestic packages can stall between intermediate hubs due to transshipment delays, missed scans, or regional sorting bottlenecks.

Neither Delhivery nor Blue Dart provides a proactive inactivity flag in raw tracking payloads. ClearTrack AI addresses this by analyzing checkpoint timestamps on every lookup. If an active shipment in the in_transit stage registers no new scan event for more than 72 hours, the API automatically populates:

• insights.is_stuck = true
• insights.requires_attention = true
• insights.hours_since_last_scan reflecting elapsed inactivity

By querying active shipments daily and filtering for insights.requires_attention === true, customer support teams can escalate stalled packages directly with carrier account managers before customers reach out. To learn more about setting up inactivity detection workers, see our guide on detecting stuck shipments.

Carrier Integration References

Explore dedicated integration documentation, carrier-specific scan remark tables, and AWB specifications:

Frequently Asked Questions