intelligent.pageDocs

Shypbuddy

ShypBUDDY Indian multi-courier aggregator in Mumbai; a Direct API channel exists but is granted by a sales conversation and is not publicly documented.

ShypBUDDY is an Indian multi-courier shipping aggregator operated by ShypBUDDY India Private Limited, based in Malad West, Mumbai. It resells Delhivery, Blue Dart, Xpressbees, Ecom Express, DTDC, Shadowfax, Ekart and Amazon shipping to small and mid-size e-commerce sellers on a prepaid wallet model, and adds its own value-added services around cash on delivery risk, delivery confirmation and tracking. For a unified commerce database it is a shipments, NDR, RTO and COD remittance source. It advertises a "Direct API" integration channel but publishes no developer documentation, and access to that channel runs through a sales conversation rather than a console.

At a glance

What it is

ShypBUDDY sits in the crowded second tier of Indian shipping aggregators. The model is standard: no setup fee, no monthly fee, a prepaid wallet that the seller tops up, and margin on the carrier rate. The FAQ states it plainly: "there are no fees to set up your account or any monthly charges", and shipping is paid "using our wallet system".

Two domains serve the same product. shypbuddy.com and shypbuddy.net both resolve and render the same site; shypbuddy.in redirects to shypbuddy.net. Treat .net as the current primary, since it carries the fuller navigation.

Named courier partners: Delhivery, Xpressbees, Blue Dart, Shadowfax, DTDC, Ekart, Amazon, with Ecom Express named in the FAQ. Coverage is sold as pan-India.

The value-added services are where the platform differentiates, and each of them creates data a commerce database would want:

  • BUDDYSHIELD, delivery protection sold as a "100% Delivery Guarantee".
  • BUDDYSURE, a delivery verification service.
  • BUDDYCONFIRM, order confirmation before dispatch. This is the COD risk gate, and its outcome is the single most valuable field ShypBUDDY holds, because it is not visible anywhere in the sales channel.
  • BUDDYQUICK, express delivery.
  • COD to Prepaid conversion.
  • Custom Tracking System and WhatsApp Tracking, both buyer-facing.
  • Reverse Logistics for returns.

Sales channel integrations offered: Shopify (an app called "Shypbuddy India PVT LTD" installed from the Shopify side), WooCommerce (store URL plus consumer key and consumer secret), EasyEcom, and DIRECT-API. In every case the panel flow ends with "Sync Orders" on first connection, after which orders sync automatically.

KYC is mandatory before shipping and differs by entity type: individuals need Aadhaar, PAN and bank verification; sole proprietors and companies additionally need a GST number. That matters for onboarding timelines, not for the connector.

COD remittance is the most concretely documented part of the platform, and the two published sources disagree slightly. The marketing page says "COD Remittance Up To 3x a Week" with a 24 hour processing guarantee, rolling payouts based on delivery date, automated reconciliation, a live dashboard, order-wise breakdown, downloadable statements and no minimum settlement amount. The FAQ says "The remittance cycle operates either weekly or early, depending on your chosen preference." Read together: weekly by default, up to three times a week on a faster plan. Confirm which applies to a given account before reconciling.

Published behaviour on refusal: "If a customer refuses the order, no COD amount is collected, and therefore no settlement is processed. The order is marked as RTO (Return to Origin)". So RTO and a null settlement are the same event, which is the right way to model it.

API access

A DIRECT-API channel exists. Nothing about it is published.

Checks made:

  • docs.shypbuddy.com, api.shypbuddy.com, app.shypbuddy.com and developer.shypbuddy.com do not resolve in DNS.
  • The shypbuddy.com sitemap lists eleven pages: home, about, contact, privacy, blog, FAQ and five value-added service pages. No developer or API page.
  • The .net site's navigation covers solutions, integrations, partners, a rate calculator, tools, tracking, resources and contact. No developer section.
  • The only occurrences of "API" anywhere on the site are the words "Direct API" and "ShypBUDDY API" as labels on the integrations page, and the DIRECT-API entry in the FAQ. Neither links to anything.

The documented route to access, quoted from the FAQ:

  1. Navigate to the left menu and select Channel.
  2. Click on DIRECT-API from the list of channels.
  3. Click on Integration. "This will notify our team, and they will reach out to you."

That is the same flow as the EasyEcom channel, which is also human-mediated. So the API is real, and it is gated behind an account manager. Contact is support@shypbuddy.com, or the key account manager the platform advertises.

Warning

No ShypBUDDY endpoint, base URL, header, parameter or field name is stated on this page, because none could be verified from a first-party source. Third-party posts and generated "API skill" repositories claiming to document Indian aggregator endpoints are common and frequently fabricated. Get the specification from ShypBUDDY in writing.

Authentication

Not published. No scheme, header, token format, lifetime or scope model could be verified. Assume a seller-scoped credential issued when the DIRECT-API channel is enabled, and confirm before designing the credential store. Plan for one credential per seller held against your channel_account_id.

Objects we can read

Everything below exists in the seller panel and is named in first-party material. None is documented as an API.

Orders

Forward Orders and Reverse Orders are separate sections in the panel, populated by channel sync or by direct entry. Because orders originate on Shopify, WooCommerce or EasyEcom, read them from that connector and use ShypBUDDY for the shipping side only.

Order items

Present inside the order in the panel. Not documented.

Products and listings, inventory

None. ShypBUDDY holds no catalogue and no stock.

Shipments and tracking

AWB, courier, status and scan history, plus a custom branded tracking page and WhatsApp tracking to the buyer. Pin code serviceability is exposed as a panel tool and a public rate calculator. A shipping label maker and a weight calculator are published as free tools, which tells you volumetric weight is part of the rating model but not the constants.

Pickup behaviour is documented: once the label is created the selected courier collects, with the first pickup taking 24 to 48 hours to arrange and regular pickups thereafter.

Returns and cancellations

Reverse Logistics is a named service with its own Reverse Orders section in the panel. RTO is the dominant return path and is explicitly tied to COD refusal. No object is documented.

Payments and settlements

The richest ShypBUDDY-only data. The COD remittance surface is described as carrying an order-wise breakdown, settlement history, downloadable statements and tax-ready documentation, with real-time status in the dashboard and notifications per settlement. A Credit summary shows wallet recharge logs.

Ask specifically whether remittance is exposed per shipment or only per payout batch, and whether the wallet ledger (shipping debits, weight-dispute adjustments, VAS charges) is readable. Per-payout-batch only is much less useful, because it cannot be joined to an order.

Customers

Buyer name, address and phone ride on each shipment. All PII. No customer object.

Locations

Pickup addresses are created in the panel under Pickup Address, Add Address. There is no documented warehouse API.

Writing back: listings, price and stock

Not applicable, this is a carrier aggregator. ShypBUDDY owns no listing, no price and no stock, so nothing a buyer sees can be changed through it. Catalogue and price writes belong to the sales channel connector.

The write path that matters is shipment creation and cancellation: create a forward order, choose or let the platform choose a courier, generate the AWB and label, trigger pickup, create a reverse pickup, cancel before pickup, and act on an NDR. All are real panel operations. None is publicly documented, so the specification has to come from ShypBUDDY when the DIRECT-API channel is enabled.

Webhooks and notifications

Not published. ShypBUDDY's notification story is buyer-facing: WhatsApp Tracking and the Custom Tracking System. Whether the platform will POST shipment status changes to a seller's server is not stated anywhere public, and it is the first question to ask.

Until confirmed, plan for polling. For an Indian aggregator with multi-day transit and NDR reattempts, polling active shipments every 2 to 4 hours during business hours catches every meaningful transition, and polling remittance once daily suits a weekly or thrice-weekly cycle. Never poll delivered, cancelled or RTO-complete shipments.

Rate limits and pagination

Not published. No quota numbers, headers, page sizes or 429 semantics. Treat the API as fragile until measured: serialise requests, stay at one or two per second, back off on 429 and 5xx, and agree any historical backfill with ShypBUDDY first.

Mapping to the unified model

Field names cannot be given because none are published. The table below is the target shape to request; every right-hand entry is unverified.

orders

order_items

Not documented. Read from the sales channel.

listings, inventory

Not applicable.

shipments

Carry the BUDDYCONFIRM outcome, the BUDDYSURE verification result and the BUDDYSHIELD flag as enrichment columns. They have no home in the unified schema but they explain RTO behaviour better than anything else on the platform.

returns

RTO dominates. Map an RTO shipment to a returns row with reason from the NDR reason and received_at set when the parcel is delivered back. A customer-initiated reverse pickup is a separate case and should not be conflated with an RTO.

settlements

customers

Buyer name, phone and address ride on the shipment. PII, unmasked. No customer object.

locations

Pickup addresses created in the panel. Not documented.

Gaps and open questions

  • The whole API is undocumented publicly. Auth, base URL, endpoints, webhooks, limits and sandbox are all unknown, and access is granted by a human. The connector cannot be scoped without a specification.
  • Whether webhooks exist. This decides between a cheap push design and an expensive poll across every active shipment.
  • The remittance cycle is described two different ways by two first-party pages: "Up To 3x a Week" on the marketing page, "either weekly or early, depending on your chosen preference" in the FAQ. Both may be true for different plans. Establish which applies per account before reconciling money.
  • Remittance granularity. Order-wise breakdown is promised in the dashboard; whether it is available by API is unknown.
  • The value-added service outcomes. BUDDYCONFIRM, BUDDYSURE and BUDDYSHIELD produce exactly the signals that explain RTO. Whether any of it is readable is unknown and is worth asking about specifically.
  • Status vocabulary. Normalised across eight couriers, or raw passthrough. Either answer changes the amount of mapping work by an order of magnitude.
  • Two live domains. shypbuddy.com and shypbuddy.net both serve the product and shypbuddy.in redirects to .net. Which is canonical, and whether API hosts follow the same split, is unclear.
  • No aggregator-of-aggregators route. ShypBUDDY has no ClickPost carrier integration page and does not appear in Unicommerce's public integration list, so there is no indirect path either.
  • EasyEcom is the nearest thing to a documented route. ShypBUDDY is an EasyEcom channel, so a seller already on EasyEcom may be able to read ShypBUDDY shipment data through EasyEcom rather than directly. EasyEcom's own knowledge base is largely login walled to automated fetchers, so this was not verified.

Sources