SizeCharts

Fetch the singleton default country-comparison table used to render cross-country size mappings on the storefront. Note: the handler also returns 404 with `status: not_found` when no config has been created yet — clients should render an empty state. That path is not contract-tested because the endpoint has no input to discriminate "found" from "missing".

Fetch size chart data for a product using a 3-level fallback lookup: (1) product-level by item_code + gender, (2) fit-level by brand UID + category UID + fit_type + gender, (3) basic-level by brand UID + category UID. Either (item_code + gender) or (brand + category + gender) must be provided. Returns status "not_found" with data null when no chart exists at any level.

Returns up to three of the logged-in user's past purchases in this category, each paired with the equivalent size on the product currently being viewed, so the storefront can show "you bought M in brand X, which is L here". Unlike `/size-recommendation`, which stops at the first tier that produces an answer, this endpoint accumulates: each tier tops the list up towards three entries and the next tier runs only if room remains. - Tier 1, brand level: past orders of the same category and brand. On the garment measurement lane the order's fit must match `fit_type`; on the body measurement lane there is no fit check. These orders are their own recommendation, so `recommended_size` equals `size_name`. Matched orders are then excluded from the later tiers. - Tier 2, category level: remaining same-category orders, fit-agnostic on both lanes, matched to the current product's chart by pivot measurement. Orders that do not match are skipped and the loop continues. - Tier 3, cluster: orders from sibling categories, with an ease-factor adjustment on the garment lane. Orders with an unresolvable ease factor are skipped, and any failure drops this tier entirely. `recommended_size` at the top level is simply the first entry's recommended size, taken positionally rather than by any score, so `purchased_orders` is ordered most-relevant-first. As with `/size-recommendation`, having nothing to show is a normal outcome: HTTP 200 with `status` "success", `data` null and a machine-readable `reason`. Clients must branch on `data` being null rather than on `status`. Missing or malformed query params are reported the same way, so this endpoint never returns 400. Requires an authenticated caller, resolved from the `x-user-data` header injected by the API gateway, falling back to the `f.session` or `UserId` cookies. 401 is the only error status this endpoint returns.

Returns a single recommended size for the logged-in user for the product being viewed, derived from that user's own recent order history. The engine first resolves the measurement type configured for the category + brand + gender triple, which selects one of two lanes: - Body measurement lane: `fit_type` is never read. A past order of the same category and the same brand wins outright. Otherwise the pivot measurement of the most recent same-category order is matched against the current product's size chart. Once any same-category history exists this lane never falls back to the sibling-category cluster. - Garment measurement lane: a past same-category, same-brand order whose fit matches the requested `fit_type` wins. Otherwise the engine falls back to the same-category pivot match (fit-agnostic), and then to the sibling-category cluster with an ease-factor adjustment. Having no recommendation is a normal outcome, not an error. The response is still HTTP 200 with `status` "success", `data` null, and a machine-readable `reason`. Clients must branch on `data` being null rather than on `status`, and simply render no size hint in that case. This covers missing or malformed query params too (reasons `missing_params` and `invalid_gender`): the endpoint deliberately never returns 400, so a bad request cannot break the product page. Requires an authenticated caller. The user is resolved from the `x-user-data` header injected by the API gateway, falling back to the `f.session` or `UserId` cookies. 401 is the only error status this endpoint returns.