Pico Express

Pico Xpress is an Indian technology led last mile carrier focused on next day and quick commerce delivery. It is a carrier, not a sales channel: there is no catalogue, price or stock surface, and the objects that matter are serviceability, shipment creation with an AWB and label, pickup, tracking, proof of delivery, NDR and returns. It publishes no API documentation. What is verifiable comes from two aggregator knowledge bases that have built the integration, from its own web application, and from company registry data.

At a glance

What it is

Pico Xpress Private Limited is a Bengaluru registered logistics company (CIN U52219KA2023PTC171252), incorporated in 2023, so it is a young business. Its own positioning, taken from its web application, is "Bharat's only Next Day Delivery platform", a technology enabled logistics service provider covering end to end quick commerce logistics, omni-channel fulfilment and retail distribution, plus a "Digital Cash and Material Reco" product, with AI positioning on last mile allocation. It runs a rider recruitment funnel advertising earnings up to Rs 50,000 a month, which places it in the owned or managed fleet model rather than pure brokerage.

It is India only. ClickPost's carrier page lists its service families as B2C, B2B, MPS (multi piece shipment), HLD (heavy or large delivery), domestic and forward delivery, and country as India. It is not a marketplace, not D2C-only and not social commerce: it is a third party carrier that a seller books through, either directly or through an order management platform.

API access

There is no self serve route and no developer console. The only documented path to credentials, from Unicommerce's own integration article, is that the Pico Xpress team issues a username and password per seller. That makes this an account managed integration: a commercial conversation first, credentials second.

Three routes exist in practice, in descending order of how well evidenced they are:

1. Through Unicommerce (Uniware). Settings, then Shipping Providers, then Add Shipping Provider, then search for "PicoXpress". Unicommerce holds the credentials in its connector and speaks the Pico Xpress API on the seller's behalf.
2. Through ClickPost. ClickPost lists Pico Xpress as carrier partner ID 5 in its integration library and exposes it behind ClickPost's own uniform API, which is documented publicly at docs.clickpost.ai. For a unified database this is usually the cheaper route, because one ClickPost integration covers many carriers with one schema.
3. Directly. Possible in principle, since the API exists, but nothing about it is published. A direct integration starts with a request to Pico Xpress for their documentation.

A third route once existed and has gone: EasyEcom listed Pico Express as a carrier integration with the line "Pico Express looks after the entire logistics arm for eCommerce enterprises, with EasyEcom interfacing its API to automate shipping workflows". That page (easyecom.io/integration/pico-express) now returns 404 and is only readable in the Internet Archive snapshot of 2026-03-05, where the page was still marked "Dummy" by EasyEcom's own template. Treat it as weak evidence that an API exists and no evidence at all about its shape.

No SDK, Postman collection, OpenAPI specification or versioning scheme is published in any language. No API version is known to be in force and no deprecation schedule exists.

Authentication

Not published. The only concrete facts available:

• Unicommerce's connector takes User Name and Password, both mandatory, "provided by the PicoXpress team", plus four configuration values that are not credentials: Service Type (mandatory, Surface, Air or road, with Unicommerce advising road as the usual value), Hand Over Mode (blank by default, or Pickup, Drop, Pick, with Drop advised), Pickup Address Id (blank by default) and Fetch Label Link (mandatory, and Unicommerce says to set it False because the label PDF is supplied by the Pico Xpress team).
• Unicommerce's flow has a separate "Connect" action after saving the credentials, which authenticates them. That implies a live verification call, but whether it exchanges the credentials for a token or simply tests a basic auth request is not stated.

No token lifetime, refresh flow, scope model, or multi account mechanism is documented. There is no way to write a credential store design against this without the vendor's documentation. What can be said is that the credential is per seller, not per application, so a connector must hold one username and password pair per seller account and must expect no OAuth style delegation.

No code sample can be given here. Publishing a fabricated token request or authenticated call would be worse than publishing nothing, and nothing about the request shape is known.

Objects we can read

No endpoint, parameter, pagination model or field name is published for any object. What follows is the capability matrix as attested by ClickPost's carrier integration library, read on 2026-09-22, which lists a tick against each of the following for Pico Xpress (partner ID 5).

Shipments and tracking

Supported both ways: tracking via polling and tracking via webhook. ClickPost describes the underlying carrier call as a "Track Shipment API" returning "real-time shipment tracking updates and delivery milestones". Unicommerce independently confirms that "AWB tracking is present" and that the AWB itself is fetched from Pico Xpress rather than allocated by the seller.

Whether the tracking response carries a full scan history with per event location and timestamp, or only a current status, is not established. Event names, status codes and the timestamp format are all unknown. Sample response not published.

Proof of delivery

Supported per ClickPost. The artefact type (signature image, photograph, OTP record) and how it is retrieved are not published.

Returns and NDR

NDR is supported, with an "NDR Action Update" call described as automating customer communication and resolution for failed delivery attempts. Return webhooks are listed separately, described as enabling automated returns processing and reverse logistics.

This is where the two sources disagree and the disagreement matters. Unicommerce states flatly that "Only Forward shipments supported" for its Pico Xpress connector, while ClickPost lists return webhooks as available. The most likely reconciliation is that the carrier supports reverse events but Unicommerce has not built the reverse leg, rather than that either source is wrong. It should be confirmed before a reverse flow is designed. RTO handling specifically is not addressed by either source.

Rates and serviceability

An EDD API is listed, described as calculating estimated delivery dates from destination pincodes and serviceability. Unicommerce's connector setup offers serviceability scoped as "Any facility to any Place", "This Facility to selected Pincodes" or "Any Facility to Selected Pincodes", with the second and third requiring the seller to upload a pincode list into Uniware. The implication is that Pico Xpress does not expose a machine readable serviceability list to Unicommerce, and coverage is maintained manually on the aggregator side. No rate or price quote API is listed anywhere.

Orders, order items, products, listings, inventory, payments and settlements, customers, locations

None. A carrier holds none of these. COD is implied by Unicommerce's instruction to add both COD and Prepaid shipping methods, but no COD remittance, statement or settlement API is listed by any source.

Writing back: listings, price and stock

Not applicable, this is a carrier. There is no catalogue, price or stock surface to write to.

The write path is the shipment lifecycle, and the following operations are attested by ClickPost:

No endpoint, method, request body, batch limit or confirmation mechanism is published for any of these. Multi piece shipments are supported as a service family (MPS), so a create call probably accepts several packages, but that is an inference from a service name.

Webhooks and notifications

Webhooks exist. ClickPost's matrix ticks both tracking via webhook and return webhooks, which is a stronger claim than most small Indian carriers can make. Everything operational about them is unpublished: there is no event type list, no subscription or registration endpoint, no signing secret or signature header, no retry or replay policy and no delivery guarantee.

Until the vendor's documentation is in hand, the safe design is:

• Treat the webhook as an unauthenticated POST from an unknown address range, and require the URL itself to carry an unguessable secret path segment, plus a shared bearer token if Pico Xpress will set one.
• Do not make the webhook the only source of truth. Poll the tracking API for every shipment not in a terminal state. Without a published rate limit, hourly per open shipment with low concurrency is a defensible starting point, tightened only after the vendor confirms headroom.
• If integrating through ClickPost instead, use ClickPost's own webhook contract, which is documented and signed, and let it absorb the carrier's quirks.

Rate limits and pagination

Nothing is published: no limits, no quota headers, no burst allowance, no pagination model, no list endpoint and no date window query. For planning purposes, assume there is no bulk or backfill route, keep per seller concurrency in the low single digits, record every AWB at the moment it is issued because there may be no way to enumerate shipments later, and confirm the real numbers with the Pico Xpress team before committing to a sync cadence.

Mapping to the unified model

Only the object level mapping can be stated. No field names exist to map onto, so every platform field below is marked as unknown rather than guessed.

Gaps and open questions

• Not one endpoint, header, parameter or field name is verifiable. Everything on this page is capability presence, not contract. A direct integration cannot be scoped from public sources.
• The two aggregator sources contradict each other on reverse logistics: ClickPost lists return webhooks, Unicommerce says forward shipments only.
• Whether serviceability is machine readable is doubtful. Unicommerce asks the seller to upload pincode lists, which suggests it is not.
• No rate or pricing API is listed by anyone, so shipping cost per shipment may have to come from invoices rather than the API.
• Authentication is a username and password with an unknown exchange mechanism, unknown token lifetime and no described rotation path.
• No sandbox is mentioned, so testing likely requires a live contracted account.
• The company was incorporated in 2023 and the EasyEcom listing that once described it has been withdrawn. Whether that reflects EasyEcom pruning a stub integration or a change in the commercial relationship is unknown, and it is worth checking the carrier is still actively onboarding before investing in a direct build.
• Recommended next step: request the Pico Xpress integration document from the carrier, and in parallel price the ClickPost route, which is documented, signed and already built.

Sources

• Unicommerce support: Integration with PicoXpress for the connector parameters, credential issuance, AWB and label ownership, serviceability scoping and the forward only statement
• ClickPost carrier integration: Pico Xpress for the capability matrix (partner ID 5, order creation, cancellation, polling and webhook tracking, POD, NDR, pickup request, AWB and label generation), the service families and the API list
• picoxpress.com application bundle for the company positioning, and live probes on 2026-09-22 confirming api.picoxpress.com answers with structured JSON errors while no documentation route exists
• The Company Check: Pico Xpress Private Limited for the CIN, incorporation year and registered state
• Internet Archive snapshot of easyecom.io/integration/pico-express dated 2026-03-05, the only remaining record of the EasyEcom listing, which now returns 404