FAQ
Frequently Asked Questions
Common questions about the DimensionsPot API — what it is, how to integrate it, and how it handles accuracy, regions, and data. Can't find what you're looking for? support@dimensionspot.com
What is DimensionsPot?
What does this API do?
DimensionsPot is a stateless body measurement prediction API. You supply a few basic inputs — height, weight, gender — and receive a complete anthropometric profile: 130+ ISO-standard body dimensions, confidence scores, and 95% prediction intervals. No photos, no biometric data, no stored records of any kind.
Dimensions are defined using ISO 7250-1 anatomical methodology — the international standard for human body measurements — with standard codes included where the ISO specification assigns them. Predictions are generated by peer-reviewed statistical models (Ridge Regression for adults, LMS Box-Cox for children), not by a neural network or AI black box.
Dimensions are defined using ISO 7250-1 anatomical methodology — the international standard for human body measurements — with standard codes included where the ISO specification assigns them. Predictions are generated by peer-reviewed statistical models (Ridge Regression for adults, LMS Box-Cox for children), not by a neural network or AI black box.
What can I build with it?
The API covers any product or service that needs to understand human body shape without collecting photos or biometric data:
Size recommendations — fashion, apparel, footwear, headwear, sporting goods, PPE
Avatar customization — gaming, VR/AR, metaverse, virtual fitting rooms
Ergonomic design — workstation calculators, wearable device sizing, furniture
Childrenswear — infant through teen, CDC/WHO calibrated growth standards
Health & fitness — body composition estimates, population percentile context
Workforce management — bulk PPE and uniform sizing from HR data
Size recommendations — fashion, apparel, footwear, headwear, sporting goods, PPE
Avatar customization — gaming, VR/AR, metaverse, virtual fitting rooms
Ergonomic design — workstation calculators, wearable device sizing, furniture
Childrenswear — infant through teen, CDC/WHO calibrated growth standards
Health & fitness — body composition estimates, population percentile context
Workforce management — bulk PPE and uniform sizing from HR data
How is this different from photo-based sizing APIs?
Photo-based APIs require users to upload two full-body photographs under specific lighting and pose conditions. Those photos are biometric data under GDPR Article 9 — a special category requiring explicit legal consent, data processing agreements, and strict retention controls. They also require significant infrastructure: photo upload, CDN, storage, image moderation, and a pose-validation layer.
DimensionsPot requires two numbers: height and weight. The input never becomes biometric data. There is no photo pipeline to build or maintain, and no GDPR Article 9 exposure. See the Privacy by Architecture comparison on the homepage.
DimensionsPot requires two numbers: height and weight. The input never becomes biometric data. There is no photo pipeline to build or maintain, and no GDPR Article 9 exposure. See the Privacy by Architecture comparison on the homepage.
Is the API really stateless?
Yes — in a structural, not policy, sense. Every request is processed in isolation. No session IDs are issued, no user profiles are created, and no input data is logged or retained after the response is sent. Your height and weight values exist only in memory during the milliseconds of computation. There is no personal data stored on our end that could be breached, subpoenaed, or subject to a GDPR erasure request.
Who is this for?
Primarily developers and product teams integrating body data into an application. The API is designed to be integrated in hours, not weeks — a standard HTTPS POST with JSON, no SDK required. CTOs evaluating build vs. buy for sizing infrastructure, and e-commerce product managers looking to reduce return rates without adding a photo-upload flow, are the typical decision-makers.
Getting Started
How do I get an API key?
Subscribe to DimensionsPot on RapidAPI — the free tier requires no credit card. Your API key is available in the RapidAPI dashboard under Apps → My Apps → Security. Every request requires two headers:
X-RapidAPI-Key and X-RapidAPI-Host.What is the minimum payload to get a response?
For adult subjects, gender plus one anchor measurement is the minimum. All
output_settings fields have defaults and can be omitted. The simplest valid request is: {"input_data": {"subject": {"gender": "male"}, "anchors": {"body_height": 1780}}}. This returns all 130 FULL_BODY dimensions in metric with 95% intervals and ISO codes where defined. See the Quick Start guide for copy-paste examples.What units should I use?
All lengths and circumferences must be in millimetres (mm), and body_mass in kilograms (kg). The most common mistake is sending
body_height in centimetres — the API expects 1780 for 178 cm, not 178. If your values are in inches and lbs, set input_unit_system to "imperial" and conversion is applied before validation.What is the free tier?
100 API requests per month with no credit card required. Paid plans start at $79/month for 2,000 requests and scale up to $799/month for 50,000 requests. All features — all dimensions, all bundles, pediatric engine, regional calibration — are available on every tier. Subscribe on RapidAPI.
Inputs & Anchors
What is an "anchor" measurement?
Any recognized body measurement key you supply in the
See the Data Dictionary for the complete list of valid anchor keys and the dimensions they can predict.
anchors object. The adult engine requires at least one anchor and accepts any number — accuracy improves with each additional anchor and plateaus after the PRIMARY_RICH tier (height + weight + one precision circumference). For the pediatric engine, anchors are optional — body_height and body_mass are outputs, derived from CDC LMS tables.See the Data Dictionary for the complete list of valid anchor keys and the dimensions they can predict.
Do I need height AND weight?
No. A single anchor is enough for the adult engine. With just height or just weight, you reach the PRIMARY_ONE tier: BONE dimensions score ~79, FLESH dimensions ~62. You can also supply a single secondary anchor like
foot_length or wrist_circumference and the engine imputes the primary anchors from it (SECONDARY tier, BONE ~74, FLESH ~67). Full-body accuracy requires both height and weight. See Anchor Strategy for the full tier breakdown.Can I supply more than two anchors?
Yes. Adding any one precision anchor (hip_circumference, waist_circumference_omphalion, chest_circumference, neck_circumference, or wrist_circumference) alongside height + weight elevates the tier from PRIMARY_BOTH to PRIMARY_RICH, increasing BONE scores from 85 to 87 and FLESH scores from 78 to 80. Details in the Anchor Strategy documentation.
What happens if a customer doesn't know their weight?
The engine can impute body_mass from secondary anchors using a dedicated Ridge model. The imputed value appears in the response header as
calculated_anchors. A confidence penalty of up to −10 points is applied proportional to imputation uncertainty. For band/ring sizing use cases where only height is available, this is often sufficient.Output & Accuracy
What does "confidence_score" mean?
It is a proprietary heuristic reliability index [0–100] that is deterministic — given the same set of anchor keys (not values), the score is always the same. It is never over-reported: actual 95-PI coverage on held-out ANSUR II data is always ≥ the reported score. The stated floor for PRIMARY_RICH BONE is 87%, for PRIMARY_RICH FLESH is 80%, validated against n=300 precision validation runs. See Confidence Score documentation for the full methodology.
What is range_95?
The [lower, upper] 95% prediction interval per dimension. For apparel sizing, use it for boundary handling: if the interval spans two size thresholds, surface both options. For safety equipment like helmets and harnesses, always use the upper bound to err toward the larger size. Enable it with
"include_range_95": true in output_settings.What is biological_limit_status?
A bounds check against NASA-STD-3001 absolute limits (adult) or age-banded CDC P1/P99 limits (pediatric). A value of OUT_OF_BOUNDS indicates a dimension falls outside the valid population range — typically when input anchors describe an extreme body type or when an anchor combination is biomechanically unusual. OUT_OF_BOUNDS does not suppress a dimension from the output; it is an informational flag.
How many dimensions are returned?
130 dimensions for a FULL_BODY request. Named bundles return subsets: HEAD_FACE (20), HAND_ARM (32), TORSO (29), LEGS_FEET (34). Some dimensions appear in two bundles (e.g., neck_circumference in both HEAD_FACE and TORSO). 19 dimensions are FULL_BODY-only. See the Bundle Reference for per-bundle dimension lists.
What is the response time?
Under 50 ms per request, typically under 10 ms on a warmed instance. P99 latency is 6–8 ms direct / 8–12 ms via RapidAPI gateway. A batch of 1,000 employee records runs in under 10 seconds at moderate concurrency.
Engines & Routing
When is the pediatric engine used?
The engine routes automatically: if
exact_age ≤ 20, the PEDIATRIC engine activates. If only age_category is provided, any pediatric value (INFANT, TODDLER, CHILD, PRE_TEEN, TEEN) triggers the pediatric engine. exact_age is always the authoritative signal and overrides age_category on conflict. Full details in the Pediatric Engine documentation.What is the pediatric engine?
LMS Box-Cox calibrated to CDC Clinical Growth Charts 2000 (218 age points), combined with the adult Ridge model. In pediatric mode,
body_height and body_mass are outputs derived from age + sex, not inputs. LMS-derived dimensions have confidence 99. All other ~127 dimensions are Ridge-derived and capped at confidence 80. See the Pediatric Engine documentation.Should I provide exact_age or age_category?
Provide
exact_age whenever possible — especially for pediatric subjects where growth rates are high. When only age_category is available, the engine uses the bracket median age for body-composition calculations, and adds a warning to header.meta_warnings. The median can be several years from the child's actual age.What is body_build_type?
A morphological modifier applied to soft-tissue dimensions. CIVILIAN = general population (NHANES baseline). ATHLETIC = removes the civilian fat-distribution shift, producing leaner circumference proportions — suitable for sports, military, and physical labour contexts. OVERWEIGHT = BMI-stratified NHANES morphing for higher body-fat distribution.
body_build_type has no effect in pediatric mode. See Code Examples for usage patterns.Regional Calibration
What is input_origin_region?
The population your customer's measurements come from. It normalises anchor values to the ANSUR II global baseline before inference, eliminating the "Double Penalty Paradox" — the systematic error that occurs when a model trained on a global baseline misinterprets a regionally shorter measurement as an overall smaller body. See the Regional Calibration documentation.
What is target_region?
The population your output should be calibrated toward. Use this when your size chart was built on measurements from a specific population — e.g., a European brand should set
target_region to EUROPE so output proportions match the proportional space the size labels were defined in. It is independent of input_origin_region. Full explanation in Regional Calibration.Which regions are supported?
Seven regions: GLOBAL (ANSUR II baseline), EUROPE, ASIA_PACIFIC, LATAM — all with full gender coverage. INDIA has a female body measurement fallback to ASIA_PACIFIC. AFRICA uses male-centric calibration with a −10% confidence penalty on FLESH dimensions. MIDDLE_EAST coefficients are validated for males 18–30 only. Known limitations are noted in
meta_warnings at runtime.What if I don't know my customer's region?
Use GLOBAL as the safe default for both
input_origin_region and target_region. It applies no regional normalisation and avoids the Double Penalty rather than risk applying the wrong regional correction. Response accuracy is lower than with correct regional settings, but no systematic error is introduced.Privacy & Data
Is any data stored?
No. The API is stateless — it processes each request in isolation and stores nothing. Height and weight are numerical inputs processed during the request and discarded immediately. No PII is required, accepted, or retained. There is no data on our end to breach, subpoena, or for which you would need to process a GDPR deletion request.
Is this GDPR-compliant?
The API processes only numerical body measurements with no names, IDs, or other identifying information. Your client application handles the identity layer and bears GDPR implementation responsibility for data collected from end users. The API's stateless architecture eliminates the most significant compliance risk — there is no personal data to breach on our end. Unlike photo-based APIs, no GDPR Article 9 (biometric data) legal basis is required.
Can I use this for medical purposes?
No. All API outputs are statistically derived anthropometric predictions intended to support — not replace — professional judgment. They do not constitute medical, clinical, ergonomic, or professional advice, and must not be used as the sole basis for health decisions, clinical assessments, or safety-critical specifications. The confidence score is a proprietary heuristic index, not a statistical confidence interval.
Still have questions?
support@dimensionspot.com