Platform API Endpoint: Retrieve Organisation Data

Before reading on please ensure that you have understood the following topics:

• Getting Started/Overview
• Personal Signing Up To SQUIZZ.com
• Registering An Organisation
• Organisational Data
• Organisation Settings
• Connecting Organisations
• Trading Tokens and Pricing
• Connecting Business Systems
• Integrate Software Into SQUIZZ.com
• Platform API

The endpoint allows different kinds of organisational data to be retrieved from another chosen organisation who had previously imported their data into the platform. The endpoint will return a list of records in a conforming Ecommerce Standards document that will be formatted in a JSON HTTP response. For example the endpoint could be called to get a list of products from a supplying organisation, or get a list of stock quantities for the products that a supplier organisation sells. See the list below of the kinds of data that can be retrieved.

Organisations who are supplying the data can control the kinds data that is available to other organisations through the use of "Data Sharing Policies". For example one organisation may not allow another organisation to retrieve stock quantities, but may allow the retrieving organisation to get product pricing data. Data sharing policies may also be used to restrict the kinds of products that another organisation may retrieve.

The endpoint allows a maximum of 5000 records to be retrieved in one request for all data types, except for Product Combinations where the limit is 500 records, and Maker Model Mappings the limit is 100,000 records. Where there are more than the maximum number of records to retrieve in a single request, the calling software can use the "records_start_index" and "records_max_amount" parameters to step through and download the a range of records across multiple requests.

Before using this endpoint we recommend that you understand what the Ecommerce Standards Documents are and how you can read data from the standards into your own business logic. Note that there are trading token costs to retrieve the organisation data using this API. These costs may be paid by the organisation supplying the data, or the organisation retrieving the data depending on the data sharing policy that the supplying organisation has set up. See Trading Tokens and Pricing for information on costs.

HTTP Request

HTTP Response

HTTP Response Example:

The Retrieve Organisation Data endpoint can be called by an organisation to retrieve a list of attribute data from another organisation connected to it on the SQUIZZ.com platform. The endpoint will return a list of attribute profiles, attributes and product attribute value records in the Attribute Ecommerce Standards Document (ESD) JSON data format that the receiving organisation has been given access to download, based on the Data Sharing Policy that the supplying organisation has assigned to the receiving organisation.

Within the retrieved Attribute JSON document, it is broken up into 2 parts. The first being a list of attribute profile records that each contain a list of attributes. Each attribute profile record conforms to the Attribute Profile ESD Record format, and then each attribute record conforms to the Attribute ESD Record format.

The second part of the Attribute JSON document contains a list of attribute values set against each product  Each product attribute value record is conforms to the Attribute Value ESD Record format. 

Attributes effectively allow an unlimited number of additional fields to be defined for products and models, with multiple product or model values being set for each attribute. Attributes are grouped into attribute profiles, allowing multiple attribute fields to be given a greater context of what they store or represent. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

HTTP Response Example:

Below is an example Attribute Document returned by the API endpoint.

Tips and Recommendations:

• If possible call the endpoint using the SQUIZZ.com API's native programming language libraries to cut down on the amount of development work needed to retrieve the product data. See API Native Programming Libraries.
• When the attribute document is being returned from the API, in each of the attribute profile or attribute value records, in any fields that had the default value set may be omitted from being included in the returned JSON. This cuts down on the amount of redundant JSON data that needs to be downloaded, speeding up retrieval times.
• Call the API endpoint to retrieve product data from a supplier organisation first, then use the product data in conjunction with the subsequent retrieved product attribute value data to gain additional information about each product assigned to the each attribute value record. Doing it this way avoids duplicate maker data being repeatedly downloaded with every model record, speeding up data retrieval times.
• Call the API endpoint to retrieve attributes data from a supplier organisation first, then use the attribute data in conjunction with the subsequent retrieved model data to gain additional information about each attribute and attribute profile the model attribute values are assigned to. This also avoids retrieving duplicate information about attributes and attribute profiles, speeding up data retrieval times.
• Note that there are trading token costs to call the endpoint. The supplying organisation may subsidise these costs, based on the data sharing policy assigned to the retrieving organisation. For more details on costs see Trading Tokens and Pricing for more details.

The Retrieve Organisation Data endpoint can be called by an organisation to retrieve a list of categories from another organisation connected to it on the SQUIZZ.com platform, as well as category trees that each category is assigned to, and products that are assigned to each category. The endpoint will return a list of category tree and category records in the Category Ecommerce Standards Document(ESD) JSON data format that the receiving organisation has been given access to download, based on the Data Sharing Policy that the supplying organisation has assigned to the receiving organisation.

Within the retrieved Category JSON document, each category record is conforms to the Category ESD Record format, and each category tree conforms to the Category Tree ESD Record format.

The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

HTTP Response Example:

Below is an example Category Document returned by the API endpoint.

Tips and Recommendations:

• If possible call the endpoint using the SQUIZZ.com API's native programming language libraries to cut down on the amount of development work needed to retrieve the category data. See API Native Programming Libraries.
• When the category document is being returned from the API, in each of the category records any fields that had the default value set may be omitted from being included in the returned JSON. This cuts down on the amount of redundant JSON data that needs to be downloaded, speeding up retrieval times.
• Within the returned category document's configs property, the dataFields property will provide a list of all the record properties that can be expected to have data set for each category record. Then if a model field was not included in a record returned from the endpoint, then it can be presumed that its value would have been the default indicated in the table above.
• If you are saving the retrieved category data to a database, use the list of category fields in the dataFields property to indicate which fields of existing category records in your database should be updated. This can be very useful to ensure that not all category fields are being overwritten in your database, allowing some category data to be updated from an external data source, and other category data be left alone.
• If you are saving the retrieved category tree data to a database, use the list of category tree fields in the dataFieldsCategoryTree property to indicate which fields of existing category tree records in your database should be updated. This can be very useful to ensure that not all category tree fields are being overwritten in your database, allowing some category tree data to be updated from an external data source, and other category tree data be left alone.
• Call the API endpoint to retrieve product data from a supplier organisation first, then use the product data in conjunction with the subsequent retrieved category data to gain additional information about each product assigned to the each category record. Doing it this way avoids duplicate product data being repeatedly downloaded with every category record, speeding up data retrieval times.
• Supplying Organisations may import up to 5 category trees and the associated categories for each tree. This allows many types of navigation to find products by (the equivalence of hosting/distributing multiple types of catalogues). If the category data is being retrieved and imported into a business/website system that only supports a single category tree structure, then choices may need to be made to only utilise categories belonging to a single nominated category tree. Alternatively multiple category trees could be retrieved then merged into a single category tree.
• The endpoint only allows active categories and active category trees to be retrieved. Any inactive category trees or categories will be excluded from being retrieved.
• Note that there are trading token costs to call the endpoint. The supplying organisation may subsidise these costs, based on the data sharing policy assigned to the retrieving organisation. For more details on costs see Trading Tokens and Pricing for more details.

The Retrieve Organisation Data endpoint can be called by an organisation to retrieve a list of makers from another organisation connected to it on the SQUIZZ.com platform. The endpoint will return a list of maker records in the Makers Ecommerce Standards Document(ESD) JSON data format that the receiving organisation has been given access to download, based on the Data Sharing Policy that the supplying organisation has assigned to the receiving organisation.

Within the retrieved Makers JSON document, each maker record is conforms to the Maker ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

HTTP Response Example:

Below is an example Maker Document returned by the API endpoint.

Tips and Recommendations:

• If possible call the endpoint using the SQUIZZ.com API's native programming language libraries to cut down on the amount of development work needed to retrieve the product data. See API Native Programming Libraries.
• When the makers document is being returned from the API, in each of the makers records any fields that had the default value set may be omitted from being included in the returned JSON. This cuts down on the amount of redundant JSON data that needs to be downloaded, speeding up retrieval times.
• Within the returned maker document's configs property, the dataFields property will provide a list of all the record properties that can be expected to have data set for each maker record. Then if a maker field was not included in a record returned from the endpoint, then it can be presumed that its value would have been the default indicated in the table above.
• If you are saving the retrieved maker data to a database, use the list of maker fields in the dataFields property to indicate which fields of existing maker records in your database should be updated. This can be very useful to ensure that not all maker fields are being overwritten in your database, allowing some maker data to be updated from an external data source, and other maker data be left alone.
• Note that there are trading token costs to call the endpoint. The supplying organisation may subsidise these costs, based on the data sharing policy assigned to the retrieving organisation. For more details on costs see Trading Tokens and Pricing for more details.

The Retrieve Organisation Data endpoint can be called by an organisation to retrieve a list of maker models from another organisation connected to it on the SQUIZZ.com platform. The endpoint will return a list of model records in the Maker Model Ecommerce Standards Document(ESD) JSON data format that the receiving organisation has been given access to download, based on the Data Sharing Policy that the supplying organisation has assigned to the receiving organisation.

Within the retrieved Maker Model JSON document, each model record is conforms to the Maker Model ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

HTTP Response Example:

Below is an example Maker Model Document returned by the API endpoint.

Tips and Recommendations:

• If possible call the endpoint using the SQUIZZ.com API's native programming language libraries to cut down on the amount of development work needed to retrieve the product data. See API Native Programming Libraries.
• When the maker model document is being returned from the API, in each of the model records any fields that had the default value set may be omitted from being included in the returned JSON. This cuts down on the amount of redundant JSON data that needs to be downloaded, speeding up retrieval times.
• Within the returned model document's configs property, the dataFields property will provide a list of all the record properties that can be expected to have data set for each model record. Then if a model field was not included in a record returned from the endpoint, then it can be presumed that its value would have been the default indicated in the table above.
• If you are saving the retrieved model data to a database, use the list of model fields in the dataFields property to indicate which fields of existing model records in your database should be updated. This can be very useful to ensure that not all model fields are being overwritten in your database, allowing some model data to be updated from an external data source, and other model data be left alone.
• Call the API endpoint to retrieve maker data from a supplier organisation first, then use the maker data in conjunction with the subsequent retrieved model data to gain additional information about each maker assigned to the each model record. Doing it this way avoids duplicate maker data being repeatedly downloaded with every model record, speeding up data retrieval times.
• Call the API endpoint to retrieve attributes data from a supplier organisation first, then use the attribute data in conjunction with the subsequent retrieved model data to gain additional information about each attribute and attribute profile the model attribute values are assigned to. This also avoids retrieving duplicate information about attributes and attribute profiles, speeding up data retrieval times.
• Note that there are trading token costs to call the endpoint. The supplying organisation may subsidise these costs, based on the data sharing policy assigned to the retrieving organisation. For more details on costs see Trading Tokens and Pricing for more details.

The Retrieve Organisation Data endpoint can be called by an organisation to retrieve a list of maker model mappings from another organisation connected to it on the SQUIZZ.com platform. Each Maker Model Mapping defines a product that belongs to a model and category. If a manufacturer builds a model that contains many interchangable parts, then an organisation may sell products that can be used/replaced/interchanged across many models. When an organisation maps each product to a model, it also must specify a category the a product is assigned to for the model. This allows categories of products to be assigned to each model, making it easier for people to see groups of products that each model contains, making it easier to find the products. When each product is mapped to a category and model, the quantity of products can also be set. This can indicate the quantity of products required for a part of the model.

The endpoint will return a list of maker model mapping records in the Maker Model Mapping Ecommerce Standards Document(ESD) JSON data format that the receiving organisation has been given access to download, based on the Data Sharing Policy that the supplying organisation has assigned to the receiving organisation.

Within the retrieved Maker Model Mapping JSON document, each model record is conforms to the Maker Model Mapping ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

HTTP Response Example:

Below is an example Maker Model Mapping Document returned by the API endpoint.

Tips and Recommendations:

• If possible call the endpoint using the SQUIZZ.com API's native programming language libraries to cut down on the amount of development work needed to retrieve the product data. See API Native Programming Libraries.
• When the maker model mapping document is being returned from the API, in each of the model mapping records any fields that had the default value set may be omitted from being included in the returned JSON. This cuts down on the amount of redundant JSON data that needs to be downloaded, speeding up retrieval times.
• Within the returned model mapping document's configs property, the dataFields property will provide a list of all the record properties that can be expected to have data set for each model mapping record. Then if a model field was not included in a record returned from the endpoint, then it can be presumed that its value would have been the default indicated in the table above.
• If you are saving the retrieved model mapping data to a database, use the list of model mapping fields in the dataFields property to indicate which fields of existing model records in your database should be updated. This can be very useful to ensure that not all model mapping fields are being overwritten in your database, allowing some model mapping data to be updated from an external data source, and other model data be left alone.
• Call the API endpoint to retrieve maker model data from a supplier organisation first, then use the maker model data in conjunction with the subsequent retrieved model mapping data to gain additional information about each model assigned to the each mapping record. Doing it this way avoids duplicate model data being repeatedly downloaded with every mapping record, speeding up data retrieval times.
• Call the API endpoint to retrieve product data from a supplier organisation first, then use the product data in conjunction with the subsequent retrieved model mapping data to gain additional information about each product assigned to each mapping record. Doing it this way avoids duplicate product data being repeatedly downloaded with every mapping record, speeding up data retrieval times.
• Call the API endpoint to retrieve category data from a supplier organisation first, then use the category data in conjunction with the subsequent retrieved model mapping data to gain additional information about each category assigned to each mapping record. Doing it this way avoids duplicate category data being repeatedly downloaded with every mapping record, speeding up data retrieval times.
• Call the API endpoint to retrieve attributes data from a supplier organisation first, then use the attribute data in conjunction with the subsequent retrieved mapping data to gain additional information about each attribute and attribute profile the model mapping attribute values are assigned to. This also avoids retrieving duplicate information about attributes and attribute profiles, speeding up data retrieval times.
• Note that the maximum record limit to retrieve maker model mapping records per request is increased to allow up to 100,000 records.
• Note that there are trading token costs to call the endpoint. The supplying organisation may subsidise these costs, based on the data sharing policy assigned to the retrieving organisation. For more details on costs see Trading Tokens and Pricing for more details.

The Retrieve Organisation Data endpoint can be called by an organisation to retrieve a list of products from another organisation connected to it on the SQUIZZ.com platform. The endpoint will return a list of product records in the Products Ecommerce Standards Document(ESD) JSON data format that the receiving organisation has been given access to download, based on the Data Sharing Policy that the supplying organisation has assigned to the receiving organisation. The Data Sharing Policy will also control the data in specific product record fields that is available to the retrieving organisation. This can be used by the organisation supplying the product data to limit what kinds of data is available to each connected organisation.

Within the retrieved Products JSON document, each product record is conforms to the Products ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

HTTP Response Example:

Below is an example Product Document returned by the API endpoint.

Tips and Recommendations:

• If possible call the endpoint using the SQUIZZ.com API's native programming language libraries to cut down on the amount of development work needed to retrieve the product data. See API Native Programming Libraries.
• When the product document is being returned from the API, in each of the product records any fields that had the default value set may be omitted from being included in the returned JSON. This cuts down on the amount of redundant JSON data that needs to be downloaded, speeding up retrieval times.
• Within the returned product document's configs property, the dataFields property will provide a list of all the record properties that can be expected to have data set for each product record. Then if a product field was not included in a record returned from the endpoint, then it can be presumed that its value would have been the default indicated in the table above.
• If you are saving the retrieved product data to a database, use the list of product fields in the dataFields property to indicate which fields of existing product records in your database should be updated. This can be very useful to ensure that not all product fields are being overwritten in your database, allowing some product data to be updated from an external data source, and other product data be left alone.
• Call the API endpoint to retrieve product data from a supplier first, then use the product data in conjunction with obtaining product pricing data and product stock quantities to match the supplying organisation's products to pricing and stock availability.
• Note that there are trading token costs to call the endpoint. The supplying organisation may subsidise these costs, based on the data sharing policy assigned to the retrieving organisation. For more details on costs see Trading Tokens and Pricing for more details.

The Retrieve Organisation Data endpoint can be called by an organisation to retrieve a list of product combinations from another organisation connected to it on the SQUIZZ.com platform. Product Combinations are used to find products based on finding parent products that contain a selection of fields with values, from where the combination of field values will find a child product that may be viewed or purchased. The fields and values are defined by combination profiles that parent products are assigned to. The endpoint will return both the combination profiles, as well as parent product and combination records in the Product Combination Ecommerce Standards Document (ESD) JSON data format that the receiving organisation has been given access to download, based on the Data Sharing Policy that the supplying organisation has assigned to the receiving organisation.. This can be used by the organisation supplying the product data to limit what kinds of data is available to each connected organisation.

Within the retrieved Product Combinations JSON document, each parent product record  conforms to the Product Combination Parent ESD Record format, the child products assigned to the Product Combination ESD Record format, the combination profiles defined by the Combination Profile ESD Record format and the combination profile fields defined by the Combination Profile Field ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

HTTP Response Example:

Below is an example Attribute Document returned by the API endpoint.

Tips and Recommendations:

• If possible call the endpoint using the SQUIZZ.com API's native programming language libraries to cut down on the amount of development work needed to retrieve the product data. See API Native Programming Libraries.
• When the product combination document is being returned from the API, in each of the combination profile, combination profile field. product combination parent or product combination records, in any fields that had the default value set may be omitted from being included in the returned JSON. This cuts down on the amount of redundant JSON data that needs to be downloaded, speeding up retrieval times.
• Call the API endpoint to retrieve product data from a supplier organisation first, then use the product data in conjunction with the subsequent retrieved product combination data to gain additional information about each product assigned to the each combination record. Doing it this way avoids duplicate product data being repeatedly downloaded with every product combination record, speeding up data retrieval times.
• The product combination parent product records returned will only include parent products that the calling organisation has permission to view, based on the data sharing policy that the supplying organisation has assigned. Similarly, product combination records that are linked child products will only be included if the calling organisation has permission to view those products.
• Note that there are trading token costs to call the endpoint. The supplying organisation may subsidise these costs, based on the data sharing policy assigned to the retrieving organisation. For more details on costs see Trading Tokens and Pricing for more details.

The Retrieve Organisation Data endpoint can be called by an organisation to retrieve a list of product pricing from another organisation connected to it on the SQUIZZ.com platform. The endpoint will return a list of pricing records in the Price Ecommerce Standards Document(ESD) JSON data format that the receiving organisation has been given access to download, based on the Data Sharing Policy that the supplying organisation has assigned to the receiving organisation and customer account. The Data Sharing Policy will control which products are allowed to be retrieved. The customer account will determine the prices that the retrieving organisation is allowed to buy the supplying organisation's products for.

Within the retrieved Pricing JSON document, each price record is conforms to the Price ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

HTTP Response Example:

Below is an example Price Document returned by the API endpoint.

The above example would define the following pricing rules from its records:

1. Buy 5 or more of product PROD-123 for $70.00 each
2. Buy 20 or more of product PROD-123 for $80.00 each. On forced contract, ID: FCONTRACT-1
3. Buy 1 or more of product PROD-123 for $75.30 each. On contract, ID: CONTRACT-222
4. Buy 0 or more of product PROD-456 for $3.30 each
5. Buy 6 or more of product PROD-456 for $13.20 per pack

Quantity Break/Volume Discount Pricing

When retrieving product pricing data from the endpoint it is possible that multiple prices could be returned for the same product for different quantities and sell units. This allows quantity breaks (also known as volume discount prices) to be made available by the supplier organisation. These quantity break prices may allow purchasing organisations to buy products for cheaper when more quantities are ordered. Each supplying organisation specifies the direction in which their quantity break prices become available, this is indicated in the returned pricing document by the value set in the "quantity_break_direction". This attribute can be set to one of the following values:

• EQUALABOVE
  This allows pricing rules to be set up as:
  Buy 5 or more products Each for $10.00
  Buy 10 or more products Each for $8.00
   
• EQUALBELOW
  This allows pricing rules to be set up as:
  Buy 5 or less products Each for $10.00
  Buy 10 or less products Each for $8.00
   
• ABOVE
  This allows pricing rules to be set up as:
  Buy more than 5 products Each for $10.00
  Buy more than 10 products Each for $8.00
   
• BELOW
  This allows pricing rules to be set up as:
  Buy 5 or less products Each for $10.00
  Buy 10 or less products Each for $8.00

When reading pricing data from the endpoint it is important the your software checks the "quantity_break_direction" attribute to ensure that it is correctly interpreting the quantity break prices.

Price Record Types

Each price record returned from the endpoint may define an entity that the supplier organisation has linked to it, this is set in the referenceID and referenceType fields. The referenceType can be set to one of the following:

• C - Contract
  Denotes that the price is linked to a contract. The contract may define unique pricing setup up by the supplying organisation, based on pre-agreed terms or deals. Typically the referenceID field would store the ID of the contract.
   
• CF - Contract With Forced Pricing
  Denotes that the price is linked to a contract. The contract may define unique pricing setup up by the supplying organisation, based on pre-agreed terms or deals. The contract defines pricing that will be priced for the product, even if it normally could be purchased for a cheaper price by another quantity break price. Typically the referenceID field would store the ID of the contract. This kind of contract typically locks in pricing for a period of time.
   
• P - Promotion
  Denotes that the price is linked to a promotion. The promotion could be a sale order some other unique event that warrants a different price for the product. Promotions do not lock in prices.

It is important to check if a quantity break price is associated to a forced contract, or not, since the forced contract price may override other quantity break prices. If you look at the above example pricing records obtained from the endpoint for product: PROD-123

1. Buy 5 or more of product PROD-123 for $70.00 each
2. Buy 20 or more of product PROD-123 for $80.00 each. On forced contract, ID: FCONTRACT-1
3. Buy 1 or more of product PROD-123 for $75.30 each. On contract, ID: CONTRACT-222

If 20 of the product were purchased it would cost $80.00, not $70 since the 2nd price rule is associated to a forced contract. If the 2nd price rule wasn't assigned to a forced contract then the product would cost $70 since the 1st price rule overrides 2nd price rule since it is cheaper.

Customer Accounts

When an one organisation connects to another organisation in the platform, each organisation can assign zero or more customer accounts to each other. The assigned customer account determines the pricing that a retrieving organisation can buy products for off a supplying organisation. It is possible that the supplier organisation may assign multiple customer accounts to a retrieving organisation. This would typically occur if the retrieving organisation had several divisions or contracts in place and wanted clear seperation of purchases. If multiple accounts are assigned then when calling the endpoint the retrieving organisation must explicitly provide the code of the customer account that products should be priced at. If only one customer account is assigned then the customer account code does not need to be specified.

Tips and Recommendations:

• If possible call the endpoint using the SQUIZZ.com API's native programming language libraries to cut down on the amount of development work needed to retrieve the pricing data. See API Native Programming Libraries.
• When the price document is being returned from the API, in each of the price records any non-mandatory fields that had the default value set may be omitted from being included in the returned JSON. This cuts down on the amount of redundant JSON data that needs to be downloaded, speeding up retrieval times.
• Within the returned price document's configs property, the dataFields property will provide a list of all the record properties that can be expected to have data set for each price record. Then if a price field was not included in a record returned from the endpoint, then it can be presumed that its value would have been the default indicated in the table above.
• If you are saving the retrieved price data to a database, use the list of price fields in the dataFields property to indicate which fields of existing price in your database should be updated. This can be very useful to ensure that not all price fields are being overwritten in your database, allowing some price data to be updated from an external data source, and other price data be left alone.
• Call the API endpoint to retrieve product data from a supplier first, then use the product data in conjunction with obtaining product pricing data and product stock quantities to match the supplying organisation's products to pricing and stock availability.
• Note that there are trading token costs to call the endpoint. The supplying organisation may subsidise these costs, based on the data sharing policy assigned to the retrieving organisation. For more details on costs see Trading Tokens and Pricing for more details.
• The endpoint can return either product pricing that the requesting organisating would receive if purchasing products from the supplying organisation, or return Recommended Retail Pricing (RRP) that contains product prices that consumers would pay at retail market rates. To obtrain RRP pricing data set the get_recommended_retail_pricing parameter to Y in the request.
• The requesting organisation may wish to separate request obtaining product pricing they recieve for purchasing products based on the trading relationship set up with the supplying organisation, as well as the RRP pricing. If the requesting organisation is on-selling then they can determine how much to markup the product prices, by using the RRP pricing as an upper limit. Note that organisations supplying product pricing data would need to have already imported a price level containing RRP product pricing, and assigned the RRP price-level to a selling region that matches the requesting organisation's assigned country/region. If this setup work hasn't occurred then a Permission Denied result_code may get returned instead.
• All pricing data returned by the endpoint may be stored excluding or inclusive of tax amounts, baesd on how the organisation supplying pricing data stores its pricing when imported. It can be found if a product has its pricing exclusive or including tax by calling the data retrieve API endpoint to obtain product data, and looking at the isTaxInclusive field.

The Retrieve Organisation Data endpoint can be called by an organisation to retrieve a list of product available stock quantities from another organisation connected to it on the SQUIZZ.com platform. The endpoint will return a list of stock quantity records in the Stock Quantity Ecommerce Standards Document(ESD) JSON data format that the receiving organisation has been given access to download, based on the Data Sharing Policy that the supplying organisation has assigned to the receiving organisation. The Data Sharing Policy will control which product stock quantities are allowed to be retrieved.

Within the retrieved Stock Quantity JSON document, each stock quantity record is conforms to the Stock Quantity ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

HTTP Response Example:

Below is an example Stock Quantity Document returned by the API endpoint.

Tips and Recommendations:

• If possible call the endpoint using the SQUIZZ.com API's native programming language libraries to cut down on the amount of development work needed to retrieve the pricing data. See API Native Programming Libraries.
• When the stock quantity document is being returned from the API, in each of the stock quantity records any non-mandatory fields that had the default value set may be omitted from being included in the returned JSON. This cuts down on the amount of redundant JSON data that needs to be downloaded, speeding up retrieval times.
• Within the returned stock quantity document's configs property, the dataFields property will provide a list of all the record properties that can be expected to have data set for each stock quantity record. Then if a stock quantity field was not included in a record returned from the endpoint, then it can be presumed that its value would have been the default indicated in the table above.
• If you are saving the retrieved stock quantity data to a database, use the list of stock quantity fields in the dataFields property to indicate which fields of existing stock quantity in your database should be updated. This can be very useful to ensure that not all stock quantity fields are being overwritten in your database, allowing some stock quantity data to be updated from an external data source, and other stock quantity data be left alone.
• Call the API endpoint to retrieve product data from a supplier first, then use the product data in conjunction with obtaining product pricing data and product stock quantities to match the supplying organisation's products to pricing and stock availability.
• You may want to call the endpoint to receive product stock quantity data on regular intervals eg. once an hour to have near realtime stock quantity data.
• Note that there are trading token costs to call the endpoint. The supplying organisation may subsidise these costs, based on the data sharing policy assigned to the retrieving organisation. For more details on costs see Trading Tokens and Pricing for more details.

The Retrieve Organisation Data endpoint can be called by an organisation to retrieve a list of product image records from another organisation connected to it on the SQUIZZ.com platform. The endpoint will return a list of image records in the Image Ecommerce Standards Document (ESD) JSON data format that the receiving organisation has been given access to download, based on the Data Sharing Policy that the supplying organisation has assigned to the receiving organisation. The Data Sharing Policy will control which product images are allowed to be retrieved based on the products that are allowed to be viewed. Note that the endpoint returns product image records, not the image data itself. That can be obtained from requesting the URL that is included in the image record data returned from this endpoint.

Within the retrieved Image JSON document, each image record conforms to the Image ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

HTTP Response Example:

Below is an example Stock Quantity Document returned by the API endpoint.

Tips and Recommendations:

• If possible call the endpoint using the SQUIZZ.com API's native programming language libraries to cut down on the amount of development work needed to retrieve the pricing data. See API Native Programming Libraries.
• When the image document is being returned from the API, in each of the image records any non-mandatory fields that had the default value set may be omitted from being included in the returned JSON. This cuts down on the amount of redundant JSON data that needs to be downloaded, speeding up retrieval times.
• Within the returned image document's configs property, the dataFields property will provide a list of all the record properties that can be expected to have data set for each image record. Then if a image field was not included in a record returned from the endpoint, then it can be presumed that its value would have been the default indicated in the table above.
• If you are saving the retrieved image data to a database, use the list of image fields in the dataFields property to indicate which fields of existing image in your database should be updated. This can be very useful to ensure that not all image fields are being overwritten in your database, allowing some image data to be updated from an external data source, and other image data be left alone.
• Call the API endpoint to retrieve product data from a supplier first, then use the product data in conjunction with obtaining product image data to match the supplying organisation's products to images.
• Note that there are trading token costs to call the endpoint. The supplying organisation may subsidise these costs, based on the data sharing policy assigned to the retrieving organisation. For more details on costs see Trading Tokens and Pricing for more details.

What needs to happen to allow our software to be able to retrieve data from one organisation, to either our own organisation, or an organisation we support?

The following would need to occur to support your software being able to retrieve data using this endpoint:

1. The organisation who's selling or supplying the data would need to be registered on SQUIZZ.com, and have uploaded/imported their data onto SQUIZZ.com. One person from that organisation must have signed up personally to SQUIZZ.com first, then registered the organisation.
2. The organisation who's retrieving the data needs to be registered on SQUIZZ.com, similar to step 1.
3. The organisation who's retrieving the data needs to have a person connected to it, assigned to the Administrator role, then they have set up the organisation's API credentials.
4. Both organisations have established a connection to each other, then the supplying organisation has granted permission for retrieving organisation to access the data, through Data Sharing Policy.
5. Your software has been given the API credentials set up in step 3, allowing your software to call the API to retrieve the supplying organisation's data that they have allowed access to with the retrieving oragnisation. Ensure that the API credentials are stored in a secure place, and not given out or accessible to any untrusted 3rd parties.

Can our software retrieve a single record when calling the endpoint, such as a single product?

No. This endpoint is not designed to retrieve a single record of data. It's designed to retrieve a list of records efficiently. This way your software receives a full page of records, and reduce the amount of round trips to obtain product data. The endpoint is designed so that your software obtains the full data set, that your software can then store or use as required. The endpoint is not designed for real time lookup of individual records.

Can the endpoint retrieve all associated data of a product in a single request?

No. The endpoint is designed to be very effecient at retrieve a list of records for only a certain data type. For products, if you wish to obtain associated pricing, categories, or other data, then you need to make separate requests to obtain the lists of associated data. This allows the servers to do less work by not having to lookup and combine associated data. Additionally your software spends less time having to wait to receive data. However it does mean that your software may need to pull the data sets of the individual types of data, then merge them together as required. You can see coding examples on how to do this within our API libraries hosted on our Github.