Metadata Integrations using the Management API

Product metadata — flags, parametrics, categories, price lists, variant groups, relation types, file types — is the structural foundation that product data imports depend on. When metadata is missing, imports fail or produce incorrect results.

Traditionally, metadata was configured manually in the Norce Admin UI before any integration ran. The Management API makes it possible to manage this metadata programmatically, which enables a new integration pattern: let your integration create and maintain the metadata it needs, as the source data requires it.

API Reference: Management API
Guide: Calling the Management API

When to use this pattern

Managing metadata from an integration makes sense when:

• Your source system (ERP, PIM, or supplier catalog) defines its own classification structures, and you want to mirror them in Norce without manual setup
• New flags, parametric values, or categories arrive in product imports and need to exist in Norce before the product import runs
• You operate multiple environments (dev, staging, production) and want configuration to be repeatable and scriptable, not manually recreated
• You manage many clients or applications and need to keep metadata structures in sync

It does not make sense when metadata is small, stable, and set up once — in that case, manual Admin UI configuration is simpler.

The integration order matters

Metadata must exist before products that reference it are imported. A product import referencing a flag code or a parametric that does not exist in Norce will either fail or silently drop that field.

The correct order for a full integration run is:

1. Metadata (Management API)
   ├── Manufacturers
   ├── Suppliers
   ├── Flags and flag groups
   ├── Parametric groups
   ├── Parametrics and their list values
   ├── Variant groups
   ├── Relation types
   ├── File types
   ├── Product types
   └── Categories

2. Price lists (Connect ImportPriceLists or Management API)

3. Product data (Connect ImportProducts)

4. Prices (Connect ImportSkuPriceLists)

5. On-hand (Connect ImportOnHands)

In practice, steps 1 and 2 only need to run when something has actually changed in the source system's structure. Steps 3–5 run on the regular import schedule.

Metadata types and their API endpoints

Manufacturers

Manufacturers are referenced by ManufacturerCode in product imports. If the code does not exist in Norce, the import will fail to link the manufacturer correctly.

Integration pattern: Before importing products, fetch the list of manufacturers from Norce and compare against the manufacturers in your source data. Create any that are missing.

Suppliers

Suppliers represent the external parties whose products, prices, and stock are imported via the Connect Supplier Service (SupplierProducts). A supplier must exist in Norce before supplier product data referencing it can be imported.

POST /supplier's commonly used fields:

{
  "Name": "Acme Tools",
  "Code": "acme-tools",
  "CurrencyCode": "EUR",
  "AutoMapManufacturers": true,
  "AutoCreateManufacturers": false,
  "IsChosenSupplierEnabled": true
}

• CurrencyCode: The currency the supplier's prices and penalty charges are expressed in.
• AutoMapManufacturers / AutoCreateManufacturers: There is no separate "map supplier to manufacturer" endpoint — these two booleans on the supplier entity control how manufacturers on incoming supplier product imports are matched. AutoMapManufacturers maps incoming manufacturers to existing ones in the client catalog by matching code; AutoCreateManufacturers creates new manufacturers that don't yet exist. Set these when creating or updating the supplier.
• IsChosenSupplierEnabled: Not the same as picking a "preferred" supplier directly — this only makes the supplier eligible to be considered by Norce's chosen-supplier algorithm, which selects the best supplier per product (by cost, penalty charges, etc.) elsewhere in the system. See Supplier Solution Design and Supplier Business Rules for how that selection logic works.

Creating or updating a warehouse under a supplier:

{
  "Name": "Main Warehouse",
  "IsStandard": true,
  "IsActive": true,
  "StandardLeadTimeDayCount": 3
}

IsStandard marks the default warehouse for the supplier — only one warehouse per supplier can have it set.

Product flags and flag groups

Flags are boolean attributes used for business logic segmentation — things like "is this a clearance item?" or "is this a hazardous product?". They are distinct from Norce's built-in product lifecycle statuses (Active, Coming, Expiring, etc.).

Use flags for statuses that belong to your business domain and should not map to Norce's own lifecycle. Do not create a flag to replicate what a Norce status already represents.

Integration pattern: If your ERP or PIM sends product data with custom status codes that don't map to Norce's statuses, model them as flags. Your integration checks whether the flag exists (by code) before the product import runs, and creates it if not.

Parametric groups and parametrics

Parametrics are structured product attributes — size, color, material, technical specifications. They are organized into groups. A parametric can be of type text, number, list (single select), or multiple (multi select).

For list and multiple type parametrics, the allowed values must also be managed.

Integration pattern: When your source system sends a product attribute that should become a parametric in Norce, your integration:

1. Checks whether the parametric exists (by code or name)
2. Creates it if not, assigned to the correct group
3. For list/multiple types, fetches the current list of values and adds any new ones

Parametrics vs. built-in fields: Not everything should be a parametric. Fields that feed Norce's shipping logic — ActualWeight, IsDangerousGoods, LogisticWidth, LogisticHeight, LogisticDepth — are built-in SKU/variant fields and should be mapped there, not as parametrics. See Working with the X-Stormconnect-Header for the correct field mappings.

Assigning a parametric group to a category: There is no dedicated "add group to category" endpoint. Grouping is a field, not a relationship — set the GroupId property on each CategoryParametricModel entry in the PUT /management/1.0/api/category/{categoryId}/parametric payload (see Categories below) to an existing parametric group's Id, obtained from GET /management/1.0/api/parametricgroup. Because that PUT fully replaces the category's parametric list on every call, GroupId must be included explicitly every time — if omitted, it comes back null instead of falling back to the parametric's own default group.

Product types

Product types (ErpStandard, ManagedStructure, Service, etc. — see Product types reference) are fixed, built-in classifications rather than metadata you define. There is no create endpoint — only listing and updating (e.g. localized names).

Categories

Categories provide the navigation and filtering structure for the product catalog. Every product must have a primary category for it to be correctly configured in Norce.

POST /category's recommended fields are Name, Code, ParentId, SortOrder, IsActive:

{
  "Name": "Outdoor",
  "Code": "outdoor",
  "ParentId": null,
  "SortOrder": 1,
  "IsActive": true
}

Norce supports multiple top-level categories per client — omit ParentId (or set it to null) to create a root-level category. Set ParentId to an existing category's Id to place the new category as its child.

Integration pattern: If your source system has its own category tree, mirror it in Norce before importing products. Use the category code field (not the Norce internal id) as the stable identifier your integration tracks.

Price lists

Price lists can be created and configured through both the Connect API (ImportPriceLists) and the Management API. Use the Management API when you need fine-grained control over pricing rules and population rules.

Integration pattern: If your ERP creates new customer-specific or campaign price lists dynamically, your integration creates the price list structure via Management API first, then populates it with prices via ImportSkuPriceLists in Connect.

Variant groups

Variant groups define the variant structure for products — for example, a product that comes in different sizes and colors has a variant group defining those dimensions.

Integration pattern: If your source system has its own variant structure, map it to Norce variant groups. Create the groups before importing products that reference them. The variant group must exist before a product can be assigned to it.

Relation types

Relation types define how products relate to each other — cross-sell, upsell, accessories, spare parts, etc. Custom relation types can be created for domain-specific relationships.

File types

File types categorize files and images associated with products — product images, data sheets, certificates, etc.

Verifying metadata before importing

A robust integration verifies that metadata is in place before running a product import, rather than assuming it exists. A simple pattern:

1. Fetch the current list of the metadata type from the Management API
2. Compare against what your source data requires
3. Create anything missing
4. Proceed with the product import

This check can run at the start of every import cycle, or only when the source system signals that its structure has changed — depending on how often your metadata evolves.

Further reading

• Management API reference
• Calling the Management API
• Products and pricing integrations
• Working with the X-Stormconnect-Header
• System integration patterns