Attributes — GET /v1/products/{id}/attributes

Attributes

Structured, category-aware attributes normalised across sellers — with the source and confidence of each value, because a parsed number is not a declared one.

GET /v1/products/{id}/attributes

Request

Name	Type	Notes
min_confidence	float	Drop weakly-inferred values before using them as constraints.
axes_only	bool	Return only the attributes that vary between variants.

Request & response

GET /v1/products/prd_8Fk2xQ/attributes?min_confidence=0.8

→ 200
{ "category": "electronics.audio.headphones",
  "attributes": [
    { "key": "electronics.anc",           "value": true,
      "source": "declared", "confidence": 1.00 },
    { "key": "electronics.battery_hours", "value": 30, "unit": "h",
      "source": "parsed",   "confidence": 0.88 },
    { "key": "general.weight",            "value": 250, "unit": "g",
      "source": "declared", "confidence": 1.00 } ],
  "axes": ["colour"] }

Notes

Attributes are namespaced per category because the axes genuinely differ. Measured across nine industries the dominant ones were: apparel Size; home Colour and Size; jewellery Material, Stone and Length; beauty Scent and Size; electronics Device, Colour and Status. One flat schema cannot serve those.

`source` separates declared from parsed from inferred. A battery figure lifted out of a description is not the same fact as one from a structured spec field, and using them interchangeably is how confident nonsense enters a catalogue.

Tags are deliberately excluded. Real storefront tags in our sample included '50EmployeeDiscount', 'BFCM40' and 'DFS check' — internal operations leaking into a public field. They are a weak search signal and worthless for identity.