HealthKart

HealthKart runs a seller programme at /healthkart-for-sellers but publishes no API: the page is client-rendered, no developer portal exists and no OMS lists a connector.

HealthKart is India's largest online retailer of sports nutrition, supplements and wellness products, founded in March 2011 and selling through its website, app and a network of physical stores. It is unusual in this set because it is primarily a house-brand company that also retails third-party brands: MuscleBlaze, HK Vitals, TrueBasics, Gritzo, bGREEN, MB and Z Verse are all HealthKart's own labels, and they dominate its own merchandising. A seller programme does exist, linked from the site footer as "Sell On HealthKart", but there is no developer portal, no published API and no order management system with a HealthKart connector.

At a glance

What it is

HealthKart positions itself on authenticity, which is the defining issue in Indian sports nutrition: counterfeit whey protein and imported supplements are endemic, and HealthKart's pitch is "100% Original & Authentic" with "tight control on sourcing and distribution". It says it carries products from 50 or more domestic and international brands, alongside its own. It runs offline stores with a locator on the site, a loyalty currency called HK Cash, free expert consultation, and a content operation of blogs and videos.

The house-brand concentration matters for anyone assessing this channel. A retailer whose own labels carry the margin has limited incentive to invest in third-party seller tooling, and that is consistent with what we found: a seller programme that exists as a page, and nothing behind it that a machine can talk to.

Category specifics that will shape any connector here: supplements are a batch-and-expiry category, so lot numbers and shelf life are part of the real data model even though the unified schema has no field for them, and nutraceutical labelling rules make listing content unusually tightly controlled.

API access

No public API. The evidence:

  • The footer carries a "Sell On HealthKart" link to /healthkart-for-sellers, so a seller programme is real and publicly acknowledged.
  • That URL returns HTTP 200 with about 172 KB of HTML, but the body is the generic HealthKart site shell: navigation, category links, footer and copyright, with no seller content. The page is rendered client-side and its content was not reachable without executing JavaScript on 2026-09-21. No registration steps, requirements, commission schedule, fulfilment model or panel description could be read.
  • seller.healthkart.com does not resolve in DNS.
  • No developers, API or integrations link appears anywhere in the footer.
  • EasyEcom's public knowledge base holds 328 articles and contains no HealthKart article.
  • Unicommerce's integrations directory does not list HealthKart.

No official SDK, Postman collection or public GitHub repository for a HealthKart seller API was found.

Note

The seller page being client-rendered is a fetching limitation, not proof of absence. Someone with a browser should read healthkart.com/healthkart-for-sellers before this page is treated as settled: it may well describe a panel, a commission structure and a fulfilment model, none of which we could see. What it is very unlikely to describe, given that neither major Indian OMS has built a connector, is an API.

Authentication

Not published. No token endpoint, key issuance process, header or signature scheme is documented anywhere. The realistic assumption is a seller panel username and password issued at onboarding. No request or response sample can be shown without inventing one.

Objects we can read

Nothing is confirmed readable by machine. The list below is the checklist for a seller conversation rather than a description of an available API. For every object, the endpoint, parameters, pagination and sample response are not published.

  • Orders. Consumer orders against the seller's listings, with the usual Indian marketplace shape: order id, state, placed timestamp, prepaid or cod, and a delivery address that is probably masked.
  • Order items. Lines carrying a HealthKart product identifier and the seller's SKU, with quantity and price. Supplements sell in flavour and pack-size variants, so the variant is the identity.
  • Products and listings. Whether sellers create their own listings or list against HealthKart's existing catalogue entries is unknown, and it is the most consequential unknown here. Catalogue-matching platforms and seller-authored-catalogue platforms need completely different connectors.
  • Inventory. Seller-declared stock. In this category stock should really be tracked per batch and expiry, which no generic schema handles.
  • Shipments and tracking. Unknown whether HealthKart warehouses seller stock or the seller ships direct.
  • Returns and cancellations. Supplements have restricted returns for safety and tamper-evidence reasons, so expect a narrow, policy-driven return flow rather than free returns.
  • Payments and settlements. Commission and logistics deductions on a payout cycle. Undocumented.
  • Customers. Assume masked. Health and nutrition purchase history is sensitive even where it is not formally health data; treat it as restricted.
  • Locations. Seller pickup locations configured at onboarding.

Writing back: listings, price and stock

No documented write path. The manual route on a platform of this type is the seller panel, with a bulk upload template for volume changes to price and stock. Whether HealthKart provides one, and in what format, could not be established.

Note that HealthKart's own-label concentration means shopper-facing price on a third-party listing may be less under the seller's control than on a neutral marketplace, since the retailer has a direct commercial interest in the competing house product. Establish who controls the selling price before building anything that assumes price write-back works.

Webhooks and notifications

None documented. Assume none. If a panel export is the only route, the practical cadence is a daily scheduled export of orders and settlements dropped into a watched folder, with listings and stock re-exported only on change. That is a manual pipeline and should be labelled as such in the data model, with a provenance flag distinguishing it from API-sourced records.

Rate limits and pagination

Not applicable, since no API is available.

Mapping to the unified model

Provisional. Platform field names are unknown, so the right-hand column records what the field would need to contain.

Gaps and open questions

  • What healthkart.com/healthkart-for-sellers actually says. It is client-rendered and we could not read it. This should be checked in a browser before any further work.
  • Whether sellers author their own listings or match against HealthKart's catalogue. This determines the entire shape of the listings connector.
  • Whether HealthKart's seller model is marketplace commission or vendor purchase-order. Given how house-brand-heavy the retailer is, a direct buying relationship for third-party brands is at least as likely as a marketplace listing model.
  • Whether the seller panel offers any scheduled or bulk export, which is the difference between a daily automated pipeline and someone clicking a download button.
  • How batch numbers and expiry dates are carried, since they are operationally mandatory in this category and absent from the unified schema.
  • Who sets the shopper-facing price on a third-party listing.

Sources

  • HealthKart homepage and footer, giving the March 2011 founding, the authenticity positioning, the 50-plus brand claim, the house-brand list and the "Sell On HealthKart" link: healthkart.com
  • HealthKart seller page, which returned HTTP 200 but rendered only the site shell to a non-JavaScript fetcher on 2026-09-21: healthkart.com/healthkart-for-sellers
  • EasyEcom knowledge base, all 328 published articles enumerated on 2026-09-21: no HealthKart article exists. support.easyecom.io
  • Unicommerce integrations directory, which does not list HealthKart: unicommerce.com/integrations
  • seller.healthkart.com does not resolve, as of 2026-09-21