Store groups and markets
Learn how selling context, market context, tax context, stock-location context, and staged product changes fit together.
Start here when a storefront or integration depends on where Enad sells, how it sells there, which tax and stock context applies, or whether product changes should be staged before promotion. Use reference pages for exact paths, request fields, response fields, enum values, status codes, and validation behavior.
The short model
A store group is the selling context for an experience. It answers what kind of selling motion is happening: direct-to-consumer, business-to-business, outlet, trade portal, or another commercial context.
A market is the local context where that selling motion applies. It answers where the experience runs and which local expectations shape it, such as country, language, currency, and market-specific configuration.
Most production flows need both. Store group keeps the selling mode clear. Market keeps the regional experience clear. Tax groups and warehouses then attach tax and stock-location behavior to that context.
Product drafts sit beside this model. They let trusted workflows stage product changes before the live product record changes and before market-facing publication or channel work depends on those changes.
Choose the right surface
| Job | Use | Why |
|---|---|---|
| Create or update a selling context | Store Groups reference | Store group operations own the store group record and the market relationships attached to that selling context. |
| Create or update a local market | Markets reference | Market operations own market records and market slugs. |
| Attach tax configuration to market context | Tax Groups reference | Tax groups own tax context and the markets attached to it. |
| Attach stock-location context to markets | Warehouses reference | Warehouses own stock-location records and the markets those locations can serve. |
| Stage product changes before publishing | Product Drafts reference | Product drafts own staged product changes and promotion into the live product record. |
| Change prices or stock for variants | Variants reference | Variant operations own price, stock, warehouse-stock, and shipping-attribute changes for exact purchasable versions. |
| Change account-specific price context | Customer groups and pricing | Customer-group pricing is a separate layer on top of store-group and market context. |
Contract facts to keep in mind
Use these facts to choose the right reference. Use operation pages for exact fields, limits, auth, status codes, and response shapes.
- Store group records require a selling type of
b2c,b2b,d2c, ord2b. Updating with amarketslist adds those market relationships; it does not remove omitted markets. - Removing a market from a store group is blocked when prices exist for that store-group and market pair.
- Market records carry
name,slug,locale,currency_code,active, and one or more ISO alpha-2 country codes. - A tax-group market relationship must provide one tax percentage for each country code in that market.
- Warehouse operations change the stock-location record, not variant stock quantities. Turning
available_onlinefrom true to false publishes an online-inventory revoke event. - Product drafts are one draft per product. Scheduling bulk create and bulk delete accept up to 100 jobs and return separate successful and failed collections.
MCP warehouse-control
MCP can preview and apply bounded warehouse-control work when an agent or operator needs a governed change flow for stock-location context. Use it for warehouse creation, metadata or address updates, deletion, market attachment, and market removal.
Warehouse create previews check existing warehouses for slug or name conflicts. Market remove previews reject missing membership, require explicit no-rollback acknowledgement, and mark the preview as destructive. Apply re-reads the preview assumptions, aborts when current evidence has drifted, writes through the matching warehouse endpoint, and records audit evidence.
Use Variants reference for variant stock quantities. Warehouse-control changes the warehouse record or its market coverage.
Events
Use Events after market-context or stock-context records change. The Event catalog covers market, store-group, tax-group, and inventory events, including online inventory revoke and market-inventory updates. Product Drafts do not have a dedicated event family; when promotion changes another record, use the event family for that record.
Use the Event catalog for exact event type strings, schema IDs, required fields, and payload fields. Use Events latest for delivery and retry behavior.
Where to go next
- Need the workspace and runtime model next? Read Teams, apps, and environments.
- Need the catalog model that changes by selling context? Read Products, variants, prices, and stock.
- Need account-specific pricing? Read Customer groups and pricing.
- Need exact REST contracts? Start with Reference.
- Working on search, autocomplete, or facets with this context in mind? Start with Search latest.