intelligent.pageDocs

Loadshare

LoadShare Networks last-mile carrier: no public API docs, credentials issued per seller, token auth, forward shipments with API AWB generation and tracking.

LoadShare Networks is an Indian last-mile logistics operator, not a software vendor and not an aggregator. It runs a shared rider and fleet network (gig riders plus a captive electric two wheeler fleet) and sells elastic delivery capacity to enterprises across ecommerce, quick commerce, food and mobility, alongside first mile, line haul and warehousing. Its customers are large platforms rather than individual D2C sellers. There is no public developer portal: the API exists and is used by order management platforms such as Unicommerce, but credentials and documentation come from the LoadShare team per seller.

At a glance

What it is

LoadShare Networks (Bengaluru) describes itself as building India's cross-vertical last-mile logistics network. Its own site claims capacity across 24 cities, a captive EV fleet used either as the primary delivery layer or as a supplement to the gig pool depending on route profile, hyperlocal delivery under 30 minutes, intercity movement with managed transporters, and B2B deliveries for modern trade and direct-to-retail stores plus intercity part truck load. Published customer quotes reference BigBasket's last mile, food delivery peak absorption during lunch and dinner rushes, and tier 2 and tier 3 expansion.

Two things follow for a connector. First, LoadShare sells capacity to platforms, so the counterparty is usually an enterprise buyer with a negotiated SLA, not a self-serve seller. Second, its own pitch is "connect to your existing OMS or WMS through our API", which means the API is designed to be driven by an order management system rather than by a brand's own code.

For the unified model LoadShare is a source of shipments only. It is a carrier: no orders in the commerce sense, no catalogue, no stock.

API access

There is no self-serve path and no published reference.

  • No developer link exists on loadshare.net, which routes enquiries to a partnerships form promising a response within 24 hours. The relevant enquiry categories on the contact page are first mile, last mile, line haul, warehousing and partnerships.
  • https://api.loadshare.net/ is live and responds to an unauthenticated request with a structured JSON error rather than a generic gateway message, which tells us the API is a real service with a consistent envelope:
{
  "status": {
    "code": 401,
    "message": "Token/TokenId not found",
    "customErrorCode": null,
    "secondaryMessage": null
  }
}

The envelope shape (status.code, status.message, status.customErrorCode, status.secondaryMessage) is worth building the client's error handling around, because it is consistent and machine readable. Note customErrorCode, which implies a vendor specific error taxonomy beyond HTTP status codes.

  • https://track.loadshare.net/ serves a buyer facing "Customer Order Tracking" single page application. Its internal endpoints are not a published contract.
  • No official SDK in any language, no Postman collection, no OpenAPI specification and no LoadShare owned repositories were found on GitHub.
  • LoadShare is not listed in ClickPost's carrier documentation set, so a brand on ClickPost cannot currently reach LoadShare through it. Unicommerce does list it.

Authentication

Not documented first party. Two independent signals describe the same model from different angles.

The live API host names the two values it expects: a Token and a TokenId. That is a paired credential, not a single bearer secret, which usually means an identifier plus a secret rather than a signed token.

Unicommerce's connector form for LoadShare asks the seller for User Name and Password (both "provided by the Loadshare team"), plus Service Type (Warehouse or Marketplace, or a keyword specified by the carrier), Hand Over Mode (Drop or Pick), Pickup Address Id, and Fetch Label Link (set to true for the Uniware label format). The form has a "Connect" button that authenticates before the integration is saved, which implies a login or validation call.

The likely reading is that the username and password are exchanged for a Token and TokenId pair presented on subsequent calls. That is an inference, not a documented fact. The token endpoint, header names, lifetime and refresh behaviour are all unpublished and must be confirmed with LoadShare before any credential store is designed.

No example request can be given without inventing endpoint paths and header names, so none is given here.

Objects we can read

Shipments and tracking

Tracking is confirmed. Unicommerce exposes a Tracking Enabled switch on the LoadShare shipping provider and lists "AWB tracking is present" among the integration's feature highlights.

What the tracking read returns is not published: whether it carries full scan history or only the latest status, whether location and timestamps are included, and whether several AWBs can be batched in one call are all unknown. LoadShare's own site advertises live ETAs, proof of delivery and anomaly alerts to enterprise clients through a dashboard, along with order level tracking, SLA adherence rates and zone level analytics with exportable reports, so richer data exists in the product. Whether any of it is reachable over the seller API, or only through the dashboard and its exports, is unclear.

Proof of delivery

LoadShare markets proof of delivery ("live ETAs, proof of delivery, anomaly alerts") as part of its enterprise visibility layer. No API surface for retrieving a POD image or signature is documented.

Serviceability

Not documented. Unicommerce requires serviceability to be defined manually in Uniware (this facility to selected pincodes, any facility to selected pincodes, or any facility to any pincode), which suggests there is no serviceability lookup available to that integration.

Returns

Not available. Unicommerce states explicitly: "Only Forward shipment is supported." There is no reverse pickup path in that integration.

Rates and settlements

Not documented. No rate card endpoint, no COD remittance and no settlement surface is evidenced anywhere.

Writing back: listings, price and stock

Not applicable, this is a carrier. LoadShare holds no catalogue, price or stock. The write path is shipment creation.

Unicommerce's integration configures forward shipping methods for both COD and prepaid with "AWB Generation selected as API", and lists "AWB is provided by Loadshare" as a feature highlight. So the AWB is minted by LoadShare at creation time rather than drawn from a pre allocated series.

Two details distinguish this integration from most carriers:

  • Labels and manifests are produced by the integrator, not by LoadShare. Unicommerce states "Label pdf format is provided by Uniware" and "Manifest is provided by Uniware", which is the opposite of the Blitz integration where the carrier supplies both. The Fetch Label Link flag is set to true for the Uniware label format. A connector should therefore expect to render its own label to LoadShare's specification rather than to receive a PDF URL.
  • Hand over mode is a configured constant. Drop or Pick is set once on the connector, not per shipment, so a pickup request is probably not a separate API call in this integration.

Shipment cancellation is not mentioned in the Unicommerce integration and is not evidenced elsewhere.

Webhooks and notifications

Not published. No callback URL, webhook secret, event catalogue or retry policy is documented in any source. Unicommerce's integration relies on tracking rather than on a push.

Until a push contract is confirmed, assume pull. For a last mile carrier serving hyperlocal (under 30 minutes) and same day work, a 10 to 15 minute poll on the open shipment set is proportionate. Whether the API tolerates that cadence is unknown and should be agreed in writing, since there is no published limit to design against.

Rate limits and pagination

Not published. No rate limit figure, quota header, burst allowance, page size, cursor or date window appears in any source, first party or third party. There is no evidence of a bulk or list read either, so request volume likely scales linearly with open shipments.

The one useful observation is the error envelope shown above: a 401 comes back as HTTP plus a status.code in the body, so a client must read the body and not just the transport status. Expect throttling responses in the same shape, with customErrorCode carrying the specific reason.

Mapping to the unified model

Field names are not published, so this table maps concepts rather than exact fields. Every row needs confirming against a real response.

The error envelope is worth storing verbatim in raw: status.code, status.message, status.customErrorCode and status.secondaryMessage are the only field names that can be stated with certainty today.

Gaps and open questions

  • No first party documentation of any kind could be read: no endpoint paths, no request or response bodies, no field names, no status vocabulary.
  • The relationship between the username and password Unicommerce collects and the Token and TokenId the API expects is inferred, not documented. Token lifetime and refresh are unknown.
  • The customErrorCode taxonomy is visible in the envelope but its values are unknown, and those are exactly what a retry policy needs.
  • Whether a serviceability or pincode lookup exists is unclear. Unicommerce defines serviceability manually, which suggests it does not.
  • Reverse pickup is explicitly unsupported in the Unicommerce integration. Whether that is a LoadShare limitation or an integration scope decision is unclear.
  • Labels and manifests are produced by the integrator in the Unicommerce integration, so the label specification (barcode symbology, required fields, dimensions) is a document that must be obtained from LoadShare.
  • No webhook contract, no rate limits, no proof of delivery endpoint, no COD remittance or settlement surface.
  • LoadShare's enterprise dashboard exposes SLA adherence, zone level analytics and exportable reports. Whether any of that is reachable over an API, or only by export, is unknown and matters for reconciliation.
  • LoadShare does not appear in ClickPost's carrier set, so unlike most Indian carriers it cannot be reached through that aggregator today.

Sources