Purpledrone

PurpleDrone is an Indian warehousing and last-mile logistics company. Its core business is third party warehousing built around its own warehouse management system, with last mile delivery to roughly 500 pincodes and reverse pickup sold alongside it. It is a smaller, regional carrier rather than a national network, and it has no public developer portal. What can be established about its API comes from ClickPost, which integrates it as courier partner 372, and from Unicommerce, which documents the seller connector.

At a glance

What it is

PurpleDrone describes itself as offering end-to-end logistics and warehousing solutions, "powered by 50+ years of industry experience". Its published service lines are warehousing (described as its core strength, built on a proprietary WMS), last mile delivery across 500 or more pincodes, reverse logistics and transportation. It also markets a separate fulfilment product, Fulfillzy, at fulfillzy.com.

ClickPost's one line summary is consistent: "a leading logistics start-up company that leverages the science of warehousing to deliver the ultimate in end-to-end logistics and warehousing solutions."

For the unified model PurpleDrone is a source of shipments only over the API. The warehousing side presumably holds inventory, but no inventory API is evidenced and the WMS is sold as a service rather than as software.

One material operational limit: Unicommerce warns of "limited pickup serviceability" and instructs the seller to "contact Purpledrone team and get the required pickup Pincodes registered where warehouse located, before using the facility pincode as pickup pincode". Pickup locations are whitelisted out of band. A connector cannot discover or register them itself.

API access

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

• No developer or documentation host exists. purpledrone.in is a WordPress marketing site whose only interactive elements are a quote request form and a tracking link.
• Credentials come from a named human. ClickPost says the username and password come "from your purple drone relationship manager"; Unicommerce says they "will be provided by the PurpleDrone team for every seller".
• ClickPost carries a single courier partner id, 372, documented under "Purpledrone RVP" (reverse). Unicommerce supports both forward and reverse shipments, so the forward flow exists too.
• No official SDK in any language, no Postman collection, no OpenAPI specification and no PurpleDrone owned repositories were found on GitHub.

Authentication

Not documented first party. ClickPost's carrier setup page gives the shape:

Unicommerce's connector form asks for the same User Name and Password, plus Service Type (Surface, Air or road, "or the keyword specified by the Shipper"), Hand Over Mode (blank by default, or Pickup, Drop or Pick), Pickup Address Id (blank by default) and Fetch Label Link (set to False, because the label PDF is supplied by PurpleDrone).

So the model is: POST credentials, receive a token, present it on subsequent calls. The token endpoint, header name, lifetime and refresh behaviour are unpublished. 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 by both sources. ClickPost lists "Tracking via Polling" among the integrated services, and Unicommerce states "Tracking is provided in Uniware for Purpledrone shipped orders" with a Tracking Enabled switch on the connector.

Note what is absent: ClickPost lists polling only. Where it integrates a carrier that supports push, it says so explicitly (Proship, for instance, is listed with both "Tracking via Polling" and "Tracking via Webhooks"). The omission here is meaningful evidence that PurpleDrone has no webhook.

The tracking response shape, status vocabulary, scan history structure and any batch limit are not published.

Returns and cancellations

Reverse pickup is a first class service, and it is the flow ClickPost documents. Unicommerce configures a ReversePickup-Prepaid shipping method with AWB generation set to API and lists "Both Forward and Reverse shipment supported".

Cancellation is confirmed by ClickPost for the reverse flow.

Serviceability, rates, NDR, POD and settlements

None are documented. Unicommerce requires serviceability to be defined manually in Uniware and separately warns that pickup pincodes must be registered by the PurpleDrone team in advance, which together indicate that no serviceability lookup is available over the API. No rate card, NDR action, proof of delivery, COD remittance or settlement surface is evidenced anywhere.

Writing back: listings, price and stock

Not applicable, this is a carrier. PurpleDrone holds no catalogue, price or stock. The write path is the shipment lifecycle, and it carries one constraint that shapes the whole integration.

That changes the connector design. The AWB is not minted by the carrier at creation time, the way it is on Proship, Blitz, Shipway, NimbusPost and most others. Instead the seller holds a finite series of waybill numbers issued out of band and consumes one per shipment. A connector therefore needs:

• A store of unconsumed AWBs, loaded from a file the relationship manager supplies.
• An allocation step that reserves one AWB per shipment before the creation call, and that is safe against concurrent creates.
• A low watermark alarm, because running out of AWBs stops shipping entirely and replenishment is a human request, not an API call.
• A reconciliation job, since an AWB consumed on a create that then failed is effectively burned unless the carrier says otherwise.

Beyond that, the operations are:

• Create a forward shipment. Unicommerce configures COD and prepaid forward methods with API AWB generation.
• Create a reverse shipment. The flow ClickPost documents, against the same pre assigned AWB pool.
• Cancel. Confirmed by ClickPost.

Labels: Unicommerce states "Label pdf is provided by Purpledrone" and sets Fetch Label Link to False to use the carrier's format. For reverse shipments ClickPost notes no label is produced at all: "Labels are not required in India for reverse pickups, hence no labels are generated for Purpledrone RVP." Manifests, by contrast, are generated by the integrator (Unicommerce: "Manifest is provided by Uniware"), so a connector should expect to produce its own manifest.

There is no evidence of a separate pickup request call. Hand Over Mode is a connector level constant.

Webhooks and notifications

None. ClickPost, which integrates hundreds of carriers and distinguishes carefully between polling and webhook tracking, lists polling only for PurpleDrone. No callback URL, event catalogue, signature scheme or retry policy is documented anywhere.

Poll instead. With a 500 pincode last mile network and no published batch read, expect one request per AWB. A 30 to 60 minute cadence on the open shipment set is proportionate for a standard delivery network. Ask about a batch tracking call during onboarding, because without one the request count scales linearly with open shipments and that is the binding constraint.

Rate limits and pagination

Not published. No rate limit figure, quota header, burst allowance, 429 behaviour, page size, cursor or date window is documented in any source, and no list read is evidenced at all.

The practical planning constraint is the pre assigned AWB pool rather than request volume: shipment creation is bounded by how many waybill numbers the seller currently holds, which is a supply question for the relationship manager, not a rate limit.

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.
• The pre assigned AWB mechanism is documented only from ClickPost's side. What a waybill file looks like, how many are issued at a time, what happens to an AWB consumed on a failed create, and whether there is any API to check remaining balance are all unknown. These are the first questions to ask.
• Whether the forward flow has the same pre assigned AWB constraint as the reverse flow is not stated. ClickPost documents the constraint on the RVP integration specifically.
• Pickup pincodes are whitelisted by the PurpleDrone team. There is no way to discover serviceable pickup locations over the API.
• No webhook, no serviceability lookup, no rate card, no NDR action, no proof of delivery and no COD remittance or settlement surface.
• No batch tracking read is evidenced, which caps how tightly the open shipment set can be polled.
• PurpleDrone also markets a fulfilment product, Fulfillzy, on a separate domain. Whether it shares the same API, credentials or waybill pool is unknown.
• Its published coverage (500 or more pincodes) is a fraction of a national carrier's. Serviceability, not API design, is likely to be the practical limit on how much volume can be routed here.

Sources

• ClickPost carrier setup, Purpledrone RVP (courier partner id 372)
• Unicommerce knowledge base, Integration with PurpleDrone
• PurpleDrone product site
• PurpleDrone last mile delivery page
• PurpleDrone reverse pickup page
• Fulfillzy, PurpleDrone's fulfilment product