Caper India

Caper India (Caper Logistics) is a Mumbai-based business-to-business logistics operator: courier, warehousing, cold chain, freight forwarding, lubricant logistics, ATM movement, procurement, vendor management and reverse logistics. It is not an e-commerce aggregator and does not appear in ClickPost's carrier list or Unicommerce's shipping-provider catalogue. For a connector the objects that matter are rate lookup, AWB entry with label, tracking and cancellation. There is no developer portal, but Caper's API host publishes an auto-generated ASP.NET Web API help page listing the endpoints and their request schemas, which is enough to see the shape of the surface even though no prose documentation, authentication guide or response sample is published.

At a glance

What it is

Caper India Pvt Ltd is a logistics company headquartered at Ascot Centre, Sahar Road, Andheri East, Mumbai 400099. As of 2026-09-21 its own site claims 125 or more offices across India, pan-India and international coverage, and "real-time tracking via IWMS", its internal warehouse management system.

Its service list is squarely B2B rather than D2C e-commerce: cold chain delivery for pharmaceuticals and APIs, air and sea freight forwarding, lubricant logistics (drums, cans, industrial oils), ATM movement including installation and relocation, procurement and vendor management, warehousing, reverse logistics and express courier. The cargo types it highlights are heavy equipment and ATMs, sensitive electronics, lubricant materials, fragile point-of-sale material and temperature-controlled goods.

That positioning matters for a commerce connector: a seller using Caper is likely moving pallets, cold chain or high-value equipment, not parcels booked from a Shopify store. Expect low shipment volume and high per-shipment value.

API access

• No developer portal, no published onboarding page, no pricing for API access, no partner programme page.
• api.caperindia.com is live and runs ASP.NET Web API on the .NET Framework. The default ASP.NET project home page is still in place at the root, which tells you the deployment is not customised.
• https://api.caperindia.com/Help is the auto-generated Web API help page. It lists every controller and action with the full request model, and for two endpoints a JSON and XML request sample. Every endpoint's description field reads "No documentation available".
• Host probing on 2026-09-21: docs.caperindia.com, track.caperindia.com, iwms.caperindia.com, portal.caperindia.com and app.caperindia.com do not resolve. api.caperindia.com is the only API-bearing host found.
• No official SDK, Postman collection or GitHub client exists. The only GitHub repository matching the name is the marketing site source under an agency account.
• Caper does not appear in ClickPost's 428-carrier integration list, nor in Unicommerce's shipping-provider knowledge base.

Authentication

Not documented. What the published request models show:

1. Most endpoints carry UserID and Password as required fields inside the request body. There is no header-based scheme in any published model.
2. The AWB entry endpoints also accept a Token field alongside UserID and Password, which suggests a session or API token exists, but no endpoint that issues one is listed for that lane.
3. A separate group of endpoints, labelled EasyEcomWebAPI in the help page, does have a POST authenticate call. Its model shares one shape across all three of its actions and includes username, password, token, account_no, service_type and eeApiToken. This is the lane EasyEcom uses to book Caper as a shipping partner, and eeApiToken is EasyEcom's own token rather than Caper's.

No token lifetime, refresh, scope or multi-account model is published. For a credential store, assume one UserID, Password and CustomerCode triple per channel_account_id.

No sample call is shown here beyond the two the help page itself publishes, because anything else would mean inventing field semantics.

Objects we can read

Shipments and tracking

POST /api/v1/Tracking/Tracking is the only tracking endpoint. It is the one call with a published request sample:

{
  "UserID": "sample string 1",
  "Password": "sample string 2",
  "AWBNo": "sample string 3"
}

All three fields are marked Required. One AWB per call: there is no bulk variant and no date-range variant.

The response is declared as a raw HttpResponseMessage, which in ASP.NET terms means the help page cannot introspect it. No response schema and no sample are published. The event vocabulary, whether a scan history is returned at all or only a current status, the timestamp format, the NDR reason codes and the RTO status names are all unknown. This is the single biggest gap: the status mapping cannot be designed from public information.

Rates

POST /api/v1/Rates/GetRate, also with a published request sample:

{
  "UserID": "sample string 1",
  "Password": "sample string 2",
  "CustomerCode": "sample string 3",
  "OriginCode": "sample string 4",
  "DestinationCode": "sample string 5",
  "Weight": 6.1
}

All six fields are Required. Note that origin and destination are codes, not pincodes, so Caper maintains its own location code list. No endpoint that returns that list is published, which means the codes have to come from Caper as a file or be captured from the panel. The response schema is not published.

There is no separate serviceability or pincode-check endpoint. Rate lookup is presumably the serviceability proxy: an unserviceable pair returns no rate.

Locations

POST /api/v1/CountryList/Countrydata returns country data, presumably the list used for international shipments. No request or response schema is published beyond the endpoint existing. There is no endpoint for Indian location codes, warehouses or pickup addresses.

Orders, order items, products, listings, inventory, customers, settlements

Not applicable, this is a carrier. None of these objects exist in the API. Shipper and consignee details, including name, address, city, state, pincode, telephone, mobile, email and a government document type and number, are carried on the AWB entry request and are PII.

Caper collects ConsigneeDocumentType and ConsigneeDocumentNumber as well as the shipper equivalents, which is consistent with international freight and CSB-V export documentation. Treat those fields as sensitive identity data, not ordinary address data.

Writing back: listings, price and stock

Not applicable, this is a carrier. Caper holds no product catalogue, price or sellable stock, so there is nothing to write back in the listings sense.

The write surface, as published:

Awbentry is the substantive one. Its published request model is large and flat. The fields that matter:

Dimensions[] is a collection with ActualWeight, Vol_WeightL, Vol_WeightW, Vol_WeightH, pcs, Volumetric_Weight, division, measurement, childAWB_no and vol_weigth. The presence of childAWB_no means multi-piece shipments get child waybills under a parent, which is normal for freight and unusual for parcel.

Two observations for an implementer. First, the request and response share one model: Awberror, error, msg and Pdfdata are clearly output fields sitting on the input type, and Pdfdata is almost certainly the label as base64 rather than a URL. Second, Volumetric_Weight and vol_weigth both appear in Dimensions, spelled differently; that is the kind of duplication that only a written specification can resolve.

EditAWB existing as a first-class call is worth noting: unlike most Indian carriers, a booked waybill can apparently be amended rather than cancelled and rebooked.

Pickup is not a separate call in the published list. Whether it is implied by AWB entry or arranged offline is unknown.

Webhooks and notifications

None published. No callback registration endpoint appears in the help page, and no third-party source asserts one. Caper is absent from ClickPost's carrier list, so there is not even an aggregator capability matrix to check.

Until Caper confirms otherwise, poll POST /api/v1/Tracking/Tracking per AWB. Because there is no bulk endpoint and no published rate limit:

• Keep the open shipment set small, which for a B2B freight operator it naturally will be.
• Poll no more often than hourly, and back off aggressively on any error.
• Stop polling an AWB about 7 days after it reaches whatever terminal status turns out to exist.

Ask Caper whether a status push, a daily file or an SFTP drop is available. For B2B logistics operators, a daily report is more common than a webhook.

Rate limits and pagination

Nothing is published. No limits, no quota headers, no pagination model, no bulk endpoints anywhere in the surface. Every call is single-record. Throttle client-side and assume the API is sized for panel-scale traffic, not for a sync job.

Mapping to the unified model

Field names on the write side are known; on the read side they are not, because no response schema is published.

Gaps and open questions

• No response schema anywhere. The tracking response is typed as a raw HTTP message and everything else says "Sample not available". The status vocabulary, which is the thing a connector most needs, is entirely unknown.
• Authentication is undocumented. Whether Token is obtained from a call, from the panel, or is unused is unclear, and the authenticate endpoint sits only in the EasyEcom lane.
• Location codes are undocumented. OriginCode and DestinationCode are required for rating but no endpoint returns the list.
• The EasyEcom lane and the v1 lane look like two different generations of the API with different field naming conventions (username versus UserID) on the same host. Ask which one a new client should use.
• Whether a sandbox exists is unknown.
• Whether pickup is requested through the API or arranged offline is unknown.
• No proof of delivery, NDR, RTO or COD remittance endpoint appears anywhere in the published surface, despite reverse logistics and COD both being offered commercially.
• Caper is absent from both ClickPost and Unicommerce, so there is no aggregator route into it and no third-party description of its capabilities to cross-check against.

Sources

• https://api.caperindia.com/Help, read 2026-09-21. Auto-generated ASP.NET Web API help page listing all eleven endpoints, their request models and, for tracking and rates, JSON and XML request samples. Per-endpoint detail pages under /Help/Api/ were read for the full field lists.
• https://api.caperindia.com/, read 2026-09-21. Default ASP.NET Web API project home page.
• Caper India homepage, read 2026-09-21 through a rendering proxy because the site is a JavaScript-only application. Service lines, cargo types, 125 or more offices, IWMS tracking claim, Mumbai address and contact details.
• Host probing of docs.caperindia.com, track.caperindia.com, iwms.caperindia.com, portal.caperindia.com, app.caperindia.com, 2026-09-21: none resolve.
• ClickPost carrier list, sitemap read 2026-09-21: Caper is not among the 428 integrated carriers. Unicommerce's shipping-provider knowledge base has no Caper article.