Guides

Product API

The Product API is used to synchronize your business’s product master data with Wapping. This ensures products are properly categorized and that the platform’s full functionality—such as applying benefits to different product sets—is available.

📘

While not strictly mandatory (since Wapping will create products received via the Checkout API), it is highly recommended to synchronize through the Product API to unlock all platform features.


The Product API Reference can be consulted to view information in detail for each method and object.

The Product API Swagger is also accessible in the endpoint, to interact directly with the API.


Before Integration
The first step is to align your current product dimensions with Wapping’s structure. This is typically done in a briefing session where Wapping reviews your dimensions and provides a report on how to map them to the platform. This process is usually quick but may take longer for complex cases.

Ongoing Synchronization
Configure product uploads to run periodically to maintain accurate segmentation and functionality.

Synchronize Product Dimensions
Dimensions such as Section, Category, Campaign, Brand, and Provider must be mapped based on the agreed translation from Step 1. Only relevant dimensions should be included.

Maintain Dimension IDs
When sending product data, include the corresponding dimension IDs from Wapping. It’s recommended to store these ID relationships in your system.

Synchronize Products
Use the Product controller with the Create and Update methods to add or modify products on the platform, depending on whether they already exist.


As shown, the minimal JSON request to create a product is just the name, description and code.

{
  "name": "test0101",
  "description": "test0101",
  "code": "test0101"
}

But, in practice, the "minimal" request should include all the product categorization that applies (those being the ones in the proposed traslation by Wapping):

properties
productCategoryId
productCampaignId
productBuyerId
productSectionId
brandId
productTypeId

The variant information is highly recommended, more information can be found here

The Tags are a special dimension, as they allow to define multiple values to a single product.
This is often used to allow having a categorization that is not structured, e.g. "sport" and "casual", or in a food retail example "high-protein" and "vegan"


{
  "name": "string",
  "description": "string",
  "code": "string",
  "productCategoryId": 0,
  "isVariant": true,
  "productParentId": 0,
  "productVariantOption1Id": 0,
  "productVariantOption2Id": 0,
  "productVariantOption3Id": 0,
  "productCampaignId": 0,
  "productBuyerId": 0,
  "productSectionId": 0,
  "productTagsId": [
    0
  ],
  "brandId": 0,
  "productTypeId": 0
}

📘

Note that the request object only accepts Wapping IDs, therefore is mandatory to create all the categorizations first. It's also highly recommended to mantain a translation table between the business codes and Wapping IDs, as retrieving them from the API each time would be a bad practice.

The complete recipe can be found here: