"When will it arrive?" is the single biggest question a shopper asks before hitting Buy Now. If your product page doesn't answer it, they'll either abandon the cart or wait to compare with a competitor who does.

The Estimated Delivery Date (EDD) widget in ILS shows a clear delivery promise right next to the buy button — using your own delivery rules, the shopper's pincode, and your warehouse location.

Important to know upfront: ILS's EDD is a rule-based, merchant-configured widget. It calculates the promised date from the settings you define (default days, distance slabs, zones, cutoff time, holidays). It does not call the courier's API in real time. That's a deliberate design choice — see the next section for why that actually works in your favor.

Why Merchant-Configured EDD Beats "Live Courier API" EDD

A lot of shipping tools brag about pulling delivery estimates live from courier systems. That sounds fancy, but in India it comes with problems ILS deliberately avoids:

1. You own the promise — not the courier. Couriers change their SLAs quietly. A "2-day" API estimate today can become "5 days" tomorrow with no warning to you. With ILS, you control the number your customer sees.

2. Zero downtime. Courier APIs go down. Rate limits kick in. Pincode databases lag. When any of that happens on a live-API tool, the widget breaks — or worse, shows nothing on your product page during peak shopping hours. ILS EDD is a local calculation. It never breaks.

3. Blazing fast. No external API round-trip means the delivery date appears instantly as the shopper types the pincode. On mobile, that speed difference is the difference between a conversion and a bounce.

4. Consistent across couriers. If you use Delhivery for one region and Bluedart for another, live-API EDD gives you two different promises for the same pincode. Customers get confused. ILS EDD shows one promise you've committed to — regardless of which courier eventually ships it.

5. Under-promise, over-deliver. You set a slightly padded date (say, 4 days when the average is 3). If the courier delivers on Day 3, the customer is delighted. Live-API estimates show best-case courier times — leaving you no buffer, so on-time delivery becomes late delivery.

6. Works even for manifest-first workflows. If you ship in bulk once a day, real-time courier estimates are wrong anyway — they assume immediate pickup. ILS lets you bake dispatch cycles into the promise.

The right mental model: ILS EDD is your delivery commitment, not a courier's guess. That's a stronger promise — and stronger promises convert better.

What Your Customer Actually Sees

Scenario A — Standard order

📦 Get it by Friday, 12 Sept Delivering to 400001 · Change pincode

Scenario B — Same-day cutoff active

⚡ Order in the next 3 hrs 22 min and get it delivered today!

Scenario C — Non-serviceable pincode

❌ Delivery not available for this pincode.

Scenario D — Invalid pincode

⚠️ Please enter a valid 6-digit pincode.

Every message text, color, and font is customizable in the Appearance tab.

How the Calculation Actually Works

ILS runs the pincode through your rules in this order (first match wins):

1. Is the pincode in your Restricted Pincodes list? → Show "Delivery not available".
2. Is Same-Day Delivery enabled and is the pincode eligible and is the current time before your cutoff? → Show the same-day countdown.
3. Is KM-Based Rules enabled? → Calculate distance from origin, pick the matching slab.
4. Is Zone-Based Rules enabled? → Classify the pincode as Metro / Non-Metro / Rural and use that day count.
5. Fallback → Default EDD Days.

Then ILS adds those days to today's date, skipping Sundays and holidays if you've turned Skip Days on.

The result is the date the customer sees. Simple, predictable, entirely under your control.