Multi-Region Platform

Business Context

The Problem: Global expansion and cross-border sourcing fail on a single issue: population-level skeletal proportions. 170 cm and 70 kg in Tokyo produces measurably different chest, waist, and shoulder dimensions than the same anchors in Berlin. Whether you serve a global audience or source from Asian factories for European customers, you’re guessing your way through systematic population differences — and guessing is what keeps the return rate where it is.

The Solution: Fix it with one parameter: input_origin_region. The API interprets measurements in their correct proportional context and returns a complete, 130-point anthropometric profile in under 10ms. You see the actual physical dimensions the manufacturer intended, validate them against your target market, and get the ground truth before the bulk order goes out. No manual offset tables, no per-market code hacks.

The Strategic Edge: Use target_region to master cross-regional validation. Align predictions with your specific brand fit model, or compare the “Sourcing Delta” between two populations by calling the API twice with different regional settings. Which regional “M” fits your audience stops being a guess — it becomes a dimension-by-dimension comparison you can read in the response payload.

How the Regional Calibration Works

Customer provides height + weight (from their regional context)
        │
        ▼
Step A — input_origin_region: "ASIA_PACIFIC"
  → Normalises input anchors to population-neutral ANSUR baseline
  → Eliminates systematic under/over-prediction for non-baseline populations
        │
        ▼
Ridge Regression Inference (ANSUR global baseline)
        │
        ▼
Step B — target_region: "EUROPE"  [optional advanced use]
  → Calibrates output proportions to the target population's norms
        │
        ▼
Output: accurate body dimensions for this customer

Why Step A matters — the Double Penalty Paradox: Without input_origin_region, an Asian customer’s 162 cm height is interpreted by the ANSUR-trained model as “short person, smaller overall” — which underestimates every other dimension. The customer is penalised twice: once because the input anchor is regionally shorter for the same body type, and again because the model interprets that shorter anchor as a globally smaller frame. input_origin_region removes the first error before inference runs.

Regional Pairing Reference

Sample Request — Asian Customer, Accurate Dimensions

curl -X POST "https://dimensionspot-bodysize-engine.p.rapidapi.com/v1/predict" \
  -H "Content-Type: application/json" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: dimensionspot-bodysize-engine.p.rapidapi.com" \
  -d '{
    "input_data": {
      "input_unit_system": "metric",
      "subject": {
        "gender": "female",
        "exact_age": 31.0,
        "age_category": "ADULT",
        "input_origin_region": "ASIA_PACIFIC"
      },
      "anchors": {
        "body_height": 1620.0,
        "body_mass": 54.0
      }
    },
    "output_settings": {
      "calculation": {
        "calculation_model": "AUTO",
        "target_region": "ASIA_PACIFIC",
        "body_build_type": "CIVILIAN"
      },
      "requested_dimensions": {
        "bundle": "TORSO",
        "specific_dimensions": null
      },
      "output_format": {
        "unit_system": "metric",
        "confidence_score_threshold": 75,
        "include_range_95": true,
        "include_iso_codes": false
      }
    }
  }'

Sourcing Delta Pattern

Call the API twice for the same demographic with different target_region values. The difference shows where population proportions diverge.

def sourcing_delta(gender, age, height_mm, mass_kg, source_region, target_region, bundle="TORSO"):
    def build_request(region):
        return {
            "input_data": {
                "input_unit_system": "metric",
                "subject": {
                    "gender": gender,
                    "exact_age": float(age),
                    "age_category": "ADULT",
                    "input_origin_region": region
                },
                "anchors": {
                    "body_height": float(height_mm),
                    "body_mass": float(mass_kg)
                }
            },
            "output_settings": {
                "calculation": {
                    "calculation_model": "AUTO",
                    "target_region": region,
                    "body_build_type": "CIVILIAN"
                },
                "requested_dimensions": {"bundle": bundle},
                "output_format": {
                    "unit_system": "metric",
                    "confidence_score_threshold": 75,
                    "include_range_95": False,
                    "include_iso_codes": False
                }
            }
        }
    # → call API for build_request(source_region) and build_request(target_region)
    # delta[dim] = round(dims_target[dim]["value"] - dims_source[dim]["value"], 1)
    # positive = target population is larger for this dimension

Regional Coverage & Known Limitations

Multi-Tenant Platform Pattern

For a SaaS platform serving multiple retailers, derive input_origin_region from the customer’s locale and target_region from the merchant’s configuration:

LOCALE_TO_REGION = {
    "JP": "ASIA_PACIFIC", "KR": "ASIA_PACIFIC", "CN": "ASIA_PACIFIC",
    "TW": "ASIA_PACIFIC", "TH": "ASIA_PACIFIC", "VN": "ASIA_PACIFIC",
    "IN": "INDIA",
    "DE": "EUROPE", "FR": "EUROPE", "IT": "EUROPE", "ES": "EUROPE",
    "GB": "EUROPE", "NL": "EUROPE", "PL": "EUROPE", "SE": "EUROPE",
    "US": "GLOBAL", "CA": "GLOBAL", "AU": "GLOBAL",
    "BR": "LATAM",  "MX": "LATAM",  "CO": "LATAM",  "AR": "LATAM",
    "SA": "MIDDLE_EAST", "AE": "MIDDLE_EAST", "EG": "MIDDLE_EAST",
    "NG": "AFRICA", "ZA": "AFRICA", "KE": "AFRICA",
}

def get_prediction(customer_locale, merchant_config, gender, height_mm, mass_kg, age=None):
    input_region  = LOCALE_TO_REGION.get(customer_locale, "GLOBAL")
    target_region = merchant_config.get("size_chart_region", input_region)
    body_build    = merchant_config.get("body_build_type", "CIVILIAN")

    subject = {"gender": gender, "age_category": "ADULT", "input_origin_region": input_region}
    if age is not None:
        subject["exact_age"] = float(age)

    return {
        "input_data": {
            "input_unit_system": "metric",
            "subject": subject,
            "anchors": {"body_height": float(height_mm), "body_mass": float(mass_kg)}
        },
        "output_settings": {
            "calculation": {"calculation_model": "AUTO", "target_region": target_region, "body_build_type": body_build},
            "requested_dimensions": {"bundle": "TORSO"},
            "output_format": {"unit_system": "metric", "confidence_score_threshold": 75, "include_range_95": True, "include_iso_codes": False}
        }
    }

Response Handling Tips

• input_origin_region is the accuracy-critical field. When the customer’s region is unknown, GLOBAL is the safe default — it avoids the Double Penalty rather than risk applying the wrong regional correction.
• target_region changes the proportional calibration of the output. Store both input_origin_region and target_region alongside every saved dimensional profile.
• Check header.modifiers_applied in every response — it lists the exact calibration steps applied, including which regional coefficients were used.
• Check header.meta_warnings for regional fallback notices (e.g., India female fallback to ASIA_PACIFIC).
• When input_origin_region == target_region, both normalisation steps still apply — Step A normalises to the ANSUR baseline and Step B calibrates back to the same region. Do not omit either parameter.
• Response time is unaffected by cross-regional requests. The translation steps are coefficient lookups, not additional model calls. P99 latency remains 6–8 ms regardless of the regional combination.