Shyplite

Shyplite was an Indian shipping aggregator of the same type as Shiprocket and Pickrr: a seller signed up, and got rate shopped access to thirty or so carriers behind one panel, one wallet and one API. Its own archived description claimed 70,000 sellers, 26,000 serviceable pincodes and 30 plus courier services. The platform is gone. As of 2026-09-22 shyplite.com has no A record at all, only Google Workspace MX records and an SPF entry, and every subdomain that an integration would need (api, docs, app, developers, www) returns NXDOMAIN. This page records what the API was, because its authentication design is unusual enough to be worth knowing and because integrations against it still exist, and is explicit that it is not a target to build against.

At a glance

What it is

Shyplite was operated out of Nehru Place, New Delhi, and sold the standard aggregator product: a seller panel, storefront plugins, rate shopping across carriers, a prepaid wallet, COD remittance and a branded tracking experience. The last readable archived snapshot of its homepage, from February 2023, positions it as "India's most reliable eCommerce Shipping Solution" and claims 70,000 sellers, 26,000 shipping pincodes and 30 plus courier services.

It competed directly with Shiprocket in a market that consolidated hard: Shiprocket absorbed Pickrr in 2022, Delhivery absorbed Ecom Express by 2025, and the long tail of aggregators thinned accordingly. Shyplite is in that long tail. There is no public acquisition announcement; the domain simply stopped resolving.

For a commerce database the consequence is the same as for Pickrr: a seller with several years of history may have Shyplite AWBs in their records, those AWBs cannot be re-tracked, and whatever was captured while the API was live is all there is.

API access

A Shyplite API integration needed five credentials, which is more than any other carrier in this set:

After login, the returned userToken replaces secret as the HMAC key for all subsequent calls. That is an unusual design: the token is never transmitted, only used to sign, which means a captured request cannot be replayed outside its timestamp window and cannot be used to derive the token.

Base URL: https://api.shyplite.com. Operation names sat directly under the root with no version segment and no resource grouping: login, order, ordercancel, getSlip, getManifestPDF, getserviceability, track, calculateprice.

One later source names https://api.shyplite.com/v2 with a different set of operations, which suggests a v2 API existed at some point. That source is lower confidence and its operation names are not reproduced here. See Gaps.

There were no first party SDKs. A community PHP and Laravel SDK is the most complete public artefact and is the basis for this page.

Authentication

The full sequence, as implemented by the SDK.

1. Compute a signature for the login call. Build the string key:<key>id:<app_id>:timestamp:<unix-timestamp>, HMAC SHA256 it with secret as the key, base64 encode the raw digest, then URL encode the result.
2. Call login. POST /login with Content-Type: application/x-www-form-urlencoded, headers x-appid: <app_id>, x-timestamp: <unix-timestamp> and Authorization: <signature>, and a form body of emailID and password.
3. Read userToken from the response. This is the value you store. It is the HMAC secret for everything that follows.
4. Sign every later request the same way, with userToken as the HMAC key. Recompute the timestamp and therefore the signature on every call. Headers become x-appid, x-sellerid, x-timestamp, Authorization and Content-Type: application/json.

  # timestamp is unix seconds; sign is "key:<key>id:<app_id>:timestamp:<timestamp>"
  # Authorization = urlencode(base64(hmac_sha256(sign, userToken)))
curl -X GET 'https://api.shyplite.com/getserviceability/110030/411001' \
  -H 'x-appid: <app-id>' \
  -H 'x-sellerid: <seller-id>' \
  -H 'x-timestamp: 1790015291' \
  -H 'Authorization: <computed-signature>' \
  -H 'Content-Type: application/json'

Two details that bite. The signed string includes the timestamp but not the request path, method or body, so the signature authenticates the caller and the moment, not the request itself. And the SDK defaults TLS certificate verification to off, with a configuration flag to turn it on, which is a strong hint that the development environment used a self signed certificate and a reminder to check what an inherited integration is actually doing.

The userToken lifetime was never published.

Multi account was one seller_id per Shyplite seller, with app_id potentially shared across sellers by an integrator, which is the closest thing in this set of carriers to a partner model.

Objects we can read

None of these respond today.

Serviceability

GET /getserviceability/{source_pincode}/{destination_pincode}, path parameters rather than a query string or body. Returned the available services for that lane. Response shape not verifiable.

Price

POST /calculateprice with a JSON body describing the shipment. Returned a quote. Request and response field names not verifiable beyond the endpoint name. That Shyplite exposed a pre booking price call at all puts it ahead of Blue Dart and DTDC and on a level with XpressBees and Shiprocket.

Shipments and tracking

GET /track/{awb}, the AWB as a path segment. A lookup by key: no pagination, no date window, no "changed since" filter. Response shape not verifiable.

Slips and manifests

GET /getSlip?orderID=<id> returned a shipping slip object carrying at least a name and a downloadable path. GET /getManifestPDF/{manifest_id} returned a manifest object with the same shape, where the manifest id came from the slip response. So the flow was: create an order, fetch its slip, take the manifest id off the slip, fetch the manifest PDF.

Orders, listings, inventory, returns, settlements

No read endpoints for any of these appear in any public integration. Order creation returned per order status inline, so there was no need to read orders back, but whether a list endpoint existed cannot now be established.

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 creation and cancellation.

Create orders

PUT /order (note the verb: PUT, not POST) with a JSON body of {"orders": [ ... ]}. Up to 25 orders per request, enforced client side by the SDK and described as Shyplite's limit.

The field names, from the SDK's own validation rules, are camelCase, unlike every other Indian carrier in this set:

Note orderId had to be numeric, which is a real constraint: a seller whose own order numbers look like ORD-10231 had to maintain a separate numeric id and a mapping table.

The response was an array positionally parallel to the request array, one element per submitted order, each carrying a success id or an error. The SDK zips the two together by index, so a short or reordered response array would silently mis-attribute results; if you are auditing an inherited integration, check that it does not rely on positional matching.

Cancel orders

POST /ordercancel with {"orders": [ ... ]}, an array of order ids. Batched like creation.

Pickup

No pickup request endpoint appears in the SDK. sellerAddressId on each order points at a pickup address registered in the panel, which suggests pickups were either standing arrangements per address or raised from the panel. Stated as a gap rather than guessed at.

NDR

No NDR endpoint appears in any public integration.

Webhooks and notifications

Not verifiable. No public integration subscribes to a Shyplite webhook or parses one. A later, lower confidence adapter declares webhook signature verification and parsing methods for Shyplite, which implies webhooks existed in some version of the API, but neither the event list nor the signature scheme can be confirmed. Given the HMAC design on the request side, a signed webhook would be consistent, but that is inference, not evidence.

Rate limits and pagination

Neither was published. The one hard limit that is documented is 25 orders per creation request. There is no pagination anywhere in the known endpoints: tracking, slip, manifest and serviceability are all lookups by key.

The signature scheme imposes its own practical constraint: because the timestamp is signed, a client whose clock drifts from the server's will fail authentication on every call. Any reconstruction of this integration would need NTP discipline.

Mapping to the unified model

Historical only. Shyplite contributed shipments and, weakly, locations.

ship_to_address maps to the customer* fields, all PII. locations maps only to sellerAddressId, an opaque numeric reference with no endpoint to resolve it, so the seller's warehouse list was panel only.

Gaps and open questions

• The platform is gone. No A record, no reachable host, no archived documentation. Treat any Shyplite connector as a migration task with no fallback.
• Every response shape is unknown. The SDK builds requests carefully and then hands the decoded response straight back to the caller, so it documents what went in and almost nothing about what came out. Tracking, serviceability, price and the slip and manifest objects are all unverified on the response side.
• Two API generations, one of them unverifiable. The detailed SDK targets unversioned operations under the root. A later adapter targets https://api.shyplite.com/v2 with a different operation set including wallet balance, pickup address management and webhook handling. That adapter could not be corroborated by any second source and is not reproduced here. If you are reading an inherited integration, check which generation it speaks.
• Units are unpublished. Weight and dimension units on packageWeight, packageLength, packageWidth and packageHeight were never stated in any public artefact.
• orderId numeric constraint. Anyone migrating a Shyplite integration will find a numeric id mapping table sitting between their orders and their shipments. It has to be carried forward or the historical join is lost.
• No pickup and no NDR endpoints appear anywhere public.
• TLS verification defaulted to off in the reference SDK. Audit any surviving integration for that setting.
• No rate limits published beyond the 25 order batch cap.

Sources

Verified live on 2026-09-22:

• DNS: shyplite.com has no A record. www.shyplite.com, api.shyplite.com, app.shyplite.com, docs.shyplite.com and developers.shyplite.com all return NXDOMAIN. The apex retains Google Workspace MX records and v=spf1 include:_spf.google.com ~all
• HTTP: every one of those hosts fails to connect

Archived:

• web.archive.org snapshot of shyplite.com, 25 February 2023: the organisation record naming the Nehru Place, New Delhi address, and the description claiming "Trusted by 70,000+ sellers, providing 26000+ shipping pincodes, 30+ courier services"

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

• md-adil/shyplite, a PHP and Laravel SDK, the primary source for this page: the https://api.shyplite.com base, the full operation list (login, order, ordercancel, getSlip, getManifestPDF, getserviceability, track, calculateprice), the HMAC SHA256 signature construction and the key:<key>id:<app_id>:timestamp:<ts> signed string, the x-appid, x-sellerid and x-timestamp headers, the login form fields emailID and password and its userToken response, the PUT /order verb with the orders array and the 25 order cap, the camelCase order field list with its numeric validation rules, and the TLS verification default
• susheelbhai/laraship, src/Adapters/ShypliteAdapter.php: names a https://api.shyplite.com/v2 base and declares rate calculation, booking, tracking, label, pickup scheduling, cancellation, webhook verification, wallet balance and pickup address management methods. This source could not be corroborated and is cited only as evidence that a v2 API existed