Pickrr

Pickrr, the shipping aggregator acquired by Shiprocket: an auth_token in every JSON body, place-order, tracking-json and order-cancellation. Hosts no longer answer.

Pickrr was an Indian shipping aggregator in the same category as Shiprocket and NimbusPost: a seller signed up, connected a store, and got rate shopped access to Delhivery, Blue Dart, Xpressbees, Ecom Express and the rest behind one API and one wallet. Shiprocket acquired it in 2022. Four years on, the platform has been wound down rather than maintained: pickrr.com, api.pickrr.com and track.pickrr.com all still hold DNS records pointing at AWS Mumbai addresses, but none of them accepts a TCP connection on port 80 or 443. This page records what the API was, because integrations against it still exist in the wild, and is explicit that the destination for any new work is /connectors/shiprocket.

At a glance

Warning

Do not build a new Pickrr connector. Verified on 2026-09-22: pickrr.com resolves to 3.111.12.227, api.pickrr.com to 3.111.129.191 and track.pickrr.com to 35.154.89.1, and every one of them times out on connect for both port 80 and port 443. The MX records still point at Google Workspace, so the domain is maintained as a mailbox, not as a platform.

What it is

Pickrr Technologies was founded in 2015 and built the standard Indian aggregator product: a seller panel, plugins for Shopify, WooCommerce and Magento, rate shopping across carriers, a prepaid wallet, COD remittance and a branded tracking page. Its customer base was the same long tail of small and mid sized sellers Shiprocket serves.

Shiprocket acquired Pickrr in 2022, in what was reported at the time as one of the larger consolidation moves in Indian logistics technology. As with most acquisitions in this space, the outcome for the API was migration rather than coexistence: sellers were moved onto Shiprocket's platform and Pickrr's own endpoints were eventually switched off.

For a commerce database the practical consequence is small but real. A seller with several years of history may have Pickrr AWBs in their order records, and those AWBs cannot be re-tracked. Whatever scan history was captured while the API was live is all there is.

API access

Access was never self serve in the developer sense: a seller signed up for Pickrr, and the panel or the account team issued an auth_token. There was no OAuth, no client id and secret, no console and no scopes.

Historical hosts:

Open source clients disagree about the host: one production integration reads it from configuration, one Python package hard codes http://www.pickrr.com/api/, and one provider class uses https://pickrr.com/api. All three use the same paths beneath, which suggests the API was served from the main web host rather than from a dedicated API host, with api.pickrr.com as a later addition.

There were no official SDKs.

Authentication

There was nothing to exchange and nothing to refresh. The auth_token was a field in the JSON request body:

curl -X POST 'https://pickrr.com/api/place-order/' \
  -H 'Content-Type: application/json' \
  -d '{"auth_token":"<token>","from_name":"Main Warehouse", "to_name":"Ramesh Kumar"}'

This is worth noting for anyone auditing an inherited integration: because the token travelled in the body rather than a header, it will not appear in the places a secret scanner usually looks, and it will appear in any request body logging you have.

The read side was different. Tracking was a GET with the tracking id as a query parameter and no token at all, which made Pickrr tracking URLs publicly enumerable by AWB. That is a design worth remembering as an anti pattern.

Multi account was one auth_token per Pickrr seller account.

Objects we can read

None of these respond today.

Shipments and tracking

GET /api/tracking-json/?tracking_id=<awb>, unauthenticated.

The response carried a status list, with each entry exposing at least status_time, status_body and status_location, which production integrations mapped directly onto a time, status and location triple. Errors came back under an error key rather than as an HTTP status, so clients branched on the presence of that key.

There was no pagination, no date window and no "changed since" query: a lookup by AWB. A human readable tracking page lived at /api/tracking/<awb>.

No proof of delivery artefact appears in any integration.

Orders, listings, inventory, returns, settlements

None appear in any public integration. Pickrr's panel certainly held orders, wallet transactions and COD remittance records, as every aggregator's does, but no open source client reads them, so whether they were exposed over the API cannot be established now.

Writing back: listings, price and stock

Not applicable, this is a carrier aggregator rather than a sales channel. There were no listings, no prices and no stock. The write path was order placement and cancellation.

Place an order

POST /api/place-order/ with a JSON body carrying the auth_token and a flat set of shipment fields. The field names confirmed by a production integration:

The response carried tracking_id, which was the AWB to store, pickup_time, and error when something went wrong. There was no success boolean: clients derived success from the absence of error.

The flat, snake case, address-prefixed field naming (from_* and to_*) is the same pattern Delhivery uses and is unlike Shiprocket's nested billing_* and shipping_* blocks, so an integration migrating from Pickrr to Shiprocket is a rewrite of the request builder, not a rename.

Cancel an order

POST /api/order-cancellation/ with the auth_token and order_id in the JSON body. Confirmed by two independent clients.

Pickup, label, manifest, NDR

No endpoints for any of these appear in any public integration. Pickrr's panel offered all four, so they very likely existed in the seller documentation; nothing public confirms their paths or shapes, and guessing at them now would be pointless since the host is down.

Webhooks and notifications

Pickrr did push events. A public webhook client repository handles Pickrr alongside other aggregators and includes an NDR preparator for it, which establishes that tracking and NDR events were pushed to client endpoints. The subscription mechanism was a configuration request to Pickrr rather than a self serve endpoint, and the body shape is not verifiable from a public source.

For a live system today, the answer is not polling: it is Shiprocket's webhook, documented at /connectors/shiprocket.

Rate limits and pagination

Neither was published and neither can be measured. There is no pagination anywhere in the endpoints that are known: tracking is a lookup by key and order placement takes one shipment.

Mapping to the unified model

Historical only. Pickrr contributed shipments and nothing else.

ship_to_address maps to the to_* fields you sent, which are PII. locations maps to the from_* fields, sent per shipment rather than registered once.

Gaps and open questions

The platform is off. Every host times out. Treat any Pickrr connector as a migration task.
The carrier behind each shipment is unrecoverable from the API. Pickrr rate shopped across carriers, and no public integration reads a field naming the chosen carrier. If your historical records only say "Pickrr", you cannot now resolve which carrier actually moved the box.
Most of the API is unknown. Only three endpoints appear in public code: place order, tracking and cancellation. Pickup, label, manifest, NDR, serviceability, rate cards and wallet or remittance reads are all unverifiable.
Tracking was unauthenticated. If you inherit a system that exposes a Pickrr style tracking proxy, check whether that property was carried forward into its replacement.
Webhook shape unknown. Its existence is established by a public webhook client; its body is not.
No official statement on API sunset. Neither Pickrr nor Shiprocket publishes a migration guide from the Pickrr API to Shiprocket's. That conversation is with Shiprocket support.

Sources

Verified live on 2026-09-22:

DNS: pickrr.com resolves to 3.111.12.227 with www.pickrr.com as an alias, api.pickrr.com to 3.111.129.191, track.pickrr.com to 35.154.89.1. MX records point at Google Workspace
TCP: connections to all three hosts on ports 80 and 443 time out after 8 seconds. No HTTP response of any kind was obtained
shiprocket.in/pickrr/: HTTP 404, so Shiprocket publishes no landing page for the acquired brand

Secondary, open source clients read for the historical API shape:

elanic-tech/angarum, Partners/pickrr.js, a production multi carrier integration: /api/place-order/ with auth_token in the body, the from_* and to_* field mapping, the cod_amount deletion for prepaid, the tracking_id, pickup_time and error response fields, /api/tracking-json/ with tracking_id and the status_time, status_body, status_location triple, /api/tracking/<awb> as the human tracking page, and /api/order-cancellation/ with order_id
harishbisht/pickrr, a Python package: independent confirmation of all three paths, the JSON content type, the auth_token in the body, and the http://www.pickrr.com/api/ host form
The-Motor-Element/shipping-backend, app/services/providers/pickrr_provider.py: the https://pickrr.com/api and https://staging.pickrr.com/api host pair, and the auth_token credential name. This provider is partly mock backed, so it was used only for host names
spandan9898/somereference_trck: a webhook client that handles Pickrr among other aggregators and includes an NDR preparator for it, establishing that Pickrr pushed tracking and NDR events