Start by sending garment measurements from each catalog item to the fit widget on its product page. Unlike a chat or review script, a fit API needs product-specific construction data to compare with the shopper's 3D body model from phone photos. That measurement layer accounts for most integration work, so map it before implementation begins.
This guide covers our Shopify app, WooCommerce plugin, and REST API, plus decisions about garment data and widget placement that influence recommendation adoption. It is for developers and technical product managers responsible for a storefront integration.
Three ways to integrate
We offer a Shopify app, WooCommerce plugin, and direct REST API for custom storefronts. Choose based on your commerce platform, not your level of technical skill.
The Shopify app is usually the quickest route to launch. Install it through the Shopify App Store. It reads garment measurements from Shopify product metafields, so those fields must follow our schema. Data held in default Shopify fields or spreadsheet imports needs migration first. For catalogs under a few hundred SKUs, this takes a few hours. Larger catalogs usually need a script. The app manages authentication, widget display, and fit sessions without custom code.
The WooCommerce plugin follows the same pattern. It reads measurements from product custom fields and displays the widget when shoppers choose a size. Variable products are supported. Measurement matching and recommendation logic run server-side, so the storefront does not calculate them.
Use the REST API for custom or headless storefronts, or when fitting the experience into a proprietary frontend component. Send a shopper's 3D body model identifier with garment measurements, then receive a structured recommendation. Your frontend can display that result within its own design system. This provides the most control, with the least prebuilt scaffolding.
Garment measurements are the main work
In most fit API projects, the difficult part is the data rather than the code. Recommendations need garment construction measurements, not only a size label and price. At minimum, provide chest at the widest point, point-to-point shoulder width, waist at the intended sit point, and hip circumference. Some categories also require sleeve length, back length, inseam, and thigh circumference.
Most brands already store these measurements somewhere, often in production fit specifications. The integration question is whether they connect to product records. Fit specs commonly sit in a PLM system, shared spreadsheet, or unlinked PDF archive instead of Shopify or WooCommerce. Moving them into the catalog is often the longest step when measurement data has not been structured.
Begin with categories that have the most complex fit and highest returns instead of importing the entire catalog. A 50-SKU pilot in a fitted-woven category is easier to prepare and validate than a 500-SKU import, and it reveals the return signal sooner.
Authentication and sessions
The API uses bearer tokens. Find your API key in the dashboard; it is scoped to your brand account. Send it in a backend request header, never in frontend JavaScript, to keep the key out of client-side code.
The Shopify app and WooCommerce plugin manage sessions for you. A fit recommendation stays linked to the shopper's session, so someone who has already submitted body measurements need not repeat the flow on later visits. Session duration can be configured, with a 30-day default that suits many brands. With a custom API, you must persist the shopper's 3D body model identifier across pages and attach it to each recommendation request.
Place the widget on the product page
Widget location on the product detail page strongly affects adoption after recommendation quality. Show the result when the shopper chooses a size. In most layouts, that means directly below or beside the size selector.
We have tried several placements. A "Find your fit" or "Get a size recommendation" button that opens a modal works well. It preserves page space and makes the action clear. An inline recommendation below the size selector, visible immediately, can improve completion by removing a click, but it needs more room and may not fit an existing product-page layout.
A widget below add to cart often performs poorly because the size decision has already happened. It adds page length without changing the choice. If the recommendation cannot sit near the size selector, delay integration until the product-page component can be reorganized.
Test before launch and track results
Before showing the widget to everyone, run an A/B test on a small share of traffic. The no-widget control establishes the period's return baseline. The widget group shows whether shoppers use recommendations and whether returns move as expected.
Track widget trigger rate, completion of the body measurement flow, recommendation acceptance through add to cart, and size-related returns for the purchase cohort. Returns need 60-90 days to mature, so begin testing early if the data must inform a budget decision.
Pilot onboarding issues we see often
Measurement gaps are common. A brand may begin integration and find that its records do not map cleanly to our schema, extending launch while the data is cleaned. Audit first: take 10 SKUs from the priority category and confirm that existing records provide chest, shoulder, waist, and hip measurements in inches or centimeters. If a script can handle 10, it can handle 500.
PDP placement is the other recurring issue. A brand may put the widget below the fold or add to cart, see weak completion, and blame the recommendation. Often the recommendation is fine and the location is not. Review completion before judging fit quality. Below 15%, placement is usually the first correction.
We provide technical integration support to pilot partners. For platform or catalog questions, begin with the integration page or our contact form.
