Understand SKU dimensions, model number and additional property rules
Learn how a SKU stores its default dimensions, what limits apply to the model number, and how additional properties are validated.
Each SKU stores its default dimensions as three separate numeric fields - height, width, depth - all optional; these are the catalogue-level defaults the design tool starts from when the item is placed. The model number (model_no) is limited to 100 characters; updates over that limit are rejected with SKU_MODEL_NUMBER_TOO_LONG, which is worth checking when a bulk edit or ERP sync fails on specific rows. Additional properties are free-form key/value pairs stored per SKU (sent as a JSON array of {key, value} objects); the only server-side rule is that a property key may not be empty - such rows fail with KEY_FOR_ADDITIONAL_PROPERTIES_CONNOT_BE_EMPTY (note the misspelled 'CONNOT' in the actual error string, so search logs for that exact text). There is no uniqueness or type validation on property keys or values, so duplicated keys or inconsistent value formats across SKUs are possible and are a data-hygiene matter for the client, not a platform error. Name is mandatory; description and display order are optional. Renaming a SKU or changing its model number also updates the catalogue search index in the background, so search may lag a rename by a short time.
The new dimensions become the SKU's catalogue-level defaults.
The additional properties are free-form key/value properties on the SKU.
✓ 2026년 10월 10일에 제품에서 확인됨The additional properties can be edited without type or uniqueness restrictions.
✓ 2026년 10월 10일에 제품에서 확인됨A simple size change does not require the SKU-structure editor: height, width and depth are edited as the SKU's own properties, and the structure editor is reserved for changes to the structure itself.