Working with the X-Stormconnect-Header

Every asynchronous import to Norce Commerce Connect requires an X-Stormconnect-Header HTTP header. This header tells Norce exactly which fields your payload contains and should be written — fields you do not declare are ignored and left unchanged in Norce.

This design is what makes it safe to have multiple systems writing to the same product catalog without overwriting each other's data.

The core concept

The header is a JSON object serialized as a single-line string in the HTTP header. You do not send a list of things to overwrite — you declare which fields are present in your payload. Norce treats everything else as "not my concern."

X-Stormconnect-Header: {"AccountId":12,"FullFile":false,"ProductFieldsThatAreSet":[0,1,6],...}

This has two important consequences:

1. You only update what you send. If your ERP owns prices and your PIM owns descriptions, neither system will clobber the other's data as long as each declares only its own fields.
2. Omitting a field is not the same as sending null. A null value in the payload for a field not declared in the header is completely ignored. A null for a field that is declared will write null.

Required fields in every header

FullFile is a destructive operation. Set it to true only on scheduled full imports, never on delta updates. See System integration patterns for when to use each.

Field array dependencies

Some *FieldsThatAreSet arrays only take effect if a parent array enables them. Forgetting the parent is one of the most common mistakes.

For product imports:

ProductFieldsThatAreSet
  └── [4] Variants          → enables VariantFieldsThatAreSet
        └── [4] Cultures    → enables VariantCultureFieldsThatAreSet
        └── [5] Skus        → enables SkuFieldsThatAreSet
              └── [20] StandardPrice → enables SkuPriceListFieldsThatAreSet
  └── [5] Cultures          → enables ProductCultureFieldsThatAreSet

If you include SkuFieldsThatAreSet but forget [5] Skus in VariantFieldsThatAreSet (and [4] Variants in ProductFieldsThatAreSet), your SKU fields will be silently ignored.

Practical scenarios

Scenario 1: ERP product sync (products + prices + on-hand)

The most common full product import from an ERP. The ERP owns status, logistics fields, and the standard price list.

{
  "AccountId": 12,
  "FullFile": false,
  "SerializationType": 0,
  "ProductFieldsThatAreSet": [0, 1, 4, 5, 6],
  "ProductCultureFieldsThatAreSet": [0],
  "VariantFieldsThatAreSet": [0, 3, 4, 5, 14, 18, 19],
  "VariantCultureFieldsThatAreSet": [],
  "SkuFieldsThatAreSet": [1, 2, 7, 8, 14, 16, 18, 19, 20, 21],
  "SkuCultureFieldsThatAreSet": [0],
  "SkuPriceListFieldsThatAreSet": [3, 5, 10],
  "IgnoreSkuPriceListFieldsWhenEmpty": [3]
}

What this does:

• Updates manufacturer, name, variants, cultures, and categories on the product
• Updates ManufacturerPartNo, IsDangerousGoods, logistics dimensions (LogisticWidth, LogisticHeight, LogisticDepth), and ActualWeight on variants
• Updates status, type, logistics, and the standard price list on SKUs
• Uses IgnoreSkuPriceListFieldsWhenEmpty on PriceSale so SKUs without a price in this import don't get their price zeroed out

Key fields explained:

• [3] IsDangerousGoods and [14] ActualWeight in VariantFieldsThatAreSet — these feed Norce's shipping logic. Import them as part of the product import, not as parametrics.
• [22] StatusCreateOnly in SkuFieldsThatAreSet — use this instead of [1] Status if you only want to set status when the product is first created and let it be managed in Norce after that.

Scenario 2: Price-only update

Your pricing system sends price list updates independently from the product catalog, multiple times per day.

Use ImportSkuPriceLists with a SkuPriceListHeader:

{
  "AccountId": 15,
  "FullFile": false,
  "SerializationType": 0,
  "SkuPriceListFieldsThatAreSet": [3, 6, 10],
  "IgnoreSkuPriceListFieldsWhenEmpty": [3]
}

What this does:

• Updates PriceSale, PriceRecommended, and IsActive on price list entries
• Ignores SKUs where PriceSale is missing in the payload (prevents accidental zeroing)
• Does not touch any product fields — this import cannot create or deactivate products

Use "FullFile": true only on a complete price list replacement (e.g., a campaign going live). For delta price updates, always use false.

Scenario 3: On-hand only update

Your WMS pushes stock levels frequently — potentially several times per hour. This should be an aggregated import in a scheduled manner to Connect.

Use ImportOnHands with a SkuOnhandHeader:

{
  "AccountId": 18,
  "FullFile": false,
  "SerializationType": 0,
  "SkuOnhandFieldsThatAreSet": [3, 4, 5]
}

What this does:

• Updates OnhandValue, IncomingValue, and NextDeliveryDate only
• Never deactivates products or changes any product data

Setting OnhandValue to 0 is not the same as deactivating a warehouse location. Use [10] IsActive to deactivate a product at a warehouse, for example when it is no longer stocked there.

Aggregation is your responsibility. If your WMS emits a stream of individual stock change events, your integration must collect and aggregate them over a time window — typically 15 to 60 minutes — and send the net result as a single batch. Do not forward each WMS event directly to Norce as it arrives. Norce has a significant processing overhead per import job, so a high volume of small imports will cause the queue to grow faster than it can be processed, increasing lead times for all imports — including products and prices.

Scenario 4: Content enrichment from a separate PIM or DAM

A content system owns product descriptions, images, and SEO fields. It must not overwrite the ERP's manufacturer or logistics data.

{
  "AccountId": 20,
  "FullFile": false,
  "SerializationType": 0,
  "ProductFieldsThatAreSet": [5, 7, 8],
  "ProductCultureFieldsThatAreSet": [0, 2, 3, 4, 5, 8, 9, 10, 11, 13]
}

What this does:

• Updates product cultures (name, descriptions, SEO fields) and images
• Does not touch manufacturer, categories, variants, SKUs, or prices
• Because AccountId is different from the ERP account, NameLimitedUpdate (code 12) can be used on the ERP side to prevent the content system's name from being overwritten by ERP imports

Scenario 5: Create-only fields

A common pattern when multiple systems write to the same entity: set a field only on creation, then let it be managed manually in Norce.

For example, set status to Coming when a product is first imported, but don't update it on subsequent imports:

"SkuFieldsThatAreSet": [22]

[22] StatusCreateOnly writes Status only if the SKU does not yet exist. On updates, it is ignored. The same CreateOnly pattern exists for names, descriptions, and other fields across all header types.

Multi-source imports

When different systems write to the same product, use a different AccountId for each. This enables:

• Traceability — the Admin UI shows which account last modified each import job
• LimitedUpdate fields — some fields (e.g. [12] NameLimitedUpdate in ProductCultureFieldsThatAreSet) only apply an update if this account was the last to write that field, preventing systems from overwriting each other

Keep one system account per integration service and do not share account IDs between unrelated imports.

Common mistakes

Further reading

• Header specifications by import type:
  • ProductHeader
  • SkuPriceListHeader
  • SkuOnhandHeader
  • SupplierProductHeader
  • CustomerHeader
  • PriceListHeader
  • RelationHeader
• Calling Norce Commerce Connect
• System integration patterns
• Products and pricing integrations