Serviceability
This page applies to Forward Logistics and Reverse Logistics. Hyperlocal and Quick Commerce check serviceability through their own endpoints and don't use this model — see their sections instead.
A single endpoint covers both forward and reverse orders, and both the Regular and Surface supply chains:
Code
Getting an answer out of it takes two decisions:
- Which
servicevalues to query — determined by the kind of order you're placing. - Which tier to look for in the response — determined by the supply chain your client account is configured for.
Both matter. A pincode appearing in the response is not the same as it being serviceable for you.
1. Which services to check
An order is only serviceable if every leg is. Check each one separately — they use different service values and are configured independently.
| Order | Services to check |
|---|---|
| Forward — Marketplace | seller_pickup, seller_delivery, customer_delivery |
| Forward — Warehouse | warehouse_pickup, warehouse_return, customer_delivery |
| Reverse — return to warehouse (RTO) | customer_pickup, warehouse_return |
| Reverse — return to seller (RTS) | customer_pickup, seller_delivery |
What each one answers:
| Service | Question it answers |
|---|---|
customer_pickup | Can we collect from the customer? |
customer_delivery | Can we deliver to the customer? |
seller_pickup | Can we collect from the seller? |
seller_delivery | Can we deliver back to the seller (RTS)? |
warehouse_pickup | Can we collect from your warehouse? |
warehouse_return | Can we return to your warehouse (RTO)? |
This is the single most common cause of a confusing rejection: the customer pincode checks out, but the pickup or return leg doesn't, and the order is refused.
2. Which tier to look for
The response lists the tiers available at that pincode. Find the one matching your supply chain — the others are irrelevant to you.
| Service | Regular client | Surface client |
|---|---|---|
customer_delivery | Regular | Surface |
customer_pickup | Regular | Surface |
seller_pickup | Marketplace | Surface_Mkt |
seller_delivery | RTS | Surface_RTS |
warehouse_pickup | dc_pickup | surface_dc_pickup |
warehouse_return | RTO | surface_RTO |
Regular is for small shipments, Surface for large ones. Which applies to you is set on your client account — check with your integration POC if you're unsure.
Values beyond these appear (Large, Slotted, large_RTO, large_dc_pickup, Connect_RTS). Treat anything that isn't your tier as not applicable rather than as a fallback.
Worked example
A Regular marketplace client shipping from 110005 to 110009:
Code
Both legs carry the Regular tier, so the order can be placed. A Surface client running the same two checks would be looking for Surface_Mkt and Surface instead — and the first pincode would fail, because 110005 returns only Marketplace.
Reading the response
Code
Things worth knowing:
- Pincodes you asked about may be missing from the response. They're omitted rather than returned with an empty
servicesarray, so compare against what you sent — don't assume the response covers every pincode in your request. - Coverage is per client account. The same pincode can return different tiers for different clients.
- A well-formed pincode outside the network still returns a tier list. Only a pincode failing the 6-digit format rule returns
[]. So a non-empty response is not by itself proof of coverage — check for your tier. - Results are cacheable. Coverage changes infrequently.
Listing all covered pincodes
Omit pincodes to page through everything covered for a service. Results are paginated with page and count (default 1 and 25).
Code
If the order is still rejected
Order placement re-checks serviceability, so a rejection despite a green check usually means a leg you didn't check — most often the return leg. Rejections come back as HTTP 400 on Reverse and HTTP 200 with message: "Failure" on Forward. See Errors.