Enrichment · Address · India

Skip the address form.

The address step is where checkouts die — 60–90 seconds of typing on a mobile keyboard, full of typos. Address Auto-fill turns a verified phone number into a complete, structured delivery address in a single server-side call. No form. No typing. No abandonment at the one step that costs you the order.

Talk to our team See how it works
India coverage· Consent-driven· One API call · no SDK
Address Lookup · Checkout Live
Verified number +91 70699 14791
Coverage check Fetching address… Address pre-filled POST /v1/address/exists Consent confirmed · /address/locate 6 fields · ready to confirm
First name Priya
Last name Sharma
Address line 1 14, Sector 18, Noida
Address line 2 Near City Centre Mall
City · State Noida · Uttar Pradesh
PIN code 201301
mobileMd5 sent · raw number never leaves the device Data Provider validating consent… Pre-filled · user can confirm or edit
6
Fields pre-filled
1
Server-side API call
~90s
Typing removed at checkout
0
Address typos & failed deliveries
The problem

The address form is where checkouts die.

For a returning shopper, the address screen asks for information they've already given someone else — and makes them re-type it on a phone keyboard at the exact moment they're ready to pay. Address Auto-fill removes the step entirely, for everyone who's in the network.

The cost of typing

What the manual address form costs you

  • 60–90 seconds of typingHouse number, street, locality, city, state, PIN — on a mobile keyboard.
  • Abandonment at peak intentThe form lands right when the user is ready to pay — and many drop.
  • Typos and failed deliveriesA wrong PIN or missing landmark turns into an RTO and a support ticket.
  • Re-entering known informationThe same address the user has typed into a dozen other apps already.
What changes

What Address Auto-fill gives you instead

  • A pre-filled address in one callName, address, city, state, and PIN returned structured and ready.
  • Consent-driven by designNothing is returned until the user accepts a consent notice.
  • The raw number never leavesLookups key on mobileMd5 — a hash, not the phone number.
  • The user stays in controlThey confirm or edit the pre-fill — and manual entry is always the fallback.
The flow

Verified number in. Pre-filled address out.

Four steps, all server-side. Authenticate the user, check coverage on a hash of the number, ask for consent, then fetch and pre-fill. The address never moves without the user's say-so.

STEP 01
Authenticate the user
OTPless verifies the phone number. You now hold a verified number — no extra step to use it here.
verified MSISDN
STEP 02
Check if an address exists
Hash the number to mobileMd5 and check coverage before you show anything.
/address/exists
STEP 03
Ask for consent
If an address exists, show a consent notice with your T&C. The Data Provider validates consent independently.
consent notice
STEP 04
Fetch & pre-fill
After consent, call locate and pre-fill the form. Let the user confirm or edit before they pay.
/address/locate
Always render a standard address-entry form as the fallback. Address Auto-fill reduces friction for users in the network — it should never block users who aren't. If addressExists is false, fall straight through to manual entry.
The API

Three operations on one number.

Each endpoint does one thing well. Check coverage, fetch the full address with consent, or clean up a raw address string into a structured form. All three authenticate with your server-side clientId and clientSecret.

Call first
POST /v1/address/exists

Coverage check

A lightweight server-side check that returns whether an address record exists for the mobileMd5 hash. Returns addressExists: false when the number isn't in the network — your cue to fall back to manual entry before showing any consent prompt.

Consent-gated
POST /v1/address/locate

Full address fetch

Returns the complete structured address — only after the user accepts consent. Pass mobileMd5, purpose, details, and tncUrl, plus optional consentDurationInDays and userIp.

No phone needed
POST /v1/address/standardize

Normalize a string

Takes any raw address string and returns it in a clean, structured form via Shiprocket. Useful for tidying user-supplied addresses before you store them — works on any text, no phone number required.

Attribute /address/exists /address/locate /address/standardize
InputmobileMd5mobileMd5 + consentraw address string
Needs consentNoYesNo
Needs phone numberYes (hashed)Yes (hashed)No
ReturnsaddressExistsFull addressStructured address
When to callBefore consentAfter consentAnytime
Privacy by design

Consent-first. Hash-keyed.

Address data is personal, so the API is built so it can't move without the user's explicit agreement — and so the raw phone number never has to travel on the wire.

The number stays hashed

Every lookup keys on mobileMd5 — the MD5 hash of the 10-digit number, no country code. Computing it client-side keeps the raw phone number out of the request entirely.

Consent is enforced, not assumed

You confirm an address exists, show the user a consent notice with your tncUrl, and only then call locate. The Data Provider independently validates that consent before returning any data.

Scoped, time-bound access

Each request carries a purpose and an optional consentDurationInDays, so access is tied to a stated reason and a window — not an open-ended grant.

Where it pays off

Built for the moment before payment.

E-commerce checkout pre-fill

Pre-fill the shipping step the instant the user authenticates. Fewer fields to complete before placing the order means fewer drop-offs at the most valuable moment in the funnel.

Quick commerce

In time-sensitive delivery flows, every removed keystroke matters. Eliminating address entry lifts order completion when the user just wants their order placed and on its way.

New-user onboarding

Populate a delivery-address profile on a user's very first visit — before they've ever typed an address into your app — so their first order is as smooth as their tenth.

Address validation

Cross-reference a user-supplied address against the one tied to their verified number to flag inconsistencies — catching errors and risk before a parcel ever ships.

Integration

Hash the number. Check, consent, locate.

A REST API with no SDK — one server-side call per checkout attempt. Compute the hash from the verified number, confirm coverage, then fetch the address after the user consents.

address-lookup.js node · server 
import crypto from 'crypto'

// verified number from OTPless auth — 10 digits, no country code
const mobileMd5 = crypto
    .createHash('md5')
    .update('7069914791')
    .digest('hex')

// 1. Coverage check — no consent needed
const { addressExists } = await post('/v1/address/exists', { mobileMd5 })
if (!addressExists) return showManualForm()   // fallback

// 2. Show consent notice → on accept, fetch the address
const address = await post('/v1/address/locate', {
    mobileMd5,
    purpose: 'checkout_prefill',
    tncUrl:  'https://shop.example/terms',
    consentDurationInDays: 30
})

prefillCheckout(address)   // user confirms or edits
// headers  clientId: '••••'  clientSecret: '••••'
POST /v1/address/locate
210ms
request · hashed identifier
mobileMd5b1a9…f7c2
purposecheckout_prefill
consentACCEPTED
response · address
fnamePriya
lnameSharma
address114, Sector 18, Noida
address2Near City Centre Mall
cityNoida
stateUttar Pradesh
pincode201301
source: logistics network latency: 210ms
Frequently asked

Common questions.

What is mobileMd5 and why do I need to compute it?
It's the MD5 hash of the 10-digit phone number without a country-code prefix. All address lookup calls use it as the identifier instead of the raw number. Computing it keeps the actual phone number out of the request, so personal data never travels on the wire.
Does the user need to give consent before their address is returned?
Yes. The /address/locate call is consent-driven. You first confirm an address exists with /address/exists, show the user a consent notice with your terms-and-conditions URL, and only call locate after they explicitly accept. The Data Provider independently validates that consent before returning any data.
What happens if no address is found for the phone number?
/address/exists returns addressExists: false. Handle this gracefully by falling back to a standard address-entry form so the user can type their address manually. Address Auto-fill should reduce friction for users in the network — never block users who aren't.
Is the Address API available globally?
No — it's currently available for India only. Coverage queries Indian logistics and fulfilment networks such as Delhivery and Shiprocket, and is highest for users who've shopped on major e-commerce or quick-commerce platforms. Numbers not present in these networks return an empty result.
What does the standardize endpoint do?
/address/standardize takes a raw address string and returns it in a normalized, structured format via Shiprocket. It doesn't require a phone number — it works on any address text you provide, which is useful for cleaning and formatting user-supplied addresses before you store them.
Do I need the device SDK to use this?
No. The Address API is a server-side REST API authenticated with your clientId and clientSecret headers — distinct from the appId used by device SDK endpoints. It pairs naturally with OTPless Authentication, which produces the verified number you hash into mobileMd5, but the lookup itself is one server-side call with no SDK.
Pre-fill the address

Stop making users type an address you can already fetch.

A verified number in, a structured address out — consent-gated and India-wide. Talk to us about adding address pre-fill to your checkout.

Talk to our team Read the docs
India coverage · Consent-driven · hash-keyed