Delhivery Maps & Naksha LLM: India's AI Mapping Stack

Every developer who has built for the Indian market knows this problem: our addresses break geocoders. “Near Lajpat Nagar Metro, behind Central Market, gali no 4, Delhi” is crystal clear to any delivery agent and complete noise to Google Maps. For years the workaround was expensive foreign APIs delivering mediocre local accuracy — and quietly eating the cost.

In June 2026, Delhivery changed the equation. It launched Delhivery Maps, an AI-native geospatial platform powered by its in-house Naksha LLM — the same stack that already runs 100% of its own national logistics operation, now opened up as commercial APIs. This is a full, structured breakdown of what it is, how it’s built, and exactly where you’d use it.

1. The Backstory — Why This Exists

Delhivery didn’t build this to sell — it built it out of operational necessity to run India’s largest logistics network, then productised it.
The platform has completely replaced third-party map providers (read: Google) across all four of Delhivery’s businesses: Express Parcel, Part-Truckload Freight, Supply Chain Services, and Delhivery Local (hyperlocal).
Opening the APIs marks Delhivery’s formal entry as a commercial geospatial infrastructure provider — competing directly with Google Maps and MapMyIndia in the Indian logistics segment.
In the words of Kapil Bharati, Executive Director & CTO of Delhivery: they built it to solve for unstructured addresses and commercial routing rules at massive scale, and opening it externally marks their entry as a geospatial infrastructure provider.

Why it matters to you: this isn’t a startup’s v1 demo. It’s proven infrastructure running at national scale before it ever reached your API key.

2. What Is Naksha LLM?

Not one model — a suite of fine-tuned geospatial reasoning models, purpose-built to decode, cleanse, and structure complex Indian addresses.
The key architectural idea: it replaces rigid rule-based databases with dynamic reasoning loops. Instead of “match this string to that record,” the model reasons about what an address most likely means — the way a human sorter would.
This is why it beats traditional geocoders on Indian addresses: landmark-based navigation, colloquial locality names, missing pin codes, and creative spellings are exactly what rule-based systems fail at and what a reasoning model handles.

3. The Data Moat (The Real Differentiator)

Naksha LLM’s edge isn’t the model architecture — it’s the training data almost nobody else has:

2 billion+ historical shipments (200 Cr) used as ground-truth address→location mappings
1 billion+ daily GPS pings (100 Cr) from a live, moving fleet
100,000+ active fleet vehicles generating real road-behaviour telemetry
18,800+ pin codes covered, across 28 states + 8 UTs
3M+ deliveries per day continuously feeding the system

The insight: every failed and successful delivery Delhivery ever made is a labelled data point about what an address actually resolves to. That’s a moat Google structurally cannot replicate in India, because Google doesn’t run the trucks.

4. What Makes It Different From Google Maps

Consumer maps are optimised for a person driving a car to a place. Delhivery Maps is optimised for commercial shipping, which is a different problem:

Vehicle-aware routing: separate speed/behaviour profiles for heavy trucks, autos, and bikes — not just “car.”
Commercial transport restrictions: understands where trucks can and can’t legally go, time-of-day constraints, etc.
Landmark-based navigation: built for how Indian addresses are actually described.
Incomplete-address tolerance: designed to resolve partial inputs instead of failing.
Priced for volume: positioned as enterprise-grade mapping at a fraction of legacy API spend.

5. Naksha LLM vs Google Maps vs MapmyIndia (Mappls)

The three real contenders for Indian location data. Here’s how they stack up for a commercial / logistics use case:

Dimension	Delhivery Maps (Naksha LLM)	Google Maps Platform	MapmyIndia / Mappls
Core approach	Geospatial LLM with dynamic reasoning loops	Global map database + ML	India address directory + ML ranking
Built for	Commercial shipping & last-mile logistics	Consumer navigation (person → place)	Broad: consumer + enterprise + auto
India focus	India-only, native	Global (India is one market)	India-first, deep local data
Training / data edge	2B+ real deliveries, 1B+ daily GPS pings, 100K+ fleet	Global crowd + Street View + traffic	50M+ mapped places, own address directory
Informal/landmark addresses	Core strength — reasons about messy input	Weak on informal Indian addresses	Strong — landmark + eLoc system
Address standardisation	Yes — LLM-driven, fills missing fields	Limited (formatting, not deep cleansing)	Yes — cleansing/normalisation API
Confidence signal	Error radius returned per result	Location type / partial match hints	Geocode-level + confidence score
Vehicle-aware routing	Truck / auto / bike profiles + commercial restrictions	Car/bike/truck (truck limited in India)	Multimodal incl. India-specific modes
Hindi / Indic input	India-tuned models	Supported	Explicit Indic feature
MCP / AI-agent support	Yes — native MCP server, 6 tools	No native MCP	No native MCP
Pricing angle	Fraction of legacy API spend	Premium; $200/mo free credit	Enterprise/tiered, India-competitive
Maturity	New (launched June 2026)	Very mature, global	Mature, India-established

How to read this table:

Pick Delhivery Maps when your problem is Indian logistics — messy addresses, commercial (truck/auto/bike) routing, or you want an AI agent to reason over location via MCP. It’s the newest, so expect less community tooling.
Pick Google Maps when you need global coverage, rich consumer POI data, Street View, or the most battle-tested SDK ecosystem — and Indian address quality isn’t your bottleneck.
Pick MapmyIndia / Mappls when you want deep, established India-specific data (the eLoc digital-address system, Indic support, 3D/immersive maps) with a mature enterprise stack.

My honest read: Naksha LLM’s differentiator isn’t that it’s “better at maps” — it’s the delivery-outcome training data and the native MCP/agent support, both of which the other two structurally lack today. For a greenfield Indian logistics or e-commerce address problem, it’s now a genuine first-choice candidate rather than a fallback.

6. The APIs — What Each Does + Where You’d Use It

6.1 Geocoding

What: Free-form Indian address → precise latitude/longitude.
Smart part: Interprets incomplete/misspelled text, auto-fills gaps, and returns an error radius as a positional-confidence score. India-optimised on billions of delivery addresses.
Use case: At checkout, convert a typed address to coordinates and flag low-confidence ones for verification before the parcel ships — directly cutting failed deliveries and RTOs.

6.2 Reverse Geocoding

What: Coordinates → human-readable address.
Smart part: Multi-level granularity (street → locality → city → state), ranked so the most specific match is primary. Intelligent estimation finds the closest addressable location within a tolerance.
Use case: In a rider app, turn a customer’s dropped GPS pin into a proper address the delivery agent can actually navigate to.

6.3 Address Standardisation (the standout)

What: Messy raw address → clean, validated, structured breakdown.
Smart part: Fixes typos/abbreviations, fills missing fields (pin code, locality), returns normalized components with a complete entity breakdown.
Use case: Cleaning a dirty customer/CRM database — run 50,000 junk addresses through it once and get structured, delivery-ready records. Also the backbone of KYC/address-verification in fintech.

6.4 Routing (Vehicle-Aware)

What: Most efficient path across multiple stops.
Smart part:
- Vehicle profiles: two-wheeler, auto, truck
- Time-aware (traffic by time of day)
- Up to 10 sequential stops
- Modifiers: avoid tolls, avoid highways, or absolute shortest path
- Turn-by-turn guidance
Use case: A quick-commerce ops team planning a rider’s batch of 8 drops by two-wheeler, avoiding tolls, optimised for 9 AM traffic — and getting accurate ETAs to show the customer.

6.5 Distance Matrix

What: N×M grid of travel times + distances across many origin-destination pairs.
Smart part: Asymmetric — respects one-ways and U-turns, so A→B ≠ B→A when the road network dictates. Low-latency, built to feed vehicle-routing optimisation.
Use case: Deciding which of 3 dark stores fulfils an order by true drive-time (not straight-line distance).

6.6 Autosuggest / Auto-Complete

What: Real-time typeahead location predictions as the user types.
Smart part: Fuzzy + partial matching (handles typos), optional geo-bias to surface nearby results first.
Use case: The address field in checkout or ride-booking — user types 3 characters, gets the right locality instantly, fewer wrong entries downstream.

6.7 Map Tiles

What: Raster map tiles in WebP format.
Smart part: Standard slippy-map (z/x/y) addressing — drops into Leaflet, Mapbox GL, or native SDKs.
Use case: A branded fleet-tracking dashboard rendering your own map UI.

7. The MCP Server — Where This Gets Genuinely Modern

Delhivery ships a Model Context Protocol (MCP) server exposing the entire API suite and Naksha LLM as tools your AI agents can call natively. This is the part I find most forward-looking.

No glue code: the agent auto-discovers tools and calls the right one.
Plain-English in, spatial reasoning out.

The 6 exposed tools:

geocode_address
reverse_geocode
standardize_address
route
compute_distance_matrix
auto_suggest

Supported clients: Claude Desktop, Claude Code, Cursor, Kiro.

Endpoint: https://gateway-maps-pub-int.delhivery.com/mcp

Setup in 3 steps:

Get your token — auto-generated from your browser session. Treat it like a password; never commit it to Git.
Paste the config snippet into your MCP client.
Restart the client — the tools appear automatically.

Use case: Ask your agent — “Which warehouse is closest by drive-time to this cluster of 12 stops, and give me the optimised truck route avoiding tolls?” It picks the tools, calls Distance Matrix + Routing, and reasons over the result. Agentic logistics with zero integration code.

8. Hands-On: Code Examples

Heads-up: These are illustrative examples to show the shape of integration. The exact endpoint paths, field names, and auth header format should be confirmed against the official API reference at delhivery.com/maps/reference — treat the snippets below as a starting scaffold, not gospel.

8.1 Geocoding — cURL

curl -X POST "https://gateway-maps-pub-int.delhivery.com/v1/geocode" \
  -H "Authorization: Bearer $DELHIVERY_MAPS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "opp Siddhivinayak Mandir, near Kirti College, Prabhadevi, Mumbai"
  }'

Expected response shape (coordinates + the confidence radius that makes this genuinely useful):

{
  "results": [
    {
      "latitude": 19.0169,
      "longitude": 72.8302,
      "error_radius_m": 70,
      "matched_components": {
        "locality": "Prabhadevi",
        "city": "Mumbai",
        "state": "Maharashtra",
        "pincode": "400025"
      }
    }
  ]
}

8.2 Address Standardisation — cURL

curl -X POST "https://gateway-maps-pub-int.delhivery.com/v1/standardize" \
  -H "Authorization: Bearer $DELHIVERY_MAPS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "no 42 2nd cross 5th blk nr forum mall koramangala blr"
  }'

Expected structured output:

{
  "standardized": {
    "house_number": "42",
    "street": "2nd Cross, 5th Block",
    "landmark": "Near Forum Mall",
    "locality": "Koramangala",
    "city": "Bengaluru",
    "state": "Karnataka",
    "pincode": "560095"
  },
  "corrections": ["expanded abbreviations", "normalised 'blr' to Bengaluru", "inferred pincode"],
  "confidence": 0.92
}

8.3 Node.js (fetch) — same call, in code

const res = await fetch(
  "https://gateway-maps-pub-int.delhivery.com/v1/standardize",
  {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.DELHIVERY_MAPS_TOKEN}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      address: "no 42 2nd cross 5th blk nr forum mall koramangala blr",
    }),
  }
);

const data = await res.json();
console.log(data.standardized);

8.4 MCP Client Config (Claude Desktop / Cursor)

Add this to your MCP config file (e.g. claude_desktop_config.json). Restart the client afterwards and the 6 tools appear automatically:

{
  "mcpServers": {
    "delhivery-maps": {
      "url": "https://gateway-maps-pub-int.delhivery.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN_HERE"
      }
    }
  }
}

For a local/stdio-style client that proxies remote MCP, the equivalent is:

{
  "mcpServers": {
    "delhivery-maps": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://gateway-maps-pub-int.delhivery.com/mcp"],
      "env": {
        "DELHIVERY_MAPS_TOKEN": "YOUR_TOKEN_HERE"
      }
    }
  }
}

Security note: the token is generated from your browser session — keep it in an environment variable or secrets manager, never hard-coded in a committed file.

Once connected, you can just ask your agent in plain English:

“Standardise this address and tell me the pincode: no 42 2nd cross 5th blk nr forum mall koramangala blr”

…and it will call standardize_address and reason over the result — no code required.

9. Who Should Care (Sector-by-Sector Fit)

E-commerce / D2C: Better checkout accuracy → fewer RTOs and failed deliveries.
Quick-commerce / hyperlocal: Dark-store selection, rider batching, accurate ETAs.
Food delivery: Pickup/drop resolution, live routing.
Fintech: KYC and address verification via standardisation.
Ride-hailing / gig economy: Reliable pickup matching; vehicle-specific routing eliminates fare disputes and driver friction.
Supply chain / freight: Truck-legal commercial routing at scale.
AI builders: Native spatial reasoning for autonomous agents via MCP.

10. How to Get Started (Free)

Live playground: Test every API in-browser at the developer portal — no signup, no token, no code. Paste your ugliest address and watch standardisation clean it up.
Free tier: Positioned for academic/research use. Students and researchers can email maps@delhivery.com to request access.
Commercial: Plans and integration support available via “Book a Demo.”
Availability: Live now for commercial integration by enterprises, developers, and gig-economy platforms.

11. Quick FAQ

Is it live? Yes — launched June 2026, available for commercial integration now.
Does it work outside logistics? Yes — e-commerce, fintech KYC, ride-hailing, food delivery, real estate.
Is there a free way to try it? Yes — the in-browser playground needs nothing, and there’s an academic/research free tier.
Can AI agents use it? Yes — via the MCP server, natively, with 6 tools.
Why not just use Google Maps? For Indian addresses and commercial (truck/auto/bike) routing, a model trained on 2B+ real deliveries has a structural accuracy and cost advantage.

12. My Take

This is not a vendor reselling map data — it’s a logistics company productising a stack it already runs at national scale.
The training data is the moat: 2B+ deliveries and 1B+ daily pings are something a pure-software mapping company can’t manufacture.
The dynamic-reasoning-loop approach (vs rigid databases) is the right architecture for India’s informal addressing.
Address Standardisation alone justifies a look for anyone sitting on a messy address database.
The first-class MCP server tells me this team understands where developer tooling is going.
Bottom line: if you build anything touching Indian addresses, logistics, or delivery — put Delhivery Maps on your evaluation shortlist today.

I’m planning to put it through a proper build soon — an address quality scoring experiment for Indian e-commerce — and I’ll publish the results with real numbers. Watch the blog for that follow-up.

Building something that touches Indian addresses or logistics? I work on full-stack and AI systems in exactly this space — reach out via muneebdev.com.

Categorized in:

Delhivery Maps + Naksha LLM: A Deep Dive Into India’s First Delivery-Trained Mapping Stack

1. The Backstory — Why This Exists

2. What Is Naksha LLM?

3. The Data Moat (The Real Differentiator)

4. What Makes It Different From Google Maps

5. Naksha LLM vs Google Maps vs MapmyIndia (Mappls)

6. The APIs — What Each Does + Where You’d Use It

6.1 Geocoding

6.2 Reverse Geocoding

6.3 Address Standardisation (the standout)

6.4 Routing (Vehicle-Aware)

6.5 Distance Matrix

6.6 Autosuggest / Auto-Complete

6.7 Map Tiles

7. The MCP Server — Where This Gets Genuinely Modern

8. Hands-On: Code Examples

8.1 Geocoding — cURL

8.2 Address Standardisation — cURL

8.3 Node.js (fetch) — same call, in code

8.4 MCP Client Config (Claude Desktop / Cursor)

9. Who Should Care (Sector-by-Sector Fit)

10. How to Get Started (Free)

11. Quick FAQ

12. My Take

Comments

Leave a Reply Cancel reply

Previous Article

Why I Picked Sarvam Vision Over OpenAI for DocuBharat

Why I Picked Sarvam Vision Over OpenAI for DocuBharat

3 Database Mistakes I Made Building a Multi-Tenant SaaS in MongoDB

Laravel 13: When to Upgrade and What’s Actually Worth It

Idempotent AI Jobs in Laravel: How to Stop Re-Charging the OpenAI API on Every Retry

Press ESC to close

Or check our Popular Categories...

1. The Backstory — Why This Exists

2. What Is Naksha LLM?

3. The Data Moat (The Real Differentiator)

4. What Makes It Different From Google Maps

5. Naksha LLM vs Google Maps vs MapmyIndia (Mappls)

6. The APIs — What Each Does + Where You’d Use It

6.1 Geocoding

6.2 Reverse Geocoding

6.3 Address Standardisation (the standout)

6.4 Routing (Vehicle-Aware)

6.5 Distance Matrix

6.6 Autosuggest / Auto-Complete

6.7 Map Tiles

7. The MCP Server — Where This Gets Genuinely Modern

8. Hands-On: Code Examples

8.1 Geocoding — cURL

8.2 Address Standardisation — cURL

8.3 Node.js (fetch) — same call, in code

8.4 MCP Client Config (Claude Desktop / Cursor)

9. Who Should Care (Sector-by-Sector Fit)

10. How to Get Started (Free)

11. Quick FAQ

12. My Take

Comments

Leave a Reply Cancel reply

Related Articles

Previous Article