Skip to main content
Every product in Galactic Core sits under exactly one category and, optionally, a subcategory. The two levels look alike and behave very differently: a store’s categories are settled when the store is created and are not authored afterwards, while subcategories belong entirely to the merchant. That difference matters most at import time. A feed naming a category the store does not have has its row rejected rather than creating one, so an integration reads the store’s own category list and matches against it.

​
Categories are fixed for the life of a store

Categories are seeded when a store is created. A merchant does not create, rename or delete them — the one control they have is enabling and disabling, and every category starts enabled so a merchant switches off what they do not sell. Two consequences follow, and both are what an integration depends on. A category’s name and slug are stable. They never change under a store, which is what makes a slug safe to hard-code in a storefront route, and what lets a specification template, a set of starter subcategories and a storefront style all resolve against the same key. The API exposes categories read-only — there are no create, update or delete endpoints on /v1/categories — and a catalog feed never creates one. Most stores are created with the standard set below, and a store selling into a particular market may be created with a catalogue tailored to it instead. So read /v1/categories for the store you are integrating with and match against what it returns, rather than assuming the list on this page. The endpoint is a publishable-key read and returns each category’s id, name and slug. General exists as the catch-all for a product that fits no specific heading, and is the fallback an importer reaches for. Who decides a store’s catalogue, and what can be changed after a store exists, is covered in White-Label.

​
The standard categories

These are the categories a store is created with unless it was set up with a tailored catalogue. Copy the names exactly. The groupings below are for reading; they are not part of the data.

​
Subcategories are the merchant’s own

Below the category line, everything belongs to the merchant. Subcategories are created, renamed and deleted freely, and they nest to any depth — Apparel → Shoes → Men → Sneakers is a valid chain, as is a single flat level. A subcategory tree lives under one category, and the database holds that shape rather than trusting the caller: a subcategory’s parent must belong to the same store and the same category, and a cycle is refused. Deleting a parent promotes its children to the top level instead of deleting the subtree, so a mis-click removes one node rather than a branch. Deletion is reversible for 90 days. A deleted subcategory can be restored from the merchant’s admin within that window. Reading the tree is a single request. listSubcategories returns a flat list by default and the whole nested forest with tree: true; root_only returns just the top level, and parent_id returns one node’s direct children. A single subcategory can be fetched with its children, or with its ancestors — a breadcrumb that begins with the owning category, each entry tagged with which level it came from. Reference: TaxonomyService

​
How a feed is matched

The importer resolves a category by name, lowercased and trimmed. That is the whole comparison — there is no fuzzy or approximate matching, so Electronics, electronics and Electronics all resolve, while Electronic and Consumer Electronics do not. A name that does not resolve rejects that row with a message naming the value it could not place:
A category that exists but is switched off is re-enabled automatically rather than rejected — importing into a disabled category is taken as intent to sell from it again. Subcategories behave the opposite way, and deliberately so: an unrecognised subcategory is created, and a >-delimited path builds the whole chain, so Audio > Headphones > Wireless creates all three levels under the resolved category on first import.
A category can also be given as its id rather than its name, which skips name matching entirely. Feeds generated from another Galactic Core store can use ids; feeds assembled by hand are almost always better off with names.
Where a feed’s own category names do not match this list, the import screen’s assisted review can propose a correction — a misspelling is corrected outright, and a plausible but unlisted name is matched to the closest category and flagged for confirmation rather than applied silently. It resolves to a name from this list either way, which is why copying the names is the shorter path. Reference: Catalog ingestion · Catalog sync

​
Starter specification templates

Specifications are the structured attributes of a product — screen size, fabric, wattage, capacity — as opposed to its description. Every store is created with one specification template per category, so a merchant filling in a smartphone starts from fields that suit a smartphone. The templates are drawn from fifteen families, each covering the categories that share a shape: Each template is named for its family and its category — Electronics Spec — Smartphones — and carries that family’s fields. Fields whose units are ambiguous carry their own guidance: a dimensions field asks for width × height × depth including the unit, and a weight field asks for the unit explicitly, so two merchants filling the same field produce comparable values. A field takes one of sixteen types: text, number, select, multiselect, boolean, date, textarea, color, url, email, phone, dimensions, weight, currency, percentage and json. The templates are a starting point, not a constraint. A merchant edits the supplied fields, adds their own, and creates entirely new templates; nothing about the seeded set limits what a store can describe.
Specifications attach to a variant, not to a product. A product with three sizes has three places specifications can be recorded, which is what allows a per-size weight or dimension to differ. Where an attribute is genuinely the same across every variant, record it on each, or keep it in the product description.

​
Starter subcategories

A new store has its categories and no subcategories — the merchant builds their own, and a storefront that needs none works fine without any. For merchants who would rather start from something, a starter set of more than 900 suggested subcategories covers every category, some with a further level of nesting beneath them. They are loaded on request, one category at a time, and the merchant chooses which of the suggestions to take rather than accepting the whole set. Anything already present is skipped, so loading twice adds nothing the second time. General is deliberately given only a handful of suggestions. It is the fallback where uncertain imports land, and a fallback that arrives pre-filled with structure invites products to settle there instead of somewhere more useful.