Shiperfecto

Shiperfecto is an Indian warehousing and shipping aggregator, a product of Shipping Imperio Private Limited. It combines third party fulfilment (pick, pack and ship from a nationwide warehouse network) with carrier aggregation, allocating shipments across its delivery partners by a priority the seller sets in the Shiperfecto panel. There is no public developer portal. Two artifacts establish the API's shape: a published Postman request showing the base URL and auth header, and Unicommerce's connector documentation describing the credential set and supported operations.

At a glance

What it is

Shiperfecto describes itself as an end-to-end warehousing and logistics hub offering product picking, packing and shipping, inventory management across a nationwide fulfilment network, trained personnel, pickups and returns. Its marketing emphasises an AI enabled dashboard, one click channel integration and "push orders via API" as the integration path. The seller panel is at app.shiperfecto.com, and a buyer tracking page sits at shiperfecto.com/tracking.

Unicommerce classifies it as "a Shipping Aggregator courier partner that provides services in India", in the same category as Shiprocket and Proship. The consequence for a connector is the same as for Proship: the actual carrier is chosen by Shiperfecto, not by the caller. Unicommerce's note is explicit that rather than adding each downstream courier separately, "the system will allocate the correct shipping company through a single Shiperfecto added in Uniware based on the priority set on Shiperfecto seller panel which is as per the shipping matrices like Rating, Pricing or Delivery time."

For the unified model Shiperfecto is a source of shipments and, in principle, locations and inventory through its fulfilment side. Only the shipping surface is evidenced.

API access

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

• No documentation host. The marketing site links only to the seller panel, a tracking page and policy pages.
• Base URL, confirmed by a captured request: app.shiperfecto.com/api/v1/. The root of that path returns a Node style Cannot GET /api/v1/, so the gateway is an Express application, and routes exist only under their specific paths.
• Credentials come from the Shiperfecto team. Unicommerce states plainly: "The API username and password can be obtained from Shiperfecto team."
• Pickup locations are issued out of band as numeric ids. Unicommerce instructs the operator to use a "Pickup Address Id ... provided by Shiperfecto team for the respective sellers", giving examples such as 17 or 18, and requires a separate shipping provider entry per pickup location when a seller has several. There is no evidence of an API to create or list them.
• No official SDK in any language, no OpenAPI specification and no Shiperfecto owned repositories were found on GitHub.

Authentication

Two credential models appear in the two sources, and they are probably two ends of the same flow.

Static token header (captured from a real request)

POST /api/v1/b2b/pickup HTTP/1.1
Host: app.shiperfecto.com
Authorization: Token 7mZFrGopof9AH7DTTug4pLgTfUqa1Rg...
Content-Type: application/json

{
  "warehouse_id": 151,
  "pickup_date": "2025-03-19",
  "pickup_time": "13:00:00",
  "pickup_partner": "DelhiveryB2B"
}

The Token <40 character key> form is the Django REST Framework TokenAuthentication convention, and the sample key is exactly 40 characters, which is the DRF default. That strongly suggests a per user API key with no expiry and no refresh, issued server side and revoked by rotation.

Username and password (Unicommerce connector)

Unicommerce's connector form collects User Name and Password and has a "Connect" step that authenticates before saving, so a login call exists that presumably returns the token above. The login endpoint, its request body and the token lifetime are not published.

Multi account support means one token per Shiperfecto seller account, and in Unicommerce's model one configured provider per pickup location id.

Objects we can read

Shipments and tracking

Tracking is confirmed. Unicommerce sets Tracking Enabled to Yes by default for this provider "as shipping provider provides tracking info", and lists "AWB tracking is present" among the feature highlights.

The tracking endpoint path, response shape, status vocabulary, scan history structure and any batch limit are not published. Because Shiperfecto allocates a downstream courier, the tracking response should be expected to name the underlying carrier, but that is an inference.

Returns and cancellations

Reverse shipments are supported. Unicommerce configures a ReversePickup-Prepaid shipping method with AWB generation set to API, and lists "Both Forward and Reverse Shipments are supported".

No cancellation endpoint is evidenced, which is unusual and worth asking about.

Serviceability, rates, NDR, POD and settlements

None are documented. Unicommerce recommends configuring serviceability as "Any facility to any Place", which means no serviceability lookup was used in that integration. 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 warehousing and carrier aggregator. Shiperfecto holds physical stock but exposes no catalogue, price or stock API. The write path is the shipment lifecycle.

Confirmed operations:

• Create a forward shipment. Unicommerce configures COD and prepaid forward methods with AWB generation set to API, so the AWB is minted by Shiperfecto at creation.
• Create a reverse shipment. Same mechanism, ReversePickup-Prepaid.
• Request a B2B pickup. POST /api/v1/b2b/pickup, the one endpoint whose exact path and request body are known:

Two things follow from that request body. The b2b path segment implies a parallel b2c namespace. And pickup_partner is a caller supplied carrier name, so on the B2B pickup flow at least, the seller can pin the downstream carrier rather than letting the allocation engine choose.

Labels: the two sources disagree. Unicommerce's feature list says "Label pdf is provided by Shiperfecto", but its connector instruction says to set Fetch Label Link to False with the explanation that "ShiperFecto will direct their clients to download labels from their platform in order to customize labels as per their business needs". The practical reading is that labels exist on the Shiperfecto platform and are downloaded from the panel, not fetched as a URL on the creation response. Confirm before designing the label path.

Manifests are produced by the integrator (Unicommerce: "Manifest is provided by UC"), so a connector should expect to generate its own.

Webhooks and notifications

Not published. No callback URL, event catalogue, signature scheme or retry policy appears in either source, and Shiperfecto is not carried in ClickPost's carrier documentation set, so there is no third party confirmation of a push channel either.

Poll instead. With no evidence of a batch tracking read, budget one request per open AWB. A 30 to 60 minute cadence on the open shipment set is proportionate for a standard aggregator. Because no rate limit is published, agree the cadence with the Shiperfecto team before going live.

Rate limits and pagination

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

One structural note: the /api/v1/ prefix means the API is versioned, which is better than the unversioned paths several peers use, and gives a breaking change somewhere to land.

Mapping to the unified model

Field names are mostly not published, so this table maps concepts. Only the pickup request fields are exact. Every other row needs confirming against a real response.

Gaps and open questions

• No first party documentation could be read. Only one endpoint path and request body are known exactly.
• The login endpoint that turns the username and password into the Token value is not documented, nor is the token lifetime or rotation process.
• There is no evidence of a cancellation endpoint, which every peer aggregator has. Either it exists and is undocumented, or cancellation is a panel action.
• The b2b path segment implies a b2c namespace, but no B2C endpoint path is known.
• Label handling is contradictory between Unicommerce's feature list and its connector instruction. The likely answer is panel download rather than an API URL, but it needs confirming.
• No serviceability lookup, no rate card, no NDR action, no proof of delivery, no COD remittance and no settlement surface.
• Whether the tracking response exposes the allocated downstream carrier is unverified, and without it every Shiperfecto shipment collapses into one carrier name.
• Pickup locations are issued as opaque numeric ids by a human. There is no way to list or create them, and Unicommerce's guidance of one provider entry per location id suggests the API may be scoped to a single location per credential.
• Shiperfecto is not in ClickPost's carrier set, so unlike Proship or PurpleDrone it cannot be reached through that aggregator.
• A working API key was published in a public Postman collection. That is a signal about the vendor's credential hygiene and is worth raising during onboarding.

Sources

• Shiperfecto product site
• Shiperfecto seller panel
• Unicommerce knowledge base, Integration with Shiperfecto
• Shiperfecto B2b, published Postman collection (B2B pickup request)
• https://app.shiperfecto.com/api/v1/ (live host, returns an Express "Cannot GET" for the bare path)
• https://shiperfecto.in/ (a separate, near empty site under the same brand)