If you’re building a sizing feature, a wearable onboarding flow, or a health dashboard, you eventually hit the same question: how do you get body measurement data without asking users to take photos?
Photo-based measurement works — under controlled conditions. But it brings two structural problems that are increasingly hard to ignore in 2026: GDPR compliance exposure and user drop-off.
This guide explains the statistical alternative, what accuracy to expect, and how to integrate it in a few minutes.
The problem with photo-based measurement
Photo-based body measurement (3DLOOK, Bodygram, Fit3D) reconstructs dimensions from images using computer vision. The technology is impressive, but the architecture creates friction at two points.
User friction. Taking two full-body photos in specific poses, with adequate lighting, on a camera, is a multi-step UX requirement. In e-commerce, fitness apps, or health onboarding flows, users abandon this process at a significant rate — especially on mobile, in shared spaces, or when the person is self-conscious.
GDPR exposure. A photograph of a person is biometric data under GDPR Article 9 — special category data that reveals physical characteristics through specific technical processing. This requires:
- An explicit legal basis beyond standard consent
- A Data Processing Agreement with any processor that stores the images
- Technical safeguards beyond standard security
- In some member states: supervisory authority notification
This is manageable, but it adds compliance overhead that many small teams underestimate.
The statistical alternative
Instead of extracting measurements from photos, DimensionsPot predicts them from simpler inputs using Ridge Regression models trained on validated anthropometric datasets (ANSUR II, NHANES, CDC/WHO).
The key properties:
- Fully stateless — the API accepts only numerical measurements. No names, emails, photos, or user IDs. Data is processed in-memory and discarded. Nothing is stored.
- 130 ISO 7250-1 dimensions — skeletal landmarks, soft-tissue measurements, body composition indicators, defined using ISO 7250-1 anatomical methodology with standard codes where assigned.
- One POST request — no SDK, no image upload pipeline, no GPU infrastructure.
- Confidence Score on every output — a reliability index [0–100] so you know how much to trust each prediction.
The tradeoff is accuracy. Statistical prediction from height and weight is less accurate than photogrammetry from well-taken photos. For made-to-measure haute couture, photogrammetry wins. For fit recommendations, avatar scaling, or ergonomic presets — where you need “close enough” at scale — statistical prediction is the better fit.
Getting started
Subscribe to the free tier on RapidAPI (100 requests/month, no credit card). Your API key is in the dashboard under Apps → My Apps → Security.
Your first call — Python
import requests
url = "https://dimensionspot-bodysize-engine.p.rapidapi.com/v1/predict"
payload = {
"input_data": {
"input_unit_system": "metric",
"subject": {
"gender": "female",
"exact_age": 28.0,
"input_origin_region": "EUROPE"
},
"anchors": {
"body_height": 1650,
"body_mass": 62.0
}
},
"output_settings": {
"calculation": {
"calculation_model": "AUTO",
"target_region": "EUROPE",
"body_build_type": "CIVILIAN"
},
"requested_dimensions": {"bundle": "FULL_BODY"},
"output_format": {
"unit_system": "metric",
"include_range_95": True,
"include_iso_codes": True
}
}
}
headers = {
"X-RapidAPI-Key": "YOUR_API_KEY",
"X-RapidAPI-Host": "dimensionspot-bodysize-engine.p.rapidapi.com",
"Content-Type": "application/json"
}
response = requests.post(url, json=payload, headers=headers)
data = response.json()
# Access a specific dimension
chest = data["body_dimensions"]["chest_circumference"]
print(f"Chest: {chest['value']}mm | Confidence: {chest['confidence_score']} | 95% PI: {chest['range_95']}")
Unit note:
body_heightis in millimeters, not centimeters. 165cm → 1650mm.
Your first call — cURL
curl -X POST "https://dimensionspot-bodysize-engine.p.rapidapi.com/v1/predict" \
-H "X-RapidAPI-Key: YOUR_API_KEY" \
-H "X-RapidAPI-Host: dimensionspot-bodysize-engine.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{
"input_data": {
"input_unit_system": "metric",
"subject": { "gender": "female", "exact_age": 28.0 },
"anchors": { "body_height": 1650, "body_mass": 62.0 }
},
"output_settings": {
"calculation": { "target_region": "EUROPE" },
"requested_dimensions": { "bundle": "FULL_BODY" },
"output_format": { "include_range_95": true }
}
}'
Understanding the response
Each dimension in body_dimensions looks like this:
"chest_circumference": {
"value": 893.2,
"unit": "mm",
"type": "FLESH",
"confidence_score": 78,
"range_95": [841.5, 945.0],
"iso_code": "4.2.1",
"biological_limit_status": "OK"
}
type tells you whether this is a skeletal (BONE) or soft-tissue (FLESH) prediction. BONE predictions (clavicle length, shoulder breadth, limb segments) are more accurate than FLESH predictions (waist, hip, chest circumferences).
confidence_score is the reliability index. For height + weight input, BONE scores cluster around 85, FLESH around 78. If the score drops below 70, treat that dimension as a rough estimate.
range_95 is the 95% prediction interval — the actual statistical bound. Enabled with include_range_95: true.
Improving accuracy
The single biggest accuracy lever is adding one circumference measurement:
"anchors": {
"body_height": 1650,
"body_mass": 62.0,
"waist_circumference_omphalion": 720.0 # user knows this from jeans size
}
This unlocks the PRIMARY_RICH tier: BONE confidence rises to ~87, FLESH to ~80. The improvement is most visible in waist, hip, and bust predictions — exactly the dimensions that matter most for sizing.
Users in a fashion e-commerce context often know their waist measurement from existing clothing. It’s a natural question in an onboarding flow and costs nothing in privacy terms — it’s just a number.
Use case: fashion e-commerce sizing
Example scenario: A fashion platform wants to recommend sizes without asking for photos.
The flow:
- User enters height, weight, and optionally one circumference during onboarding.
- App calls DimensionsPot, receives
chest_circumference,waist_circumference_omphalion,hip_circumference. - App maps these to the brand’s size chart to recommend a size.
- App stores the mapping result, not the raw biometric numbers.
The last point matters: the API is stateless, so the only data your infrastructure sees is what you choose to store downstream. If you store only the recommended size label (not the numerical measurements), you have zero biometric data in your system.
Use case: HealthTech onboarding
Example scenario: A wellness app needs body composition indicators at sign-up for personalized program recommendations.
The flow:
- User answers 3 questions: sex, age, height, weight.
- App calls DimensionsPot with
calculation_model: "AUTO"— for users under 20, the pediatric engine runs automatically. - App receives BMI-adjusted circumference estimates and skeletal dimensions.
- App uses these for personalization logic, never persists the raw numbers.
For HIPAA-covered entities, the stateless architecture reduces the scope of Protected Health Information handling. Any link between a body profile and a specific individual exists exclusively in your own infrastructure — and only if you create it.
Conclusion
Statistical prediction from height and weight is not a replacement for photogrammetry in every scenario. But for the large class of use cases where you need approximate body dimensions at scale, without storing biometric data, it is a structurally simpler and more privacy-friendly approach.
The API is free to try — 100 requests on the free tier, no credit card. The Playground on RapidAPI has pre-filled examples ready to execute.
All API outputs are statistical predictions, not medical or professional advice. The Confidence Score is a proprietary heuristic index, not a statistical confidence interval.