Overview

when working with our json api, it’s important to structure your http requests correctly to ensure successful execution here’s a brief overview to guide you authentication to authenticate your requests, certain headers must be included please refer to the authentication documentation for detailed instructions on the required headers and authentication process request body the request body should be a json object tailored to the specific api operation you intend to execute refer to the url and http method type (get, put patch, etc ) as specified in the swagger/openapi specification docid\ w5ivv5q4jjbffywxds5p8 response a successful request will return an http 200 status code for information on other possible status codes and their corresponding response messages, consult the swagger/openapi specification docid\ w5ivv5q4jjbffywxds5p8 limits all apis generally have a request size limit of 2mb in case of for additional validations or specific limits for certain apis, refer to the swagger/openapi specification docid\ w5ivv5q4jjbffywxds5p8 record structure in klevu, each item needs to be indexed, i e if you have a complex product, like a shirt, available in different sizes and colors, then you should index the parent product “shirt” and all the variants available as a different item in klevu following are some of the key properties of the item to understand how to structure a product “ id ” field each item should have the unique “id” each item being submitted in the request should have the id defined in the whole catalog even for complex products, ensure that parent products and variants have unique ids in the full catalog e g i cannot have a parent product with id “1” and variants with id “1”, “2” and “3” here parent and variant have a conflict at id “1” same way, i cannot have a cms page with id “1” if there exists an item with id “1” the “type” field represents the type of item for catalog items, “ klevu product “ is used for other types, please refer to itemtype from swagger/openapi specification docid\ w5ivv5q4jjbffywxds5p8 the “ attributes ” field represents all the attributes of the item the basic attributes that you will include in the product are “name”, “url”, and “price” there are other standard attributes available that can be used and defined in the swagger/openapi specification docid\ w5ivv5q4jjbffywxds5p8 “ name ” you might notice that text fields like name, and description have defined values as { "default" "product 1" } fields with text value have been defined in the above format using "default" it will help us to expand the definition for other use cases in the future for the time being, all text values have to follow the pattern as you see in the example “ url ” url is critical for the item being indexed and that is used to redirect the end user on your site to the relevant page it should typically have a value of the pdp page for the product, a category page for the category, etc for different variants in the complex product, if your platform supports variant specific urls, then it is recommended to use the variant flavor of url, else you can also give a common parent product url for all the variants “ price “ prices are mandatory for the products being indexed this is a list of different prices and “type” defines the use of the price “currency” needs to be defined for each price, even if the store is using a single currency, it needs to be defined for each price of the product if you are indexing multi currency prices, then ensure that you give value for each currency for each product “saleprice” is the mandatory type to be defined for each currency for each product this is the price after all applicable discounts and will be displayed in the rendered product “defaultprice” is the original price, if defined, can be used to show a strikethrough while rendering the products the “ relations ” field represents the relation of the item with other items in your catalog we can map a parent and child product in a complex product or map products in categories using relations you will see this in action in one of the examples docid 4nx4iaiq1ea1vwzymf7xl the “ channels ” field is used to represent alternative values of the properties for different channels or groups e g we use it for defining a different price for a customer group on my site refer to the example customer groups docid 2fu3ql4jhm2bvvjsgxsjb to understand how to use this in detail example request