Constructor’s product discovery platform requires a regularly updated product feed to serve timely and accurate results. Constructor’s machine learning and AI algorithms combine this feed with the behavioral data generated by your users to provide optimized, personalized results.

The feed only needs to include data that's relevant for powering the Constructor features you're using. This generally includes things like a product name, URL, image URL, description, keywords, and any other metadata you'd like shown in results (price, user ratings, etc). Frequently, products are part of a category hierarchy, which can also be sent.

There are three primary ways of integrating your feed with the Constructor platform:

1. By utilizing a connector for one of the various supported platforms
2. By sending a full or partial feed CSV via REST API or FTPS at regular intervals
3. By integrating with Constructor's REST API for item-by-item JSON updates

There are no defined requirements about the frequency of updates for either method - this is generally a function of how often your product catalog changes.

CSV feed - API or FTP

Constructor provides an API catalog or FTPS server endpoint to its customers to upload full or incremental feeds at arbitrary intervals. Many customers have existing integrations with third-party vendors that include regular feed uploads, and Constructor can easily integrate with these existing systems. This method is recommended if the catalog data does not change more rapidly than once per minute, and a platform connector cannot be utilized.

Both full and incremental (delta) feeds are fully supported. Constructor recommends sending a full sync daily with incremental delta or patch delta updates throughout the day to reflect inventory and other intraday changes. The frequency of the delta and patch delta updates are at the customer's discretion based on their business needs however sending updates more frequently than every 5 minutes is not recommended.

Constructor has a standard item (products) catalog CSV format which makes integration easy. If items are part of a catalog hierarchy, there is a standard item group (category) list format.

A full CSV feed update may consist of the following components:

• CSV feed format - items (products) - defined within an items.csv file
  Products shown as results on product listing pages (search, browse)
• CSV feed format - variations - optionally defined within a variations.csv file
  Not all product catalogs have variations. Variations refer to child items that can be shown as swatches of top level results on product listing pages
• CSV feed format - item groups (categories) - defined within an item_groups.csv file
  Hierarchy definition of groups for organizing products

An API or FTPS catalog integration using CSV as the data format is the recommended approach for product feed integration due to its simplicity, speed of setup and ease of debugging.

JSON data - REST API

Constructor also offers a full REST API to support additions, deletions, and changes to a product catalog in batches or one at a time. This can be useful if customers have existing API-driven systems and/or require complex logic that’s hard to support with a standard product feed.

However, this approach requires back-end coding on the part of the customer and is consequently more time-consuming to implement. Typically only 1,000 products (items) can be added or modified with a single request, so this approach may require implementing batching logic.

Comparing approaches

Based on extensive integration experience across many customers, Constructor recommends using one of its platform connectors to many popular e-commerce platforms, PIMs or CMSs.

If a connector cannot be utilized, it is recommended to start with an API or FTPS catalog integration via CSV files due to the simplicity and speed. There are a number of advantages to this approach:

• Customers often have existing feeds being sent to third parties, and there is little work involved in creating another one.
• The entire product catalog is sent in a single payload, which can make debugging catalog updates much simpler in comparison to multiple REST API requests.

An item-by-item REST API integration works well, and is recommended for advanced use cases, but is often slower to implement due to a number of complexities:

• Requests should be batched to avoid accidentally hammering Constructor’s servers, and batching logic can be difficult to implement correctly within existing systems.

• Retry logic should be implemented in the event of a network failure, and this can also be difficult to implement within existing systems.