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
   ├── Flags and flag groups
   ├── Parametric groups
   ├── Parametrics and their list values
   ├── Variant groups
   ├── Relation types
   ├── File 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.

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.

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.

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