Api Operation Logic in Data Extraction Mode (Output)
This GET request also makes use of the “time” and “last_update” parameters, which accept a value in UNIX format.
The combination of these two parameters will allow extracting the information between last_update and time.
The following graphic shows a simple example of the results of API requests depending on the events that occurred in the account:
A data response logic is maintained based on the time parameters sent.
It is possible to obtain all the items that go through the connector, regardless of modifications, by specifying a time equal to 0.
Any change in the connector configuration, as well as in the parameters, will trigger a full synchronization.
Our SDK, based on LAMP technology, also allows the creation of local data repositories through the Updater SDK service. This will facilitate the synchronization of PIM data with a database.
Download the (PHP Based) Sales Layer SDK here.
Export parametrization
Export connectors allow the parameterization of the API output behavior based on the status of the items in the different tables of the Sales Layer PIM.
Like the vast majority of Sales Layer connectors, it is possible to select the different locations enabled in the client account to extract the translation values of the fields that have been configured as multi-language.
It is possible to configure different combinations of statuses to be taken into account in the export of records from the API: All, Visible, Visible + Draft, etc.
It is also possible to configure the export of categories, even if they do not have related products, using the “Include empty categories” parameter.
It is also possible to filter the content of each table using tags, formulas, search filters, etc.
Table hierarchy
The Categories, Products, and Variants tables share a hierarchical relationship among them; any change that occurs in one can affect the others.
This behavior will apply as long as the tables are active within the connector.
In the following graphic, you can see the order in the table hierarchy, excluding possible Custom Entity tables.
For example, a status change in a category that has associated products will generate either a modification (M) or a deletion (D) output for those products, even if no direct change has been made to them. Similarly, if each of those products has associated variants, the API will also send change information for the associated variants.
The combinations follow an algorithm based on different factors that ensure correct use in external synchronization processes such as online stores, web catalogs, etc.
The combination of the API request parameters parents_category_tree, first_parent_level, and same_parent_variants will allow altering the behavior of the information sent by the API during extraction processes (in the synchronization phases) to adapt it to the different requirements of external applications.
