Kindlife

kindlife is an Indian beauty and wellness platform specialising in Korean skincare, clean beauty and supplements, operated by AlphaCMA Private Limited. It sells online at kindlife.in, runs try-and-buy counters in a dozen Indian cities, and wraps the commerce in a community layer: live shopping sessions, creator content, reviews, a loyalty programme called Superkind Club, and an assistant called kiki.Ai. For a brand it is a curated channel rather than an open marketplace: kindlife describes its sourcing as "100% authentic, direct sourcing" and onboards brands through a Partner Brand enquiry form. The technically interesting finding is that kindlife runs on CS-Cart, which ships a documented REST API, and that API is live on the site.

At a glance

What it is

kindlife's assortment is led by Korean beauty, with COSRX and A'pieu among the brands it merchandises heavily, alongside Indian skincare, makeup, body care, supplements and immunity products. Its own site claims over 2 million units sold, free shipping above 699 rupees and 5 day returns. Physical try-and-buy presence is listed across Delhi, Noida, Gurugram, Faridabad, Dehradun, Indore, Raipur, Hissar, Jammu, Lucknow, Bareilly and Faizabad, which is a notably tier 2 heavy footprint for a beauty platform.

The commercial model matters more than the technology here. Two signals point to kindlife buying rather than hosting:

• It describes its sourcing as direct, and authenticity in imported K-beauty is only controllable if you own the import chain.
• Brand onboarding runs through a "Partner Brand" link and a /brand-query page, which sits behind a sign-in and is framed as "kindlife connect". That is an enquiry and relationship surface, not a seller console.

If kindlife buys, then a brand on kindlife sees purchase orders and no listing control, exactly as on the other vendor-model platforms in this set, regardless of what the underlying software can do.

API access

kindlife runs CS-Cart. The evidence is unambiguous and was gathered directly from the live site on 2026-09-21:

• The page source carries 38 dispatch= controller references, CS-Cart's routing convention, including dispatch=products.view, dispatch=publicprofile.profiles and custom controllers prefixed kl_, such as dispatch=kl_products.kl_search and dispatch=kl_account.account. The prefix indicates kindlife has its own CS-Cart add-on.
• Category URLs use CS-Cart's filter parameters: features_hash, filter_id, sort_by and sort_order.
• The account area exposes "RMA requests", CS-Cart's name for returns.
• https://www.kindlife.in/api/ responds with {"message":"Unauthorized","status":401} and a JSON content type. So the REST API add-on is enabled and reachable, not disabled.
• https://www.kindlife.in/api/products?items_per_page=1 returns the same 401, confirming the resource naming and CS-Cart's items_per_page pagination parameter are in force.

What that does and does not mean:

• It does mean that if kindlife chooses to give you access, there is a documented, standard API behind it, and no bespoke integration work is needed on the protocol.
• It does not mean a brand can obtain a key. In CS-Cart the API key is generated per admin user inside the store's own administration panel. Issuing one to an outside party means creating an admin account on kindlife's store. Nothing suggests kindlife does this for brands.

No kindlife-specific SDK, Postman collection or public GitHub repository was found. EasyEcom's public knowledge base contains no kindlife article, and Unicommerce's integrations directory does not list it.

Authentication

CS-Cart uses HTTP basic authentication. The username is an administrator's email address and the password is an auto-generated API key from that administrator's profile in the back office. There is no OAuth, no token exchange and no refresh step: the key is static until regenerated.

1. A kindlife administrator opens the user profile in the CS-Cart admin panel and generates an API key.
2. That email and key are given to the integrator.
3. Every request carries them as basic auth credentials.
4. Rotation means regenerating the key in the admin panel, which invalidates the old one immediately.

CS-Cart documents three equivalent ways to present the credentials. With curl:

curl --user 'admin@example.com:APIKEY' \
  'https://www.kindlife.in/api/2.0/products?items_per_page=1'

Or as an explicit header, with the email:APIkey pair base64-encoded:

GET /api/2.0/orders HTTP/1.1
Host: www.kindlife.in
Authorization: Basic YWRtaW5AZXhhbXBsZS5jb206QVBJS0VZ
Accept: application/json

CS-Cart offers two API versions. Version 1.0 is addressed as /api/:object, version 2.0 as /api/2.0/:object, and the documentation recommends 2.0. Both accept GET, POST, PUT and DELETE, and both accept and return JSON. Where mod_rewrite is unavailable the fallback form is /api.php?_d=:object&ajax_custom=1.

Multi-account handling does not really arise: there is one kindlife store, so one set of credentials. If kindlife runs CS-Cart Multi-Vendor rather than the single-store edition, a vendors resource exists and a vendor-scoped account becomes possible, which would be the clean way for kindlife to grant a brand limited access. Whether they run Multi-Vendor could not be determined from outside.

Objects we can read

CS-Cart's API documents more than 25 entity types, including products, categories, orders, users, payments, shipments, vendors, stores and languages. Responses are JSON objects keyed by object id, with a field array as the value, plus a search query section.

Because every call returned 401, no real kindlife response can be shown, and none will be invented here. The mapping below is based on CS-Cart's documented entity set rather than on observed kindlife data. Sample responses not published, and not obtainable without credentials.

Orders

GET /api/2.0/orders and GET /api/2.0/orders/:id. CS-Cart orders carry the order id, status code, timestamps, totals, the customer, and the product lines. Status in CS-Cart is a single-character code that stores redefine freely, so kindlife's status codes must be read from their admin configuration and cannot be assumed.

Order items

Carried inline on the order object rather than as a separate resource.

Products and listings

GET /api/2.0/products, paginated with items_per_page and page. CS-Cart products carry price, list price, amount in stock, status, category assignments and features. kindlife's category filters run off CS-Cart "features", which is where attributes such as skin concern and ingredient live.

Inventory

CS-Cart holds stock as an amount field on the product rather than as a separate inventory resource, so inventory reads and writes go through the product object.

Shipments and tracking

GET /api/2.0/shipments. CS-Cart shipments carry a carrier and a tracking number and link back to the order.

Returns and cancellations

CS-Cart's returns feature is RMA, and kindlife's account area exposes "RMA requests" to shoppers, so the feature is enabled. Whether RMA is exposed through the REST API in this installation was not verifiable.

Payments and settlements

GET /api/2.0/payments returns payment methods, not settlements. There is no settlement or payout entity in CS-Cart's core API. Brand payouts would be a commercial statement from kindlife, not an API object.

Customers

GET /api/2.0/users. This is full shopper PII: names, emails, phone numbers and addresses for kindlife's entire customer base, not just orders touching one brand. This is the strongest argument against kindlife handing an unscoped admin key to any outside party, and the strongest reason to ask for a scoped export instead.

Locations

GET /api/2.0/stores covers storefronts. Physical try-and-buy counters are unlikely to be modelled as CS-Cart locations.

Writing back: listings, price and stock

CS-Cart supports POST /api/2.0/products to create and PUT /api/2.0/products/:id to update, which covers price, list price, stock amount and active status. So the platform can do it.

Whether a brand ever gets to is a different question, and the answer is probably no. Given the direct-sourcing model and the enquiry-form onboarding, assume kindlife's merchandising team controls listing content, price and stock, and that a brand's influence is the trading terms and the assets it supplies. There is no bulk upload template documented publicly; CS-Cart's own admin has CSV import, but that is a back-office feature, not a brand-facing one.

Webhooks and notifications

CS-Cart's core REST API has no outbound webhook or event subscription system. There is nothing to subscribe to.

If credentials are granted, poll. A fifteen minute poll of orders filtered on a recent update window, plus a nightly full product sync, fits comfortably within any reasonable limit for a store of this size. If credentials are not granted, there is nothing to poll and the fallback is a scheduled export negotiated with kindlife.

Rate limits and pagination

CS-Cart's documentation does not publish rate limits, and no quota headers are documented. Pagination is by items_per_page and page, confirmed present on this installation by the 401 response to ?items_per_page=1. Since the API runs on the same web servers as the storefront, be conservative regardless of the absence of a published limit: serialise requests, keep page sizes moderate, and run full syncs off-peak.

Mapping to the unified model

Based on CS-Cart's documented entities, not on observed kindlife responses.

Gaps and open questions

• Whether kindlife runs CS-Cart Multi-Vendor or the single-store edition. This decides whether a vendor-scoped account is even possible, and it is the first thing to establish.
• Whether kindlife's relationship with brands is purchase-order buying or marketplace listing. The direct-sourcing claim points to buying, but nothing is published.
• What /brand-query, branded "kindlife connect", actually offers once signed in. It is behind authentication and could not be read.
• kindlife's CS-Cart order status code mapping, which is store-defined and meaningless without their configuration.
• Whether the RMA entity is exposed through this installation's REST API.
• Whether kindlife would ever issue credentials to a brand, given that an unscoped CS-Cart admin key exposes the entire customer table.
• Commission or margin terms, settlement cycle and who sets the shopper price. None is published.

Sources

• kindlife storefront, read in full for the footer, category structure, city list, claims and the Partner Brand link, and showing the CS-Cart dispatch= controllers and features_hash filters: kindlife.in
• kindlife.in/api/ and kindlife.in/api/products?items_per_page=1, both returning {"message":"Unauthorized","status":401} as JSON on 2026-09-21, confirming the CS-Cart REST API is enabled
• kindlife brand enquiry page, behind sign-in and branded "kindlife connect": kindlife.in/brand-query
• CS-Cart REST API developer guide, for the base URL forms, basic auth with admin email and API key, entity list, JSON format and HTTP methods: docs.cs-cart.com
• EasyEcom knowledge base, all 328 published articles enumerated on 2026-09-21: no kindlife article exists. Unicommerce's integrations directory does not list kindlife either