ElasticRun began as a rural B2B commerce platform: aggregate demand from kirana stores in small-town and rural India, aggregate supply from FMCG brands, and move the goods on an asset-light transportation network of contracted vehicles. It also carries e-commerce parcels for Amazon, Flipkart and Myntra into the same geography. By 2026 the public positioning has shifted to "India's fastest-growing fulfilment network", with a supply chain software stack, dark stores, a D2C delivery brand called Swifter, and 10 minute hyperlocal delivery in 50 plus cities and towns. It is a large, contracted, enterprise business. There is a real API gateway and no public developer documentation. The only interface anyone can exercise today is a guest tracking endpoint, which is documented precisely below.
At a glance
What it is
A Pune company, based in Pimple Saudagar, describing itself as "India's Commerce Enabler". Its own metadata still carries the original positioning verbatim: "B2B eCommerce platform | Rural | Aggregation | Transportation Network | Amazon | Flipkart | Myntra | FMCG | Pimple Saudagar, Pune". That sentence is the clearest one-line description of the business anywhere on the site.
The original and still core model is rural B2B distribution. Kirana retailers in towns and villages order FMCG stock through ElasticRun instead of waiting on a distributor's beat; ElasticRun aggregates those orders, buys or draws from brands, and delivers on a network of contracted vehicles. The same vehicles carry e-commerce parcels for the large marketplaces into the same routes, which is what makes the economics work. Nothing on the public site explains the commercial mechanics of the brand side, and in particular whether brands transact with ElasticRun on purchase orders, on consignment or as a marketplace.
The vendor purchase order model is widely described for ElasticRun in secondary commentary, and it is consistent with a buy-and-resell rural distribution business, but it could not be confirmed from any first-party source read for this page. Treat the PO mechanics, the ownership of title, the payment terms and the returns liability as open commercial questions to put to ElasticRun directly.
The 2026 public face is broader and more software-shaped. Product statements taken from the site on 2026-09-22:
Those are vendor claims. No order volume, GMV, retailer count or funding figure was found from a first-party page.
For our purposes ElasticRun is simultaneously three things: a B2B sales channel for FMCG brands selling into rural retail, a fulfilment provider holding stock in warehouses and dark stores, and a last-mile carrier. Which of those a given seller is buying decides which unified tables apply.
API access
There is no developer programme and no documentation. The infrastructure, checked on 2026-09-22:
Two things follow. First, ElasticRun runs an enterprise API management layer, WSO2 API Manager, which is the standard choice for exposing versioned, rate-limited, subscription-gated APIs to contracted partners. Its default Axis2 service listing at /services exposes only the WSO2 sample echo and Version services, so no business API is discoverable and nothing is leaking. Its publisher and developer portal paths return WSO2's own 404, meaning those consoles are not exposed to the internet.
Second, the gateway hostname xrp-liberaduo-flipkart-gwy names Flipkart explicitly, and partner.elasticrun.in points at an ERP application gateway. Together those say integrations here are built per partner, behind named gateways, with an ERP at the centre. That is a per-contract integration model, not a product.
The route in is commercial. Expect a named account manager, a statement of work, and an interface specification supplied under NDA rather than published.
The one public endpoint
The tracking page at elastic.run/track-your-order calls a guest endpoint that answers without any credential. Verified live on 2026-09-22:
GET /api/tracking/last-mile-service/guest/v2/get-tracking-details?tracking_id=<AWB>&mobile_number= HTTP/1.1 Host: elastic.run
Both parameters are sent by the page; mobile_number is sent empty. With no parameters at all:
{ "data": "", "message": "insufficient parameters", "status_code": 400, "error": "insufficient parameters" }
With an AWB that does not exist:
{ "data": null, "message": "No consignment found", "status_code": 400, "error": "" }
So the response envelope is { data, message, status_code, error }, and status_code is carried in the body rather than only in the HTTP status. The path itself is informative: last-mile-service is a named internal service and v2 is a real version, so the contracted interface is very likely a set of similar services behind the same prefix.
This is the site's own guest endpoint, read from its public JavaScript, not a published API. It carries no contract, no versioning commitment and no rate limit statement, and the mobile_number parameter suggests it will accept a phone number as an alternate lookup key, which makes abuse plausible and a future lockdown likely. Use it to verify a single AWB by hand. Do not build a tracking pipeline on it. Ask for the contracted interface.
Authentication
Not published. WSO2 API Manager conventionally issues OAuth 2.0 tokens through a token endpoint, with per-application consumer keys and secrets, subscription tiers and scopes, and that is the most likely shape here. But the developer portal is not exposed, no token endpoint is documented, and nothing first-party confirms the grant type, the token lifetime or the scope model. Do not design a credential store on the assumption.
Questions to settle in the integration conversation: is it OAuth 2.0 client credentials or a static key, are credentials per brand or per integration, what is the token lifetime, and is there a separate credential for the ERP gateway at partner.elasticrun.in from the one for api.elastic.run.
The guest tracking endpoint takes no credential at all.
Objects we can read
Only shipments, and only by AWB, without a contract.
Orders
For a brand selling into rural retail through ElasticRun, the order is a retailer order placed in ElasticRun's own app, and ElasticRun is the system of record. For a D2C brand using Swifter, the order originates in the brand's own store and ElasticRun fulfils it. Either way no interface is published. An order management system is named in the product list; it is not exposed.
Order items
Not documented.
Products and listings
For the B2B business, a brand's SKUs are listed to retailers inside ElasticRun's app, which makes it a genuine sales channel with listings and prices. Nothing about that surface is published: no catalogue endpoint, no price mechanism, no listing status model. This is the largest documentation gap on the page, because it is the only part of ElasticRun that would produce listings rows.
Inventory
Real. ElasticRun operates warehouses, offers dedicated warehouse space per brand, and runs dark stores for hyperlocal delivery. A warehouse management system is named in the product list. No interface is published.
Shipments and tracking
The only readable object. Shipments are keyed by AWB. The guest endpoint above returns tracking details for one AWB at a time. The marketing copy describes what the tracking page shows: "live shipment status and journey updates", "expected delivery, and full journey checkpoints", so the contracted interface presumably returns a status, an expected delivery date and a scan event array.
No field names are published. Sample response not published: the only responses obtainable without a real AWB are the two error envelopes above.
Returns and cancellations
A returns product exists and is well specified in marketing terms: doorstep pickup, on-spot quality check, rapid refund initiation and a return analytics dashboard, plus same-day returns under the Swifter brand. On-spot QC is unusual and valuable, because it determines refund eligibility at the doorstep rather than at the warehouse. No interface is published.
Proof of delivery
Not mentioned in public material. For a business running its own last mile with rider tracking, an electronic POD almost certainly exists. Ask.
Payments and settlements
Nothing published. For the B2B business this is the critical unknown: if ElasticRun buys on a purchase order then settlement is an accounts payable relationship rather than a marketplace remittance, and there may be no settlement report at all in the marketplace sense. Establish which model applies before designing anything.
Customers
Two different customer types. In the B2B business the customer is a kirana retailer, and that data is ElasticRun's. In Swifter the customer is the brand's own consumer, and the name, address and phone travel with the parcel. All PII. Nothing is exposed.
Locations
Warehouses, dedicated brand warehouse space and dark stores across 50 plus cities and towns for hyperlocal. No location list or serviceability lookup is published, which matters a great deal for a business whose main selling point is reach into places other networks do not serve.
Writing back: listings, price and stock
Not applicable to the carrier and fulfilment side of ElasticRun, which is how it is catalogued here. There, the write path is order and shipment creation, pickup scheduling, returns pickup and cancellation, none of it documented.
The B2B side is a genuine exception worth recording. A brand selling to rural retailers through ElasticRun does have listings, prices and stock, presented to retailers in ElasticRun's app. If ElasticRun buys on a purchase order and resells, the brand does not control the retail price and the listing is ElasticRun's; if it is a marketplace or consignment model, the brand might. Nothing published settles it, and no mechanism for a brand to update a price or a stock level, whether by API, feed, spreadsheet or account manager, is described anywhere.
That question, buy-resell versus marketplace, is the single thing to resolve before treating ElasticRun as a channel rather than a carrier.
Webhooks and notifications
Not published. No push mechanism is described, no event catalogue exists and no subscription endpoint is exposed.
Without a contract the only pull option is the guest tracking endpoint, one AWB at a time, which is not a supported interface and should not be used as a pipeline. With a contract, ask specifically for: push of shipment status changes, push of return pickup and QC outcomes, whether events are signed, and the retry policy. A WSO2 gateway makes subscription-based callbacks straightforward, so a webhook is a reasonable thing to request.
Rate limits and pagination
Not published. WSO2 API Manager enforces subscription throttling tiers by default, so a contracted interface will almost certainly come with a named tier and a documented request ceiling. Ask for the tier and its numbers as part of the specification. No pagination model is observable.
Mapping to the unified model
Field names are unknown except the two tracking request parameters. The table records the concepts and which business line they come from.
Gaps and open questions
- The commercial model of the B2B business: purchase order and resale, consignment, or marketplace. Everything about
listingsandsettlementsdepends on this and no first-party source states it. - No interface specification for anything. The WSO2 gateway is real and sealed.
- Authentication model unknown, including whether the ERP gateway and the API gateway use the same credentials.
- No serviceability lookup, which is the most valuable thing ElasticRun could expose given its geography.
- Proof of delivery is not mentioned anywhere.
- No webhook, no rate limit statement, no sandbox, no versioned public contract beyond the
v2visible in the guest tracking path. - The guest tracking endpoint accepts a
mobile_numberparameter. Whether it will return consignments for a phone number without an AWB was not tested and should not be, but it is worth flagging to ElasticRun as a privacy question. - The apex
elasticrun.inandpartner.elasticrun.inboth return a Kubernetes default backend 404, which means partner-facing hosts exist but route only on specific paths. Those paths are the integration surface and none of them are public. - ElasticRun does not appear in the ClickPost carrier directory or Unicommerce's integration list, so there is no aggregator description to cross-check against.
Sources
- ElasticRun homepage, read 2026-09-22, and its application bundle at
/assets/index-BhJ683mS.js, for the product statements, the Swifter description, the techstack claims, the hyperlocal city count and the original positioning metadata - ElasticRun B2B e-commerce page and Swifter page, both client rendered, with content read from the application bundle
- ElasticRun order tracking page, and the guest endpoint
GET /api/tracking/last-mile-service/guest/v2/get-tracking-detailsexercised unauthenticated on 2026-09-22 for the two error envelopes quoted above - Live HTTP checks on
https://api.elastic.run/, which returns the WSO2 API Manager welcome page, and on/services,/devportal,/publisherand/carbon, which expose only WSO2 defaults - Live HTTP checks on
https://elasticrun.in/andhttps://partner.elasticrun.in/, both returningdefault backend - 404 - DNS checks across
elastic.run,www,api,docs,developer,track,seller,vendor, andelasticrun.in,www,api,docs,partner, run 2026-09-22, which reveal theerp-gway2,erp-appgw-ci-01andxrp-liberaduo-flipkart-gwygateway hosts