intelligent.pageDocs

Proship

Proship by Prozo aggregator: no public API docs, username and password give tokens, forward and reverse AWB creation, cancel, polling and webhook tracking.

Proship is the shipping arm of Prozo, an Indian supply chain operator that runs warehousing, fulfilment and freight for quick commerce and omnichannel brands. Proship is the carrier aggregation layer of that stack: rather than the brand choosing a courier per order, Proship allocates one from its integrated set using a priority the seller configures in the Proship panel (by rating, price or delivery time). There is no public developer portal, but the API is real, well integrated, and unusually well described by two aggregators that consume it: ClickPost documents it as courier partner 329 (forward) and 367 (reverse), and Unicommerce documents the seller connector.

At a glance

What it is

Prozo (Gurugram) sells itself as a supply chain operating system for quick commerce and omnichannel brands: shared, dedicated, managed and on-demand warehousing, fulfilment for quick commerce, marketplaces, D2C webstores, general and modern trade and B2B distribution, plus surface and air delivery, same day and next day, metro express, part truck load freight, appointment deliveries and hyperlocal. Its platform layer includes a multi-channel order management system, a warehouse management system, and a freight technology layer (TMS) with a courier allocation engine and NDR and NPR management.

Proship is the freight piece sold on its own. ClickPost describes it plainly as "the shipping arm of warehousing and fulfillment service provider, Prozo", and Unicommerce classifies it as "a shipping aggregator courier partner" in the same category as Shiprocket, Shyplite and Pickrr.

The consequence for a connector is that the carrier on a Proship shipment is chosen by Proship, not by the caller. Unicommerce's note is explicit: rather than adding each downstream courier separately, "the system will allocate the correct shipping company through a single Proship added in Uniware based on the priority set on Proship seller panel which is as per the shipping matrices like Rating, Pricing or Delivery time." Allocation policy lives in the Proship panel, outside the API.

For the unified model Proship is a source of shipments only. Prozo as a whole also holds inventory and orders, but that is the WMS and OMS product, not Proship, and it has its own separate logins (the Prozo site offers "Control Tower", "WMS Login" and "TMS Login" as three distinct entry points).

API access

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

  • No developer. or docs. host for Prozo resolves. docs.proship.in and api.proship.in both serve the same single page application, a "Proship Tracking" front end, not an API reference. www.proship.in is the seller web application itself.
  • Credentials come from a named human. ClickPost's setup page says the username and password "You will get it from your Proship relationship manager", and Unicommerce says they "will be provided by the Proship team for every seller".
  • An optional Partner_id exists. ClickPost describes it as "used to designate a specific courier partner for shipment orders, it can be left unconfigured", which means the caller can override Proship's allocation engine and pin a downstream courier if they want to.
  • No official SDK in any language, no Postman collection and no OpenAPI specification were found. No Prozo owned repositories were found on GitHub.
  • https://api.prozo.com/ is publicly reachable and answers with a Spring Data REST HAL index listing master data resources (users, countries, userMasters, cities, schedulerJobInfoes, profile). That tells you the backend stack is Spring Data REST and that resource collections are paged with {?page,size,sort}, but it exposes no shipping endpoints and is not the Proship shipping API. Do not build against it.

Authentication

Not documented first party. ClickPost's carrier setup page is the most precise description available:

So the model is: POST credentials, receive a token (ClickPost says "Tokens", plural, which may mean an access and refresh pair or separate tokens per API), present it on subsequent calls. Token lifetime, the token endpoint, the header name and refresh behaviour are unpublished.

Unicommerce's connector form asks for the same User Name and Password, plus Service Type (Warehouse or Marketplace, or a keyword the carrier specifies), Hand Over Mode (Drop or Pick), Pickup Address Id, and Fetch Label Link. Its "Connect" button authenticates before the integration saves, which confirms a login or validation call exists.

No example request, endpoint path or header name can be stated without inventing one, so none is given here. Confirm all of it with the Proship relationship manager.

Objects we can read

Shipments and tracking

Tracking is available two ways, which is unusual for a carrier of this size and is the single most useful fact on this page. ClickPost lists both "Tracking via Polling" and "Tracking via Webhooks" among the services integrated, for both the forward partner (329) and the reverse partner (367). Unicommerce independently confirms "AWB tracking is present".

The shape of either channel is not published: no field names, no status vocabulary, no scan history structure, no batch limit on the polling read. Because Proship allocates a downstream courier, the tracking response should be expected to carry both the Proship identity and the underlying courier's identity, but that is an inference.

Returns and cancellations

Reverse shipments are a first class flow. ClickPost maintains a separate courier partner id for them (367, "Proship RVP") with the same four integrated services, and Unicommerce states "Both Forward and Reverse Shipments are supported".

Cancellation is confirmed by ClickPost for both the forward and the reverse partner.

Serviceability, rates, NDR and settlements

Not documented. Prozo's platform page advertises a "PACE Engine", courier allocation, and NDR and NPR management as TMS features, so NDR handling exists in the product, but no API surface for it is evidenced. No rate card, serviceability lookup, COD remittance or settlement endpoint is documented anywhere. Unicommerce requires serviceability to be defined manually in Uniware, which suggests a serviceability lookup was not used in that integration.

Proof of delivery

Not documented.

Writing back: listings, price and stock

Not applicable, this is a carrier aggregator. Proship holds no catalogue, price or stock. The write path is the shipment lifecycle.

  • Create a shipment. ClickPost lists "Order Creation" as integrated for both the forward and the reverse partner. Unicommerce configures forward shipping methods for both COD and prepaid with AWB generation set to API.
  • AWBs are minted in real time. ClickPost is explicit: "No need to configure pre-assigned AWBs, AWBs are generated by Proship in real-time during the order creation API call and returned back in response." That rules out the pre allocated waybill series some Indian carriers use, and means creation is the only place an AWB appears.
  • Labels come back on the forward create call. ClickPost: "Clickpost does not generate a label for Proship orders. Labels are generated by Proship and returned in API response to the customer." Unicommerce agrees ("Label pdf is provided by Proship", "Manifest is provided by Proship") and instructs the operator to set Fetch Label Link to FALSE "to get label format from shipper end".
  • Reverse shipments get no label. ClickPost states for partner 367: "Labels are not generated in Proship RVP orders." A connector must not block a reverse booking on a missing label URL.
  • Cancel. Available on both forward and reverse.
  • Pin a courier. Setting Partner_id overrides Proship's allocation engine for that shipment.

There is no evidence of a separate pickup request call. Hand Over Mode is configured once on the connector as Drop or Pick, which suggests handover is an account level setting rather than a per shipment call.

Webhooks and notifications

Proship supports webhook tracking. ClickPost lists "Tracking via Webhooks" as an integrated service for both courier partner ids, which means Proship pushes status to a registered endpoint rather than only answering polls.

What is not published: the subscription mechanism (whether the URL is registered over the API or configured in the Proship panel), the event catalogue, the body shape, the verification scheme (signature, HMAC or shared secret header), the retry policy and the timeout. All of that has to come from the Proship team.

Because polling is also supported, the safe pattern is both: take the webhook as the low latency path and run a reconciliation poll on the open shipment set every 30 to 60 minutes to catch dropped deliveries. No batch limit on the polling read is published, so start conservatively.

Rate limits and pagination

Not published. No rate limit figure, quota header, burst allowance, 429 behaviour, page size or cursor is documented in any source.

One indirect signal: the publicly reachable api.prozo.com HAL index advertises Spring Data REST paging on collection resources ({?page,size,sort}). If the Proship shipping API is built on the same stack, expect page, size and sort query parameters and a HAL style _links and _embedded envelope on any list read. That is a reasonable starting hypothesis to test, not a documented fact.

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.

Gaps and open questions

  • No first party documentation could be read: no endpoint paths, no request or response bodies, no field names, no status vocabulary.
  • The token endpoint, lifetime, header name and refresh behaviour are unknown. ClickPost's phrasing ("generate the Tokens") hints at more than one token, which needs clarifying.
  • The webhook contract is entirely unspecified: subscription mechanism, event types, body shape, signature and retries.
  • Whether the tracking response exposes the allocated downstream courier is unverified, and it matters: without it, every Proship shipment collapses into one carrier name and carrier level performance analysis becomes impossible.
  • No serviceability lookup, no rate card, no NDR API, no proof of delivery and no COD remittance or settlement surface is evidenced.
  • Reverse shipments produce no label, per ClickPost. Whether the return pickup is therefore label free end to end, or whether a label arrives by another route, is unclear.
  • Partner_id overrides carrier allocation, but the list of valid values and how a caller discovers them is not documented.
  • https://api.prozo.com/ exposes a Spring Data REST index publicly. It carries no shipping endpoints, but it is a hint that the platform's REST conventions are Spring Data REST, and it should not be mistaken for the Proship API.
  • Prozo's own OMS and WMS may expose orders and inventory over an API. That is a separate product and a separate page, and it was not documented publicly either.

Sources