WeChat & JD Mini Programs

WeChat Mini Programs and JD Mini Programs run in a sandboxed runtime that cannot load third-party scripts, so the standard Kleep JS widget does not apply. Two integration approaches exist instead: an API-based integration (recommended, detailed on this page) and a web-view embed of the Kleep drawer, which carries heavy platform constraints.

​

Integration options

​

Option A — API-based (recommended)

Your mini program renders the sizing UI natively (CTA, fit questionnaire, result screen) and drives it with calls to the Kleep REST API. You own the look & feel, nothing external loads inside the mini program, and the only platform requirement is allowlisting the Kleep API domain. The rest of this page details this approach.

​

Option B — web-view embed

In principle, the Kleep drawer (drawer.kleep.ai) — the same web experience our mobile SDKs wrap in a WebView — could be embedded through the mini-program web-view component. In practice, this path is blocked by platform constraints, which is why we do not support it today:

• Business domain + ICP filing. A WeChat web-view can only load domains declared as business domains (业务域名) in the MP console, and a domain is only eligible if it holds an ICP filing (ICP备案). drawer.kleep.ai is hosted outside mainland China and has no ICP filing; obtaining one requires a Chinese legal entity and mainland hosting.
• Per-retailer declaration. Even with an eligible domain, each retailer must declare it in their own console (verification file uploaded at the domain root, limited number of business domains per mini program), and web-view is restricted to business-verified accounts.
• Broken messaging bridge. The drawer communicates with its host through real-time postMessage events (add to cart, select size, mid/uid persistence). In a WeChat web-view, wx.miniProgram.postMessage only delivers messages on specific triggers (back navigation, component destruction, share) — not in real time. An add-to-cart tapped inside the drawer would not reach the mini program until the view closes.
• Performance. Serving an overseas-hosted page to visitors in mainland China is slow and unreliable, at the most conversion-critical moment of the journey.

JD Mini Programs enforce equivalent domain-allowlisting rules, so the same reasoning applies to both platforms. If a web-view-based integration is strategic for you, discuss it with your Kleep representative — it would require a China-hosted, ICP-filed deployment of the drawer plus a rework of the messaging bridge.

​

Architecture

The integration has two independent halves:

1. Runtime (mini program ↔ Kleep API). Your mini program calls the Kleep API over HTTPS — either directly from the client (wx.request / jd.request) or proxied through your backend. It checks product eligibility, submits the shopper’s fit profile, and retrieves the size recommendation.
2. Data (your systems → Kleep). Your product catalog, orders and returns reach Kleep through the standard data integration channels (SFTP or feed). This is what powers the recommendations — it is a prerequisite, not part of the mini program itself.

Key identifiers used throughout:

​

Prerequisites

1. Onboarding with Kleep — you receive your public_id and API credentials.
2. Catalog ingestion — your product data is flowing to Kleep (see Data Integration).
3. Domain allowlisting — add the Kleep API domain to your mini program’s authorized request domains:
   • WeChat: MP console → Development → Development settings → Server domain → request legal domains (request合法域名).
   • JD: the equivalent server-domain allowlist in the JD Mini Program console.
   All Kleep endpoints are HTTPS-only, which both platforms require.

​

Integration flow

​

1. Check product eligibility (PDP load)

When a product detail page mounts, call the eligibility endpoint with product_id (and mid if the shopper already has one). The response tells you:

• whether the product is recommendable — if not, hide the CTA entirely;
• the recommended size, if the shopper already has a measurement profile.

Render the CTA accordingly: “Find my size” when no profile exists, “Recommended size: M” when one does. Cache the result per (product_id, mid) for the session to keep PDP navigation free.

​

2. Collect the fit profile

When the shopper taps the CTA and has no profile yet, open your native fit-questionnaire screens. The questionnaire structure (questions, order, validation rules per category — clothing, footwear, lingerie, children) is specified in the API documentation shared at onboarding. Typical inputs: height, weight, age, fit preference. Submit the answers to the profile endpoint. Kleep returns a mid (measurement-profile ID) that identifies this shopper’s profile from now on.

​

3. Get the size recommendation

Call the recommendation endpoint with product_id + mid. The response contains the recommended size label (e.g. "M", "38") plus fit details to display on your result screen. Show the result natively, with your own add-to-cart or select-size action.

​

4. Persist the Kleep IDs

Mini programs have no cookies, so continuity relies on IDs you store:

• Save mid in local storage (wx.setStorageSync / JD equivalent) so returning shoppers skip the questionnaire and see their recommended size directly on PDPs (step 1).
• Pass customer_id on your API calls when the shopper is logged in — this links the profile to your CRM identity and enables cross-device continuity.

​

5. Hand off to cart natively

Size selection and add-to-cart stay entirely in your mini program — Kleep only returns the recommendation. Wire your result screen’s CTA to your existing cart logic.

​

API surface (overview)

Client-side calls are authenticated with your public_id. If any credential with broader scope (API key) is issued to you, keep it server-side — never ship it in the mini program bundle.

​

Tracking

To measure performance (usage, conversion, size-related returns), send the three standard journey events through the tracking endpoint. These are your store’s standard customer journey events, not Kleep-specific actions: Include product_id, variantId, cart contents and customer_id where applicable — same payloads as the JS library events.

​

Privacy & compliance

The fit flow processes personal data (body measurements). Collect the shopper’s consent as required by the regulations applicable to your market — for mini programs distributed in mainland China, that means PIPL: surface your privacy notice and obtain consent before submitting the fit profile to Kleep. No cookies are involved in this integration; all continuity is based on the IDs described above, under your control.

​

Support

Your Kleep representative provides the full API specification, test credentials and a sandbox public_id during onboarding. For anything unclear at integration time, contact support@kleep.ai.