Data Format

Note: As the data format itself is 100% dependent on the data (“marketing”) model configured in inRiver, it is not possible to create a JSON-Schema or similar definition easily. For ease of understanding, instead a textual representation of the underlying modelling techniques is presented:

  • An Entity is exposed/imported as a JSON Object.
    {
    "ProductGender": ...,
    "ProductBrand": ...,
    "ProductSubBrand": ...,
    ...
    }

  • The attribute identified by typeId is used as attribute key

"ProductCode": "10003320"

  • For non-localized values, the data is exposed directly as string.

"ProductCode": "10003320"

  • For localized attributes, the different localizations are exposed/imported as object mapping language code (preferrably 2-character ISO code) to String value.
    In addition, a “virtual” language “$” is exposed as ‘best-matching locale’:

"ProductMaterialDescription": {
  "$": "Miss Delicate 10 WHUF",
  "ru": "Miss Delicate 10 WHUF",
  "es": "Miss Delicate 10 WHUF",
  "sv": "Miss Delicate 10 WHUF"
},

To reduce transfer size, the set of exposed locales may be limited. “$” is always exposed as the “best” match on the requested locales. This allows the middleware to rely on data being presented (with fallback) in this attribute.

When UPSERTing data, “$” is ignored. All other languages will be updated accordingly.

  • For CVLs, similar to localized texts, an Object is returned, containing the CVL Key (“#“), the default label (“$“) and, if localized, the additional locales.

"ProductSubBrand": {
  "#": "FA",
  "$": "Female",
  "de": "Frauen",
  "en": "Female"
},

Same as for localized texts, locales may be omitted.
For UPSERT operations, in typical cases only “#” is used to identify the matching CVL. If this ID is not present, “$” may be used to automatically search for a matching CVL based on this label – in any language.
If the CVL needs to be created (as not yet existing), the labels will be used as default.

  • Update mode:
    For specific use cases, it is desirable to ignore object uploads unless the unique key maps to an existing entity – for example, to amend existing data based on a different source system which may contain more products than uploaded to inRiver.
    For this case, a virtual attribute may be used:

"$mode":"updateOrIgnore"

If this is present, non-existing entities will not be auto-created.

Example:

...
"Materials": [
 {
 "MaterialSAPMaterialNo": "10120015",
 "$mode":"updateOrIgnore",
 "MaterialColors": [
   {
   "ColorId": "1000001500AS",
   "$mode":"updateOrIgnore",
   "ColorCountryOfOrigin": { "#": "Morocco", "en": "Morocco" }
  }, ...
 }
]

  • Relations will be exposed as JSON Attribute, where the attribute name corresponds to the relation’s ID. The value is an array of objects, representing the corresponding target entities.

"ProductItem": [
  {
  "ItemCode": "100033200003B080",
  "ItemGridId": "0003B080",
  "ItemEan": "7613111519830",
  "ItemMaterialComposition": "92% Baumwolle, 7% Elasthan, 1% Polyamid",
  "ItemSeason": {
    "#": "SS2002",
    "$": "SS2002"
  },
...

Note that in inRiver all relations are bi-directional – but only one name is provided! 

In Proxy: To reduce transfer size and to allow control on the nesting depth, all relevant relations need to be requested explicitly, refer to inlineRelations query parameter.
When UPSERTing data, nested elements are automatically created based on the target entity type as defined in inRiver. Same logic for unique identifier identification is applied. A link to parent entity is automatically created.
Relations are not deleted! In a future proxy release, this behaviour may be changed via additional query parameter deleteOrphanedChildEntities.