Storesome Taxonomy
| Version | Created / Updated by | Notes |
|---|---|---|
| 1.0 | Danail Deltchev | |
| 1.1 | Danail Deltchev | Addition for different Storesome accounts in the same Hemi - here |
The purpose of this page is to detail Storesome’s taxonomy structure and way of downloading it as well as connection to product content (listing) creation
API Docs: https://storesome-test-seller-api.azurewebsites.net/index.html
API Calls:
- GET /api/categories - for pulling down the whole category tree
- GET /api/categories/{id}/attributes for downloading all available and mandatory attributes against a category
- GET /api/categories/{id}/variants - for downloading all available and mandatory variant options against a category
Storesome employs a fairly straightforward category tree structure. We have multiple levels of categories and attributes and variants are assigned only to the utmost leaf category in a structure. Each category can hold multitude of attributes and/or variants which need to be taken in consideration when preparing data for the relevant marketplace hosted by Storesome. Both “attributes” and “variants” can be mandatory or optional. Especially for variants this means that even if we are listing a single product in a specific category IF that category holds a mandatory variant option we must validate this against our product and require this value to be provided
For downloading the models we want to pull down all categories via the relevant call and then download all needed attributes and variants against each category in our new structure to hold for further validations, mappings, exports etc.
Note: it seems the standard at the moment for category tree structure is tree levels but we should be ready for more than this or less in some main category branches
Get Categories - the call provides the whole structure including leaf categories for each master branch
Example:
[
{
"name": "Fashion",
"id": 119,
"subCategories": [
{
"name": "Women's Fashion",
"id": 120,
"subCategories": [
{
"name": "Dresses",
"id": 128,
"subCategories": null
},
{
"name": "Tops & Shirts",
"id": 161,
"subCategories": null
},
{
"name": "Jeans",
"id": 162,
"subCategories": null
},
{
"name": "Trousers",
"id": 163,
"subCategories": null
},
{
"name": "Coats & Jackets",
"id": 164,
"subCategories": null
},
{
"name": "Shorts",
"id": 165,
"subCategories": null
},
{
"name": "Skirts",
"id": 166,
"subCategories": null
},
{
"name": "Lingerie & Nightwear",
"id": 167,
"subCategories": null
},
{
"name": "Maternity Clothing",
"id": 168,
"subCategories": null
},
{
"name": "Jumpers & Cardigans",
"id": 169,
"subCategories": null
},
{
"name": "Suits & Tailoring",
"id": 170,
"subCategories": null
},
{
"name": "Hoodies & Sweats",
"id": 171,
"subCategories": null
},
{
"name": "Leggings",
"id": 172,
"subCategories": null
}
]
},
{
"name": "Women's Accessories",
"id": 121,
"subCategories": [
{
"name": "Belt Buckles",
"id": 173,
"subCategories": null
},
{
"name": "Belts",
"id": 175,
"subCategories": null
},
{
"name": "Hair Accessories",
"id": 176,
"subCategories": null
},
{
"name": "Handbag Accessories",
"id": 177,
"subCategories": null
},
{
"name": "Hats",
"id": 178,
"subCategories": null
},
{
"name": "ID & Document Holders",
"id": 179,
"subCategories": null
},
{
"name": "Keyrings",
"id": 180,
"subCategories": null
},
{
"name": "Gloves & Mittens",
"id": 189,
"subCategories": null
}
]
}
]
}
]Mapping - Don’t think there is anything specific to map - we need to store the “name” of each of the categories and its “id” so we can reference them and also pull down the attributes and variants. In Hemisphere we expect to see the “name” of a category
Get Attributes - The whole structure of attributes is based on a attributes with key/value pairings for the different available options
Example:
[
{
"id": 968,
"name": "Material",
"isMandatory": true,
"valueTypeId": 1,
"values": [
{
"key": "Polyester",
"value": "4182"
},
{
"key": "Mixed",
"value": "5065"
},
{
"key": "Lycra",
"value": "5066"
},
{
"key": "Cotton",
"value": "5067"
},
{
"key": "Viscose",
"value": "7532"
},
{
"key": "Leather",
"value": "7690"
}
]
},
{
"id": 1126,
"name": "Gender",
"isMandatory": true,
"valueTypeId": 1,
"values": [
{
"key": "Men's",
"value": "5060"
},
{
"key": "Women's",
"value": "5061"
},
{
"key": "Kid's",
"value": "5062"
},
{
"key": "Babies",
"value": "5063"
},
{
"key": "Unisex",
"value": "5064"
}
]
},
{
"id": 1127,
"name": "Wear",
"isMandatory": false,
"valueTypeId": 1,
"values": [
{
"key": "Other",
"value": "5051"
},
{
"key": "Official",
"value": "5052"
},
{
"key": "Casual",
"value": "5053"
},
{
"key": "Underwear",
"value": "5054"
},
{
"key": "Glasses",
"value": "5055"
},
{
"key": "Jewellery and watches",
"value": "5056"
},
{
"key": "Footwear",
"value": "5057"
},
{
"key": "Accessoiries",
"value": "5058"
},
{
"key": "Clothes",
"value": "5059"
},
{
"key": "Outwear",
"value": "7691"
},
{
"key": "Sportwear",
"value": "7692"
}
]
},
{
"id": 1128,
"name": "Fastening",
"isMandatory": false,
"valueTypeId": 1,
"values": [
{
"key": "Zip",
"value": "5068"
},
{
"key": "Lace",
"value": "5070"
},
{
"key": "Buttons",
"value": "5089"
}
]
}
]Mapping - the important things here are the names of each attribute ID, the “isMandatory” field which we should also track and the “valueTypeId” which should point to us if an attribute is an enumeration or free text. “valueTypeID” = 1 should be our indicator that the attribute is an enumeration, meaning we have to look and store its following values
Get Variants - same as Attributes just for the variation options
Example:
[
{
"id": 257,
"name": "Colour",
"isMandatory": false,
"valueTypeId": 1,
"values": [
{
"key": "White",
"value": "745"
},
{
"key": "Black",
"value": "744"
},
{
"key": "Blue",
"value": "743"
},
{
"key": "Grey",
"value": "742"
},
{
"key": "Pink",
"value": "741"
},
{
"key": "Red",
"value": "740"
},
{
"key": "Green",
"value": "2084"
},
{
"key": "Orange",
"value": "2083"
},
{
"key": "Yellow",
"value": "2082"
},
{
"key": "Multi-colour",
"value": "739"
}
]
},
{
"id": 289,
"name": "Size",
"isMandatory": false,
"valueTypeId": 1,
"values": [
{
"key": "XS",
"value": "1375"
},
{
"key": "S",
"value": "902"
},
{
"key": "M",
"value": "751"
},
{
"key": "L",
"value": "750"
},
{
"key": "XL",
"value": "749"
},
{
"key": "XXL",
"value": "748"
},
{
"key": "XXXL",
"value": "747"
},
{
"key": "One Size",
"value": "746"
},
{
"key": "S/M",
"value": "2107"
},
{
"key": "M/L",
"value": "2108"
},
{
"key": "L/XL",
"value": "2109"
},
{
"key": "Pack of two",
"value": "2085"
}
]
}
]Mapping - same as Attributes just for the variation options
Multiple different Storesome accounts in the same Hemi
What we need to achieve is the option for one seller in Hemi to be connected to more than one Storesome stores. This might happen because said seller is opening more than one websites (hosted on two Storesome accounts) or wants to sell on just two marketplaces that are powered by Storesome (same way this is possible with Mirakl)
We have 2 ways to tackle this
- Simplify and just download separate taxonomy for each Storesome account, separate it by the account ID not just by the distinct marketplace and only make sure that for listing create and update validations it works through the correct taxonomy based also on the account mapping
- Add a filed by which we can distinguish to which Storesome the account is linking. This shouldn't be much more complicated for execution BUT it allows us to download a taxonomy for a certain Storesome account only once in case we have more than one accounts connected to it (for ease I will use the case of Autofixa - where we have 1 store with 1 taxonomy but can connect multiple sellers with different Hemi accounts in the same Hemi Connect platform) This field is a simple enum that we can add to new values whenever Storesome communicate with us there are more stores opened (if any) and should be mandatory for the taxonomy cron to run. The listing validation goes the same way as in point 1 but it will have to pick this same value and not just the distinct MP to differentiate if there are multiple taxonomies
I prefer option 2 as it gives us more flexibility and less stress and storage (if we have 5 accounts for the same Storesome platform for example) but option 1 will work as well