UrbaneBolt

UrbaneBolt is an Indian same day and next day delivery company, operated by Urbanlogix Global India Private Limited, that also sells warehousing under the name Store and Ship: you send stock to its warehouses, it picks, packs and dispatches each order into its own delivery network. For a commerce database the shipping half is usable today, because UrbaneBolt publishes a Postman collection for its customer API covering authentication, pincode serviceability, manifestation, labels, tracking, cancellation, NDR actions, payment mode change and proof of delivery. The warehousing half is not: there is no published endpoint for stock levels, for advising an inbound consignment, or for releasing an order to be picked, even though the Store and Ship page promises real time inventory visibility. That split is the finding.

At a glance

What it is

UrbaneBolt positions itself as a full stack logistics partner for D2C and e-commerce brands in India, with same day and next day delivery as the headline product, plus two hour delivery, cross border shipping, air and ocean freight and express import and export. Its published network is 10 cities and 56 owned service centres, with Delhi NCR, Bengaluru, Mumbai, Hyderabad, Ahmedabad, Surat, Lucknow and Guwahati named on the home page. The corporate entity is Urbanlogix Global India Private Limited.

Store and Ship is the warehousing and fulfilment product. The description is the standard 3PL one: stock is held in warehouses positioned close to buyers, orders received before a daily cut off are picked, packed and shipped the same day, and fulfilment feeds directly into the same day and next day delivery network. Warehousing is named for Bangalore, Hyderabad and Delhi specifically, and the page claims real time stock levels across every location and end to end visibility of inventory and orders.

For the unified model UrbaneBolt is a carrier first: it supplies shipments and their events[]. Where Store and Ship is in use it is also a locations row of type fulfilment_centre and, in principle, a source of inventory, but nothing public says how to read that.

API access

The route is: contact UrbaneBolt, sign as a customer, and ask the integration team for API credentials and the production host. The collection's own note on the token endpoint says exactly that: "Kindly use your API credentials provided by UrbaneBolt integration team."

What you are given is a username, a password and a customerCode, which appears on the manifest request as UEBCUS0008 in the sample and is the account identifier the shipment is booked against. No API versioning policy, deprecation schedule or SDK is published. The collection is the specification.

Nothing in it is fulfilment specific, so for Store and Ship expect the same conversation as with any Indian 3PL without published docs: ask whether stock and inbound are available by API, by scheduled file, or only in a panel, and get the answer in writing before scoping.

Authentication

1. POST your username and password as JSON to the token endpoint.
2. Take the token from the response and send it as Authorization: Bearer <token> on every later call.
3. Re-authenticate when calls start failing, because no lifetime is documented.

curl -s -X POST https://uat.urbanebolt.in/api/v1/auth/getToken/ \
  -H 'Content-Type: application/json' \
  -d '{"username":"<your-api-user>","password":"<your-api-password>"}'

curl -s "https://uat.urbanebolt.in/api/v1/services/tracking-pub/?awb=200000001170" \
  -H 'Authorization: Bearer <token>' \
  -H 'Content-Type: application/json'

Two inconsistencies to code around. The Print Label request sends the token bare in the Authorization header with no Bearer prefix, while every other request uses Bearer; send Bearer and fall back only if you get a 401. Several requests also carry Django style csrftoken and sessionid cookies, which suggests the API sits on a session based web application, so a bare token may not be sufficient on every path. Test each endpoint with the token alone before assuming.

No scopes, no roles and no multi account mechanism are published. For several brands, expect one credential and one customerCode per account.

Objects we can read

Shipments and tracking

GET /api/v1/services/tracking-pub/?awb=<awb> returns, in the collection's words, "shipment details along with shipment travel history". No sample response is saved in the collection, so the field names are unknown until the first live call. Plan the parser defensively.

GET /api/v1/services/epod/?awbs=<awb> returns proof of delivery for one or more waybills. GET /api/v1/services/label/?awbs=<awb> returns label data rather than a rendered label: the description says it gives you shipping label data so you can create your own label to paste on the box.

Locations and serviceability

• GET /api/v1/location/pincodes/?pincodes=122001,122017 checks specific pincodes.
• GET /api/v1/location/pincodes/?type=ex is the bulk list. The type parameter's allowed values are not documented beyond the ex in the example.

There is no endpoint that enumerates UrbaneBolt warehouses or service centres.

Orders, inventory, returns, settlements

None published. An order exists only as a manifested shipment. Stock at a Store and Ship warehouse has no endpoint. Returns are handled through the NDR path as an RTO action on an existing waybill rather than as a return object. There is no fee, invoice or COD remittance endpoint.

Writing back: listings, price and stock

UrbaneBolt is not a sales channel, so there is nothing to list or price, and there is no documented stock write. The documented writes are all shipment level.

Manifest a shipment

POST /api/v1/services/manifest/ takes an array of shipments, so it is a batch call. Every field below is from the collection's sample request:

customerCode, orderNumber, declaredValue, itemDescription, collectableValue, height, length, breadth, weight, pieces, itemQuantity, serviceType (SDD in the sample, NDD in the global one), payMode (COD or PPD), invoiceNumber, invoiceDate, and three parallel address blocks: consignee (consName, consAddress, consAddressType, consCity, consState, consPincode, consCountry, consMobile, consEmail), shipper (shpr*) and return (rtn*).

[
  {
    "customerCode": "UEBCUS0008",
    "orderNumber": "ORDER-1001",
    "serviceType": "SDD",
    "payMode": "COD",
    "declaredValue": 100,
    "collectableValue": 1,
    "itemDescription": "BOOKS",
    "itemQuantity": 1,
    "pieces": 1,
    "weight": 1.1,
    "length": 12,
    "breadth": 10,
    "height": 10,
    "invoiceNumber": "INV0002",
    "invoiceDate": "2024-10-02",
    "consName": "...",
    "consAddress": "...",
    "consAddressType": "Home",
    "consCity": "Surat",
    "consState": "GUJRAT",
    "consPincode": 122001,
    "consCountry": "INDIA",
    "consMobile": 8320226438,
    "consEmail": "buyer@example.com",
    "shprName": "...",
    "shprAddress": "...",
    "shprAddressType": "Seller",
    "shprPincode": 122001,
    "rtnName": "...",
    "rtnAddress": "...",
    "rtnAddressType": "Seller",
    "rtnPincode": 122017
  }
]

POST /api/v1/services/global-manifest/ is the cross border variant and adds itemSku, itemHsn, sellerGST, sellerERN, taxCGSTN, taxSGSTN, taxIGSTN, totalGST, totalTax, volWeight, latitude and longitude for each party, and the booleans isDG, isReverse, isSurface, isEssential, delSecure and delPriority. isReverse is the only hint in the whole collection of how a reverse pickup is booked.

Mobile numbers and pincodes are sent as numbers rather than strings in the samples, which will drop a leading zero if you are not careful. Consignee name, address, phone and email are PII.

Other writes

• POST /api/v1/services/cancel/ with {"awbs": "200000001170"} cancels before pickup.
• POST /api/v1/services/ndr/?type=rtoLock with a list of waybills forces a return to origin.
• POST /api/v1/services/ndr/?type=reAttempt takes an array of objects with awb, name, address, city, state, pincode, mobile and email, so a re-attempt can correct the address at the same time.
• POST /api/v1/services/update-paymode/ with a comma separated awbs string switches COD to prepaid or back.

Note the inconsistency in how waybill lists are passed: a comma separated string in cancel and paymode, a query parameter in label, tracking and ePOD, an array of objects in NDR re-attempt.

Inbound and stock, not documented

There is no published way to tell a Store and Ship warehouse that stock is coming, to read what it received, or to read what it holds. Ask for the inbound advice format, the receipt confirmation, and whether stock is available as a scheduled export.

Webhooks and notifications

None published. The site's marketing copy mentions automated notifications from pickup to delivery to the buyer, which is a customer messaging feature rather than a webhook for your systems.

Poll on this basis until UrbaneBolt confirms otherwise:

Rate limits and pagination

Neither is published. The collection has no paged endpoint at all: reads are keyed by waybill or pincode, and the bulk pincode call returns a whole list in one response. Because tracking is per waybill, a large book of shipments turns into one request each, which is exactly the shape that gets an integration throttled. Keep concurrency low, batch the awbs parameter where an endpoint accepts several, cache terminal statuses and never re-poll a delivered waybill.

Mapping to the unified model

Gaps and open questions

• No sample responses. The collection saves no example response for any endpoint, so every field name on the read side is unverified. This is the main reason confidence on reads is lower than on writes.
• Production host unknown. Every documented request points at uat.urbanebolt.in. The production base URL comes from the integration team.
• Token lifetime unknown. No expiry, no refresh endpoint, no error shape for an expired token.
• Session cookies in the collection. Whether the API is genuinely token only, or expects a session, needs one live test per endpoint.
• The whole Store and Ship surface. Inventory, inbound, receipts, pick and pack state and storage fees are all undocumented despite the product page promising real time visibility. If per warehouse stock matters, treat this as an unanswered question rather than a small gap.
• Warehouse footprint. The site names Bangalore, Hyderabad and Delhi for warehousing and 56 service centres overall, but does not say how many are fulfilment centres or how large they are.
• No returns object. A customer return appears to be either an RTO on the forward waybill or a reverse shipment booked through the global manifest with isReverse. Which one applies in practice is not documented.

Sources

• UrbaneBolt Customer API_Documents_UAT, the public Postman collection linked from the site footer, fetched as JSON on 2026-09-22 and read request by request for endpoints, headers, request bodies and descriptions
• urbanebolt.com, the home page, for the network figures and the service list
• urbanebolt.com/store-and-ship, the warehousing and fulfilment product page, for the Store and Ship description, the named warehousing cities and the inventory visibility claims