Introduction

For a product to be recognized it must be setup in the product catalogue.

A product catalogue is a single, continuously updated source of information on all of the products that may be available for sale across all stores.

It is essential to create a product catalogue that contains the products you wish to recognize with the Tiliter API. This article will guide you through the process of creating a product catalogue in preparation to map products to Tiliter archetypes, which is described in the next section.

A simplified example of a product catalogue is as follows:

Retailer Product ID	Product name used in store
834437	Large Banana
930655	Loose Limes
567001	Portobello mushrooms
129554	Red Bell Pepper
290123	Opal Apple
645433	Yello Apple

Prerequisites

Before you start, make sure you have a list of products you want to recognize

The list of products should be exported from your internal database of all sold products. Depending on the arrangement of the organisation, this could be simple, or it could prove to be challenging.

The next step can be made easier by distilling down the export to just the relevant items that are sold without barcodes. For instance, if the export contains flowers and baked goods with packaging, they may clutter the list and make the next step more difficult.

Creating Products

Creating a product involves registering it with the Tiliter Recognition API. This process creates a virtual product with essential information like the product name, ID, and other retailer-specific details.

Here's a sample API call to create a product using a Unix-like command-line interface:

curl --request POST --url https://recognition.services.tiliter.com/products/PRODUCT1 --header 'accept: application/json' --header 'content-type: application/json' --header 'tiliter-api-key: YOUR_API_KEY' --data ' { "department": "fresh_produce", "recognition_enabled": true, "product_id": "PRODUCT1", "product_name": "Red Apple" } '

The expected response to this is:

{ "recognition_enabled": true, "product_id": "PRODUCT1", "product_name": "Red Apple", "product_description": null, "lookup_code": null, "department": "fresh_produce", "required_attributes": [], "optional_attributes": [], "sale_method": null }

Product Parameters

Each product can have other special parameters, as follows:

API field	Data type	Description	Example values	Required
product_id	string	A unique identifier for the product.	PRODUCT1, 123, 1234, 12345	Mandatory
product_name	string	The name of the product.	Red Apple, Royal Gala Apple, Apple - Royal Gala, Banana, Banana - Cavendish	Mandatory
product_description	string	A brief description of the product.	A juicy red apple	Optional
recogniton_enabled	boolean	If true (default), this product will be recognised. Set to false to have the product ignored.	true, false	Optional
lookup_code	string	An alternative to the product ID field. Can correspond to a PLU (product lookup code) or UPC (universal product code).	123, 4174	Optional
department	string	The department the product is sold in.	fresh_produce, bulk_goods	Mandatory
required_attributes	array of strings	Use this field to specify essential attributes always present on a Retailer Product. For instance, if peanuts must be in a brown paper bag and cannot be sold loose, set the brown bag attribute as required. The Tiliter Recognition API will only return peanuts if a brown bag is detected.	in_brown_bag, specialty_label	Optional
optional_attributes	array of strings	Use this field to specify optional attributes that may be present on a Retailer Product. For instance, if bananas may be organic or not organic, set the specialty label as an optional attribute. That way, the Tiliter Recognition API will know that bananas can be sold in both ways and provide responses accordingly.	in_brown_bag, specialty_label	Optional
sale_method	n/a	Parent group. Cannot have any value.	n/a	This group of properties is optional. However, if you use any of them, all must be defined.
currency	string	ISO4127 code representing the Sale Currency	USD, AUD, NZD, EUR	Mandatory if any of the other Sale method properties are defined.
unit_price	number	Price with up to two decimal places.	1.05, 1.9, 10, 12.50, 99.99	Mandatory if any of the other Sale method properties are defined.
weight_unit	string	For products sold by weight, this field defines the measurement units used	kg, g, lb, oz.	Mutually exclusive with Quantity unit. One of these two is mandatory if any of the other Sale method properties are defined
quantity_unit	string	For products sold by quantity this must be set to the fixed value of ea.	ea	Mutually exclusive with Weight unit. One of these two is mandatory if any of the other Sale method properties are defined.
tare	number	Tare with up to three decimal places.	0.003, 0.005, 0.01	Mutually exclusive with Quantity unit. Mandatory if Weight unit is defined.

More information on the product parameters can be found in Create Product.

Products can be created, updated, and deleted, and can also be retrieved in a list, and retrieved individually using the API functions provided. In addition, a list of all issues with products can be retrieved.

Products in the catalogue need to be linked to a Tiliter Archetype before they can be recognised. This process is known as mapping, and is described in Product Mapping.

Ongoing Product Management

New products are introduced all the time, such as when a new variety of apple is created. When each new product is introduced into any store, new products will need to be created and setup just like existing products were.

The process is exactly the same from a technical perspective. It is recommended to establish practices and processes that ensure that product creation within the Tiliter Recognition API is part of the standard checklist of work required to introduce a new product into any store.

Conclusion

The Recognition API can only recognize products that are in the product catalogue (and mapped to a Tiliter Archetype and in stock). Creating and managing products is required to use the Recognition API. Good management of products will result in the best outcomes, performance, and accurate and useful usage and performance statistics. For more information, see Products.