Platform API Endpoint: Import 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 imports different lists of organisation data based on the given data type. The data being imported must be placed into the Body of the HTTP request in the form of a conforming Ecommerce Standards Document JSON string that matches with the data type specified. For example this endpoint can be used to import a list of product records that have been wrapped up within a JSON formatted "Products Ecommerce Standards Document".Before using this endpoint we recommend that you understand what the Ecommerce Standards Documents are and how you can convert business data from your system into the standards. It is highly recommended that any data uploaded using this endpoint be compressed using the GZIP compression algorithm and uploaded in a stream. Note that there are trading token costs to import the organisation data using this API, of which the organisation importing the data must have enough tokens to allow the data to import. See the Trading Tokens and Pricing Help page for data import costs.

Data Import Types

Below is a list of the following types of documents and records that can be imported into the platform, with the data structured in JSON data conforming to the Ecommerce Standards Documents:

• Taxcodes - Record docs
• Price Levels - Record docs
• Products - Record docs
• Product Price-Level Unit Pricing - Record docs
• Product Price-Level Quantity Based Pricing - Record docs
• Product Customer Account Pricing - Record docs
• Alternate Codes - Attribute Profile Record, Attribute Record, Product Attribute Value Record docs
• Product Stock Quantities - Record docs
• Product Combinations - Combination Profile Record, Combination Profile Field Record, Product Combination Parent Record, Product Combination Record docs
• Attributes - Record docs
• Sales Representatives - Record docs
• Customer Accounts - Record docs
• Supplier Accounts - Record docs
• Customer Account Contracts - Record docs
• Customer Account Addresses - Record docs
• Locations - Record docs
• Purchasers - Record docs
• Surcharges - Record docs
• Payment Types - Record docs
• Sell Units - Record docs

HTTP Request

HTTP Response

HTTP Response Example:

The Import Organisation Data endpoint can be called by an organisation to import a list of attribute profiles, attributes and product attribute values into the SQUIZZ.com platform. Each "Attribute" defines extra fields that can store additional data against products, maker models, and maker model product mappings. Attributes allow additional data to be stored against the forementioned types of entities, effectively allowing for unlimited number fields to store data value against these entity types. Each attribute defines if the values stored against it are either in the STRING (Text), or NUMBER data types. Storing the attribute's values as numbers allows the values to be sorted numerically, otherwise be sorted alphabetically. Multiple values can be assigned to each attribute. Attributes are grouped together through the use of "Attribute Profiles". Each attribute can be assigned to one attribute profile, and an attribute profile may have many attributes assigned to it. The attribute data imported by this endpoint includes both the attribute profiles, and attribute values set against each product.

The endpoint needs to POST a list of attribute profile records and product attribute value records in the Attribute Ecommerce Standards Document (ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the attribute data was successfully imported or not. Attribute data can only be imported by an organisation if it has enough trading tokens to covert the costs of the attribute data import.See Trading Tokens and Pricing for more details.

Within the imported Location ESD JSON document, each attribute profile record is conforms to the Attribute Profile ESD Record format. Each attribute record assigned to an attribute profile conforms to the Attribute ESD Record format. Each product attribute value record conforms to the Attribute Value ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

Below is an example Attribute Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the attribute data. See API Native Programming Libraries.
• Products need to be imported before any product attribute value data is imported to ensure that any attribute values can be assigned to products when imported.
• Any attribute profiles and attributes assigned to product attribute value records must be defined within the ESD document being imported, otherwise the attribute values will be ignored from being assigned to the products.
• The Attribute Profiles and Attributes need to be imported before maker model data to allow attribute values to be assigned to maker models.
• The Attribute Profiles and Attributes need to be imported before maker model mapping data to allow attribute values to be assigned to maker model product mappings.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of categories and category trees into the SQUIZZ.com platform. Each category represents a collection of goods or services that an organisation offers. Each category may have any number of products assigned to it, and each product may be assigned to several categories.

Categories may be assigned against models allowing collections of products to be grouped together for each model. Additionally each category may be assigned to one other category, called its "parent". This allows people to navigate through a series of categories to find the products that they are looking for. This structure of having products and categories assigned to other categories creates a "category tree" data structure. Each category can be belong to one category tree, where each category tree represents a collection of categories that users can navigate through. Category Trees may be used to represent a single catalogue or product brochure. A limit of up to 5 category trees can be imported and set as active for a single data import. One of the category trees can be set as the default tree. For categories being imported that are not assigned to any category tree, they will be assigned to the default category tree. By default when an organisation is first registered on SQUIZZ.com a default category tree is already created.

The endpoint needs to POST a list of category records and category tree records in the Category Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the categories and category trees were successfully imported or not. Categories can only be imported by an organisation if it has enough trading tokens to cover the costs of the categories data import. See Trading Tokens and Pricing for more details.

Within the imported Customer Account ESD 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:

Below is an example Categories Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the category data. See API Native Programming Libraries.
• Product records need to be imported before category records to ensure that products can be assigned to categories, if category searching is required to be used to help customers/people find products that the organisation sells.
• Only the first 5 category tree records will be attempted to be imported. If more than 5 category trees exist in the imported data, then the additional category trees will be ignored.
• If a category record does not specify a keyCategoryTreeID to assigned itself to, then the category record will be assigned to the category tree that is set as the default. If there is no default tree then category record will be ignored from importing.
• If a category tree was previously imported and is not included in the latest category tree data to import, then it will be inactivated. An exception to this is if the inital category tree that is created when an organisation is first registered, it will not be deactivated if not included in the category tree list if it is still set as the default tree. If it is not the default tree then it will become deactivated.
• The category data will need to be imported before the Maker Model Mappings data import is run, to ensure that categories can be assigned to products for specified models. This is only required if make/model searching needs to be used by the organisation.
• In the keyProductIDs array the order of the keyProductIDs determines how products are sorted when listed within each given category by default.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import data. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of customer accounts into the SQUIZZ.com platform. Each customer account represents an organisation or person who buys off the organisation as a customer. Each customer accounts defines the payment terms, payment methods, and pricing that the customer is allowed to buy goods and services off the organisation for. A customer account is also known as a "debtor", which is used within accounting business systems to track the money that has been transferred between the customer and the organisation. A customer account may also be known as a "Vendor", "Business Partner" or "Customer", depending on the software an organisation users uses. Each customer account may have a number of records associated to it, including invoices, sales orders, back orders, payments and credits. It may also have sales representatives, conversations and contracts associated to customer account, required when using the Customer Relationship Management (CRM) features of the SQUIZZ.com platform. Once customer accounts are imported into the SQUIZZ.com platform, this can provide a link back to the associated customer account in the organisation's business system, from which sales orders and invoices can be imported against, and queried by customers in real-time using the platform's Account Enquiry feature. Customer Accounts must be imported into the platform to allow an organisation to sell on the platform to one or more customers.

The endpoint needs to POST a list of customer account records in the Customer Account Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the customer accounts were successfully imported or not. Customer Accounts can only be imported by an organisation if it has enough trading tokens to cover the costs of the customer accounts data import. See Trading Tokens and Pricing for more details.

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

HTTP Request Raw Example:

Below is an example Customer Accounts Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the customer account data. See API Native Programming Libraries.
• Sales Representative records may need to be imported before customer account records to ensure that customer accounts can be assigned to sales representatives, if sales representatives are required to be used.
• Price Level records need to be imported before customer account records to ensure that customer accounts can be assigned to their price levels, and thus be assigned to product pricing.
• Location records may need to be imported before customer account records to ensure that customer accounts can be assigned to locations. This is only required if sales orders created against the customer account must have a location assigned to the order.
• The first keyLocationID in the locations set for each customer account record will be denoted as the default, primary location assigned to the customer account. This primary location will be assigned to sales orders created against the customer account, to denote the location where its products may need to be picked/packed or shipped from.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import data. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of makers (also known as manufacturers) into the SQUIZZ.com platform.  Each maker manufactures or assembles products, also known as models that may contain a collection of products, parts or raw materials. Makers can be used to enable people to find products that the organisation sells, based on the products associated to models that the maker constructs, also known as Make/Model searching. Each maker may be representative of a single person, organisation, or collection of entities.

The endpoint needs to POST a list of customer account records in the Maker Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the makers were successfully imported or not. Makers can only be imported by an organisation if it has enough trading tokens to cover the costs of the makers data import. See Trading Tokens and Pricing for more details.

Within the imported Maker ESD 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:

Below is an example Makers Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the maker data. See API Native Programming Libraries.
• Maker records are needed to be imported before maker model records to ensure that models can be assigned to makers.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import data and have it hosted. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of maker/manufacturer models into the SQUIZZ.com platform. Each model represents a collection of products or raw materials that are manufactured together by a maker (also known as a manufacturer) to produce a completed model. Each organisation may assign its products to different categories against each model, to indicate the products (also known as parts) that it offers to maintain the model. Many industries use models and provide interchangable products for models, some examples include vehicles, printers, computers/devices, toys, and many more.

For each model there's ability to assign many attribute values to it. Each attribute defines an additional field that values can be set against. This allows organisations to provide additional information about a model, depending on the type of model that it is, or the specifications of a model. For example if a model was a car, then attributes may define the engine size, car type, primary paint colours, or technical details of a car such as measurements. In order for attributes to be assigned to models, an organisation must first import attribute profiles into SQUIZZ.com that define the attributes that values can be assigned to for each model. Model attribute values can either be set as STRING (text) values, or NUMBER values. Use numeric values to allow them to be ordered numerically, otherwise set STRING values to store any kinds of text characters that will be sorted alphanumerically.

The endpoint needs to POST a list of maker model records in the Maker Model Ecommerce Standards Document (ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the maker models were successfully imported or not. Models can only be imported by an organisation if it has enough trading tokens to covert the costs of the maker model data import. See Trading Tokens and Pricing for more details.

Within the imported Maker Model ESD JSON document, each model record is conforms to the Maker Model ESD Record format. Each attribute value record assigned to a model record conforms to the Attribute Value ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

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

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the maker model data. See API Native Programming Libraries.
• Makers need to be imported before any maker model data is imported to ensure that models can be assigned to makers when imported. Use the Makers data import to import the Makers.
• Attribute Profiles and Attributes need to be imported first if model attribute values are to be saved when imported, or any unmatching attribute value records will be ignored from importing with each model. Use the Attributes data import to import the Attribute Profiles and Attributes.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing model records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of maker/manufacturer model mappings into the SQUIZZ.com platform. Each mapping links a product to category for a specified maker model. 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 must also specify a category that a product is assigned to for a model. This allows categories of products to be assigned to each model, making it easier for people to understand the kinds of products that each model contains and making it easier to find the products. When each product is mapped to a category and model, the quantity of product can also be set. This can indicate the quantity of products required for a part of the model.

For each model there's ability to assign many attribute values to it. Each attribute defines an additional field that values can be set against, that allows organisations to provide additional information about a model, depending on the type of model it is, or the specifications of a model. For example if a model was a car, then attributes may define the engine size, car type, primary paint colours, or technical details of a car such as measurements. In order for attributes to be assigned to models, an organisation must first import attribute profiles into SQUIZZ.com that define the attributes that values can be assigned to for each model. Model attribute values can either be set as STRING (text) values, or NUMBER values. Use numeric values to allow them to be ordered numerically, otherwise set STRING values to store any kinds of text characters that will be sorted alphanumerically.

The endpoint needs to POST a list of maker model mapping records in the Maker Model Mapping Ecommerce Standards Document (ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the maker model mappings were successfully imported or not. Mappings can only be imported by an organisation if it has enough trading tokens to covert the costs of the maker model mapping data import. See Trading Tokens and Pricing for more details.

Within the imported Maker Model Mapping ESD JSON document, each mapping record is conforms to the Maker Model Mapping ESD Record format. Each attribute value record assigned to a mapping record conforms to the Attribute Value ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

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

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the maker model mapping data. See API Native Programming Libraries.
• Maker Models need to be imported before any maker model mapping data is imported to ensure that products can be assigned to models when imported. Use the Maker Model data import to import the Maker Models.
• Categories need to be imported before any maker model mapping data is imported to ensure that products can be assigned to categories and models when imported. Use the Category data import to import the Categories.
• Attribute Profiles and Attributes need to be imported first if model mapping attribute values are to be saved when imported, otherwise any unmatching attribute value records will be ignored from importing with each model mapping. Use the Attributes data import to import the Attribute Profiles and Attributes.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of locations into the SQUIZZ.com platform. Each location can represent a physical geographic location such as a store, warehouse, or site at a specified address. Locations may also represent the internal area of building, or a theoretical non-physical location. Each location may have any number of products assigned to it, with each product indicating how much of it is in stock at the location. This is typically used to indicate stock availability at a store, warehouse, building or site. Locations can be assigned to customer accounts, allowing customers to order products from selected locations. Locations can be assigned to sales orders and derived invoices, to indicate where product stock needs to be picked, packed and delivered from. A location can be set at the sales order level, or at the line level allowing individual products to be shipped from multiple locations.

The endpoint needs to POST a list of location records in the Location Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the locations were successfully imported or not. Locations can only be imported by an organisation if it has enough trading tokens to covert the costs of the location data import. See Trading Tokens and Pricing for more details.

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

HTTP Request Raw Example:

Below is an example Location Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the location data. See API Native Programming Libraries.
• Products need to be imported before any location data is imported to ensure that any product stock quantities can be assigned to locations when imported.
• Locations need to be imported before customer account data to allow customer accounts to be assigned to locations.
• Set up Sales Order rules within the Admin section of an organisation's profile to allow different order data to dictate the location that is assigned to a sales order, such as checking the delivery suburb, state or country to determine the most appropriate location to ship ordered products from.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of payment types into the SQUIZZ.com platform. Each payment type defines a way that a customer can pay for goods and services. Many payment types can be assigned to each customer account, and when a person needs to pay for either a sales order or invoice linked to a customer account in the platform, the payment options available to the person will be based on the payment types assigned to the account. For example customer accounts may be assigned to a payment type called "On Account", that specifies that the customer pays for orders after an agreed period of time. Another payment type called "Credit Card" could be created that allows customers to pay for sales orders with a credit card at the time of the sales order is being raised. Payment Types are required to be imported by an organisation first before any customer account data is imported.

The endpoint needs to POST a list of payment records in the Payment Type Ecommerce Standards Document(ESD) JSON data format. The endpoint will return an general Ecommerce Standards Document in the JSON data format that indicates if the payment  types were successfully imported or not. Payment Types can only be imported by an organisation if it has enough trading tokens to covert the costs of the payment type data import. See Trading Tokens and Pricing for more details.

Within the imported Payment Type ESD JSON document, each payment type record is conforms to the Payment Type ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

Below is an example Payment Type Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the payment type data. See API Native Programming Libraries.
• Typically payment types data only needs to be imported by organisations when a new type of payment type is made available by an organisation.
• Payment Types need to be imported before Customer Account data to ensure that accounts can be assigned to their allowed payment types.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of price levels into the SQUIZZ.com platform. Price levels allow for multiple prices to be set against each product. Customer accounts are then designated to a price level, and this determines the pricing that the customer will see when purchasing products. Price levels allow organisations to sell a product at different prices to certain customers. For example customers who repeatedly buy in bulk may be assigned to a price level that allows them to buy products at a cheaper price than other customers who buy less and are assigned to a more expensive price level. Price levels can be also be used to set prices of products for customers within different regions of a country or international. Price levels are  conditionally required to be imported by an organisation first before any product price-level pricing data is imported.

The endpoint needs to POST a list of price level records in the Price Level Ecommerce Standards Document(ESD) JSON data format. The endpoint will return an general Ecommerce Standards Document in the JSON data format that indicates if the price levels were successfully imported or not. Price Levels can only be imported by an organisation if it has enough trading tokens to covert the costs of the price level data import. See Trading Tokens and Pricing for more details.

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

HTTP Request Raw Example:

Below is an example Price Level Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the price level data. See API Native Programming Libraries.
• Typically price level data only needs to be imported by organisations when a new price level is added to their business systems.
• Many business systems have a fixed number of price levels that don't change, and if that's the case then the price level data would only need to be imported once.
• Price Levels need to be imported before Customer Account data to ensure Customer Accounts can be assigned to a price level.
• Price Levels need to be imported before Product Price Level Unit Pricing and product Price Level Quantity Pricing to ensure pricing data can be saved against an existing price level.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of products into the SQUIZZ.com platform. Each product may be physical object such as a chair, or a non-physical product such as a ticket to an event. Once imported the organisation can sell these products to other organisations and people on the platform, or use the products to match up inventory being purchased from other supplier organisations.

The endpoint needs to POST a list of product records in the Product Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the products were successfully imported or not. Products can only be imported by an organisation if it has enough trading tokens to covert the costs of the product data import. See Trading Tokens and Pricing for more details.

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

HTTP Request Raw Example:

Below is an example Product Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the product data. See API Native Programming Libraries.
• Taxcodes need to be imported before Product data is imported to ensure that a taxcode can be assigned to a product when imported.
• Sell Units need to be imported before Product data to ensure sell units can be assigned to a product when imported.
• At least one sell unit must be assigned to a product to allow it to be sold.
• For each product multiple sell units can be assigned to it, to allow the product to be sold in many different quantities, such as individual units, packs, containers, train loads, boxes.
• Sell units can be linked to each other when assigned to each product in a hierarchy. These relationships allow customers to switch between the amount of units they are purchasing for a product.
• Using sell units may negate the need to create separate products when a product is bundled in different amounts.
• Product data needs to be imported before pricing data, locations is imported.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of combination profiles, profile fields, profile field values, and product combinations into the SQUIZZ.com platform. Product Combinations allows groups of products to be assigned to parent products, that collectively represents them. When the parent product is viewed, the child products can be found based on being assigned to set of fields and values that can be chosen from. It is these "combination" of field values selected that determines the child product that can then be viewed or purchased. Product Combinations are an ideal data structure to use when there are many products of similar style, appearance, or contain shared characteristics. By initially searching through a reduced range of parent, representative products, the refining options to find the the child product, can make it quicker and easier to find required product. Typical usages of Product Combinations are for clothing, electronic devices, automotive products, among many many more.

Product Combinations uses Combination Profiles, where profiles define common field and field values that can be used across a range of parent products, and assigned against each of the child products. This allows a standard list of fields and values to be reused. For example, clothing sizes come in common set of sizes. One Combination Profile could define the sizes and be assigned to many different parent clothing products. The child products would then be assigned to the same common size field values for different parent products. Using profiles removes the need to continually define the same field names, and field values, and may cut down the data work.

The endpoint needs to POST a list of combination profile records, combination profile field records, product combination parent records and product combination records in the Product Combination Ecommerce Standards Document (ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the combination data was successfully imported or not. Product Combination data can only be imported by an organisation if it has enough trading tokens to covert the costs of the combination data import.See Trading Tokens and Pricing for more details.

Within the imported Product Combination ESD JSON document, each combination profile record is conforms to the Combination Profile ESD Record format. Each combination profile field record assigned to an combination profile conforms to the Combination Profile Field ESD Record format. Each product combination parent record conforms to the Product Combination Parent ESD Record Format, and each product combination record conforms to the Product Combination ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

Below is an example Product Combination Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the attribute data. See API Native Programming Libraries.
• Products need to be imported before any product combination data is imported to ensure that parent combination products can be assigned to a combination profile, and child products can be assigned to parent products for a given product combination.
• Any Combination Profiles assigned to Product Combination Parent records must be defined within the ESD document being imported, otherwise parent products will be ignored from being assigned to a Combination Profile.
• Any Combination Profile Fields and Field Values  assigned to Product Combination records must be defined within the ESD document being imported, otherwise child products will be ignored from being assigned to a Combination Profile Fields, or parent products.
• If a product is assigned to multiple Product Combination Parent records, then it will only be assigned to the Combination Profile of the first record. Any subsequent records will be ignored. This ensures that a product can be a parent of one set of product combinations.
• Any products that are assigned as a parent of a product combination will no longer be able to be directly purchased. Instead only the child products assigned against will be able to be purchased.
• If a product is no longer assigned to any Product Combination Parent records, then it will be unassigned to combination profiles and no longer be marked as a parent any more. This then allows the product to be directly purchased.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of alternate codes that are linked to an organisation's products imported into the SQUIZZ.com platform. Each alternate code can be linked to a product, and denote that the alternate code may be a code assciated to a product of a manufacturer, supplier, customer, industry, standards product, or be linked to a another product. Alternate codes allow a product to have many different codes known by different people and systems.

The endpoint needs to POST a list of alternate code records in the Alternate Code Ecommerce Standards Document(ESD) JSON data format. The endpoint will return an general Ecommerce Standards Document in the JSON data format that indicates if the alternate codes were successfully imported or not. Alternate Codes can only be imported by an organisation if it has enough trading tokens to covert the costs of the alternate code data import. See Trading Tokens and Pricing for more details.

Within the imported Alternate Code ESD JSON document, each alternate code record is conforms to the Alternate Code ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

Below is an example Alternate Code Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the alternate code data. See API Native Programming Libraries.
• Products need to be imported before Alternate Code data to ensure that the alternate codes can be assigned to an existing product in the platform.
• Supplier Accounts needs to be imported before to ensure that any alternate codes that reference a supplier account can be assigned to a supplier account already imported into the platform.
• Customer Accounts needs to be imported before to ensure that any alternate codes that reference a customer account can be assigned to a customer account already imported into the platform.
• Assign alternate codes to products that contain the supplier's product code and are linked to a supplier account. This will allow the Order Procurement process to automatically find and match the supplier's products to a purchase order being submitted by the organisation.
• Assign alternate codes to products that contain the customer's product code and are linked to a customer account. This will allow the Invoicing process to automatically find and match the customer's products when an invoice is being sent back to a customer.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of price-level unit prices for products into the SQUIZZ.com platform. Each organisation's product may have many prices assigned to it, based on the number of "price levels" imported for each organisation, and the number of sell units assigned to each product. For each price level a pricing record will define the unit price that any customers assigned to the price level will pay to purchase 1 sell unit of the product. Since each product may have many different sell units assigned to it, there can be as many different unit prices assigned to products through this import as there are price-levels and sell units assigned to a product. For example if an organisation has previously imported 5 different price-levels, and for a "tea-towel" product it is assigned to 3 different sell units "Each", "Pack", "Container", then a product can have imported 5x3 = 15 different price-level unit prices. Using price levels an organisation may have cheaper or more expensive unit prices for each product, to sell the product for cheaper to customers on one price-level compared to other customers assigned to more expensive price levels.
Unit prices are used in product search listings on the platform so that customers of an organisation can initially see how much a product costs for them if they had bought a single product of a given sell unit.

The endpoint needs to POST a list of pricing records in the Pricing Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the pricing records were successfully imported or not. Pricing records can only be imported by an organisation if it has enough trading tokens to covert the costs of the price-level unit pricing data import. See Trading Tokens and Pricing for more details.

Within the imported Price ESD JSON document, each pricing 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:

Below is an example Price Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the pricing data. See API Native Programming Libraries.
• Price Levels need to be imported before pricing data is imported to ensure that a price record can be assigned to a price-level for a product when imported.
• Sell Units need to be imported before Product data to ensure sell units can be assigned to a product when imported.
• Products need to be imported before pricing data is imported to ensure that a price record can be assigned to a product when imported.
• For each product multiple price-level unit prices can be assigned to it, to allow the product to be sold in many price-levels. Additionally multiple price-level unit prices can be assigned to the same price-level for a product across all the different sell units assigned to the product.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.
• Only import price-level unit prices for price-levels actively being used or download by customers. Having unused price records will cost more trading tokens for little positive value.
• Once price-level unit pricing has been imported then customers may be able to download the pricing for their assigned price level through the API's retrieve data endpoint, or in platform. based on the customer account that a customer is assigned to. This allows customers to automate the retrieval of pricing data back into their own systems.
• Update pricing regularly to ensure that any sales orders created by customers contains the most up to date pricing.
• Only one quantity break direction can be set across all product quantity prices. For example the Quantity Break Direction can be set to one of the following within the Organisation Settings (make sure this matches the business system where the prices are coming from):
  • Buy Over Quantity For Price X
  • Buy Equal To Or Over Quantity For Price X
  • Buy Under Quantity For Price X
  • Buy Equal to Or Under Quantity For Price X

The Import Organisation Data endpoint can be called by an organisation to import a list of price-level quantity prices for products into the SQUIZZ.com platform. Each organisation's product may have many prices assigned to it, based on the number of "price levels" imported for each organisation, and the number of sell units assigned to each product, as well as quantity breaks, also known as volume discounts. Quantity based pricing allows customers to buy a product for a cheaper price when they purchase over/equal to and over/under/equal to or under a specified quantity. This allows customers to receive discounts by purchasing products in greater quantities. The "product price-level quantity based pricing" import allows quantity break pricing to be imported against each product for a specified price-level and sell unit. This allows customers on an assigned price-level to receive certain volume discounts for each product that other customers assigned to other price-levels may not.

For each price level a pricing record will define the quantity based price that any customers assigned to the price level will pay to purchase 1 sell unit of the product. Since each product may have many different sell units assigned to it, there can be as many different quantity based prices assigned to products through this import as there are price-levels and sell units assigned to a product. For example if an organisation has previously imported 5 different price-levels, and for a "tea-towel" product it is assigned to 3 different sell units "Each", "Pack", "Container", and 4 quantity breaks exist for all price-levels, then a product can have imported 5x3x4 = 60 different price-level quantity based prices.

The endpoint needs to POST a list of pricing records in the Pricing Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the pricing records were successfully imported or not. Pricing records can only be imported by an organisation if it has enough trading tokens to covert the costs of the price-level unit pricing data import. See Trading Tokens and Pricing for more details.

Within the imported Price ESD JSON document, each pricing 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:

Below is an example Price Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the pricing data. See API Native Programming Libraries.
• Price Levels need to be imported before pricing data is imported to ensure that a price record can be assigned to a price-level for a product when imported.
• Sell Units need to be imported before pricing data to ensure sell units can be assigned to a product when imported.
• Products need to be imported before pricing data is imported to ensure that a price record can be assigned to a product when imported.
• For each product multiple price-level quantity prices can be assigned to it, to allow the product to be sold in many price-levels. Additionally multiple price-level unit prices can be assigned to the same price-level for a product across all the different sell units assigned to the product.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.
• Only import price-level quantity prices for price-levels actively being used or download by customers. Having unused price records will cost more trading tokens for little positive value.
• Once price-level quantity pricing has been imported then customers may be able to download the pricing for their assigned price level through the API's retrieve data endpoint, or in platform. based on the customer account that a customer is assigned to. This allows customers to automate the retrieval of pricing data back into their own systems.
• Update pricing regularly to ensure that any sales orders created by customers contains the most up to date pricing.

The Import Organisation Data endpoint can be called by an organisation to import a list of customer account prices for products into the SQUIZZ.com platform. Each organisation's product may have many prices assigned to it, based on the prices that are assigned to specific customers. This allows products to have pricing set for certain customers, such as used for contracts and promotions. This allows customers to buy a product for a cheaper or dearer price of a product for a specified quantity and sell unit. Each customer account price can force its price to be set for a product, known as Forced Contract pricing, regardless if the customer account is assigned to a price-level price that is cheaper then the account price. This is useful for when a customer agrees to purchase products at a specified price over a certain time frame, regardless if the product becomes cheaper or dearer over time.

For each pricing record it will define the quantity based price that any customers assigned to it will pay to purchase one or more sell units of the product. Since each product may have many different sell units assigned to it, there can be as many different customer account quantity based prices assigned to products through this import. Customer Account Price records can either be assigned to a specific customer account, or be assigned to a "Price Group". Each price group can contain a list of 0 or more customer accounts assigned to it. By using price groups it may reduce the amount of pricing records that need to be imported in this data import, such as when many customer accounts are assigned to the same contract and receive the same pricing.

The endpoint needs to POST a list of pricing records in the Pricing Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the pricing records were successfully imported or not. Pricing records can only be imported by an organisation if it has enough trading tokens to covert the costs of the price-level unit pricing data import. See Trading Tokens and Pricing for more details.

Within the imported Price ESD JSON document, each pricing 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:

Below is an example Price Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the pricing data. See API Native Programming Libraries.
• Customer Accounts need to be imported before pricing data is imported to ensure that a price record can be assigned to a customer account when imported.
• Sell Units need to be imported before pricing data to ensure sell units can be assigned to a product when imported.
• Products need to be imported before pricing data is imported to ensure that a price record can be assigned to a product when imported.
• For each product multiple customer account quantity based prices can be assigned to it, to allow the product to be sold at different prices to several different customer accounts. Additionally multiple product prices can be assigned to the same customer account for a product across all the different sell units assigned to the product.
• Use price-groups instead of assigning individual customer accounts to price records, when multiple accounts receive the same pricing. For example this could occur if multiple customer accounts are assigned to the same contract, promotion, or deal.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.
• Only import customer account prices for customer accounts actively being used or downloaded by customers. Having unused price records will cost more trading tokens for little positive value.
• Once customer account pricing has been imported then customers may be able to download the pricing for their account through the API's retrieve data endpoint, or in platform. based on the customer account that a customer is assigned to. This allows customers to automate the retrieval of pricing data back into their own systems.
• Update pricing regularly to ensure that any sales orders created by customers contains the most up to date pricing.

The Import Organisation Data endpoint can be called by an organisation to import a list of customer account contracts into the SQUIZZ.com platform. Each organisation's customer account contract defines a list of products and customer accounts that are bound to each contract. 

Organisations typically set up contracts in a business system to lock in pricing for set period of time, for one or more customers. This may be done to provide certainty for selected customers, or to set exceptional pricing that is different from their usual price-level product prices. Contracts can also be used to provide a list of products that certain customers may regularly order with and can more easily find. 

When importing contracts with this endpoint it doesn't handle importing any product contract pricing itself, since that is done by calling the Product Customer Account Pricing data import with all other customer specific prices. Also note that pricing records imported from that separate endpoint can be referenced back to contracts imported with this endpoint using a price records's referenceID field, and reference type fields.

The endpoint needs to POST a list of customer account contract records in the Customer Account Pricing Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the contract records were successfully imported or not. Customer Account Contract records can only be imported by an organisation if it has enough trading tokens to cover the costs of the customer account pricing data import. See Trading Tokens and Pricing for more details.

Within the imported Customer Account Contract ESD JSON document, each contract record conforms to the Customer Account Contract ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

Below is an example Customer Account Contract Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the contract data. See API Native Programming Libraries.
• It's recommended to import Customer Accounts before contract data is imported to ensure that a customer account record can be assigned to a contract when imported. If the customer account does not exist then it will be ignored from being assigned to the contract.
• It's recommended to import Products before contract data is imported to ensure that a product record can be assigned to a contract when imported. If the product does not exist then it will be ignored from being assigned to the contract.
• Each Customer Account can be assigned to many contracts.
• Each Product can be assigned to many contracts.
• Contracts can be used to help customers find a list of chosen products more easily. In effect they can be used like shopping lists, or order templates.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.
• Only import contracts for customer accounts and products actively being used by customers or staff. Having unused contract records will cost more trading tokens for little positive value.
• Import customer account contract pricing with any other customer specific pricing records using the separate Import Product Customer Account Pricing data import. Within each pricing record there is the ability to reference the price record back to the contract using the price record's referenceID, and reference Type fields. Any product prices applicable to customers can then be indicated as contract prices.

The Import Organisation Data endpoint can be called by an organisation to import a list of stock quantities available for products imported by an organisation into the SQUIZZ.com platform. This allows the available stock quantities of products to be updated on a regular basis, which may be required to indicate if products are able to be purchased or not. Each of the stock quantities given indicates how much stock is available be purchased for a product's base sell unit.

The endpoint needs to POST a list of stock quantity records in the Stock Quantity Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the stock quantities were successfully imported or not. In order for stock quantities to be imported the products must first be imported. Stock quantities can only be imported by an organisation if it has enough trading tokens to cover the costs of the stock quantities data import. See Trading Tokens and Pricing for more details.

Within the imported Stock Quantity ESD 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:

Below is an example Product Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the stock quantity data. See API Native Programming Libraries.
• Stock quantities need to be imported only after Product data has first been imported data to ensure that stock units can be assigned to a product when imported.
• Use this Stock Quantities data import to regularly update the available stock quantities for products to customers. The more often the stock quantities are updated the closer an accurate figure is available to customers.
• Product stock quantities can also be updated using the Products data import, however the Stock Quantities data import is a much more lightweight and faster approach to update stock quantities due to the reduced amount of data needing to be uploaded and processed.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import data. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of related product data, also known as Item Relations, into the SQUIZZ.com platform. This allow each product to be linked to a list of other products. This related products list can then display when the details of a product show, allowing people to find other products that they may wish to view and purchase. Ultimately it may lead to increased sales for a selling organisation.

The endpoint needs to POST a list of item relation records in the Item Relation Ecommerce Standards Document (ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the item relations were successfully imported or not. In order for the item relations to be imported the products must first be imported. Item Relations can only be imported by an organisation if it has enough trading tokens to cover the costs of the item relations data import. See Trading Tokens and Pricing for more details.

Within the imported Item Relation ESD JSON document, each item relation record is conforms to the Item Relation ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

Below is an example Product Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the stock quantity data. See API Native Programming Libraries.
• Item Relations need to be imported only after Product data has first been imported data to ensure that the related products can be assigned to existing products when imported.
• A limit of 20 related products can be assigned to a single product. If additional related products are attempted to be assigned to a given product then they will be ignored.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import data. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of purchasers into the SQUIZZ.com platform. Each purchaser record indicates a person or other entity that can buy goods and services for the organisation. Purchasers can be assigned as a default to each supplier account, to act as a purchaser manager, as well be linked to one or more people. This allows people connected to the organisation, and purchasers to view details of its assigned supplier account, as well as create purchase orders. When purchase orders are raised the purchaser who created the purchaser order may be assigned to it. This can be used by organisations to report how much a purchaser is buying, and may be used to determine budgets or other actions for people associated to the purchaser record. Purchaser records must be imported and assigned against supplier accounts to allow purchasing people within the organisation to use the Order Procurement process to raise orders against supplier organisation(s).

The endpoint needs to POST a list of sales representative records in the Purchaser Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the purchasers were successfully imported or not. Purchasers can only be imported by an organisation if it has enough trading tokens to cover the costs of the purchaser data import. See Trading Tokens and Pricing for more details.

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

HTTP Request Raw Example:

Below is an example Purchaser Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the purchaser data. See API Native Programming Libraries.
• Purchaser records need to be imported before supplier account records to ensure that supplier accounts can be assigned to purchasers.
• Once Purchaser records have been imported, multiple people connected to the organisation can be assigned to each Purchaser record. This allows multiple people to manage or purchase for one or more supplier accounts.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import data. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of sales representatives into the SQUIZZ.com platform. Each sales representative record indicates a person or other entity that can sell goods and services for the organsiation. Sales representatives can be assigned as a default to each customer account, to act as an account manager, as well be linked to one or more people. This allows people connected to the organisation, and a sales representative to view details of its assigned customer account, as well as create sales orders. When sales orders are raised the sales representative who created the sales order may be assigned to it. This can be used by organisations to report how much a sales representative is selling, and may be used to determine bonuses, commissions or other actions for people associated to the sales representative record.

The endpoint needs to POST a list of sales representative records in the Sales Representative Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the sales representatives were successfully imported or not. Sales Representatives can only be imported by an organisation if it has enough trading tokens to cover the costs of the sales representatives data import. See Trading Tokens and Pricing for more details.

Within the imported Sales Representative ESD JSON document, each sales representative record is conforms to the Sales Representative ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports:

HTTP Request Raw Example:

Below is an example Sales Representative Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the sales representative data. See API Native Programming Libraries.
• Sales representative records need to be imported before customer account records to ensure that customer accounts can be assigned to sales representatives.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import data. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of sell units into the SQUIZZ.com platform. Sell units describe how quantities of products can be bundled together. For example a sell unit called "Each" that describes a product being sold as an individual unit. Another sell unit called "Pack" could be created that describes multiple quantities of of product bundled together into a pack. Any number of sell units can be created, each with their own label. This import allows generic named sell units to be imported, such as "each", "pack", "carton", "container", "box". Then separately these sell units can be assigned to each product in the Product Import endpoint, with each product describing the label of the sell unit specific to the product. So an "each" sell unit could be assigned to a product, but the product would label the "each" sell unit as "drum", and the "pack" sell unit as "box of 6 drums".

Sell Units can be linked to each other in a hierarchy. This hierarchy can be used to allow customers to switch between sell units for a product, and the quantities will adjust accordingly based on the quantity of one sell unit that makes up another. For example if a "pack" sell unit has its parent sell unit set to "each", then if a product defines that 6 "each" quantities make up 1 "pack" sell unit, then if the customer changes the product being purchased from 1 pack to the each sell unit, then the value 6 will update in the quantity box. A sell unit can specify if it is the base sell unit, this means that it is top of the sell unit hierarchy and represents an individual quantity. All other sell units at all levels of the hierarchy can indicate how many base sell unit quantities make up a sell unit. Sell units can also specify if they should be priced based on calculating the amount of base sell units quantities that make up a sell unit. This can reduce the amount of pricing records that need to be imported.

Sell Units are conditionally required to be imported by an organisation first before any product, product price-level unit pricing. price-level quantity pricing, or customer account pricing data is imported.

The endpoint needs to POST a list of sell unit records in the Sell Unit Ecommerce Standards Document(ESD) JSON data format. The endpoint will return an general Ecommerce Standards Document in the JSON data format that indicates if the sell units were successfully imported or not. Sell Units can only be imported by an organisation if it has enough trading tokens to covert the costs of the sell unit data import. See Trading Tokens and Pricing for more details.

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

HTTP Request Raw Example:

Below is an example Sell Unit Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the sell unit data. See API Native Programming Libraries.
• Typically sell unit data only needs to be imported by organisations when a new type of sell unit is added to an organisation's business system.
• Many business systems have a fixed number of sell units that don't change, and if that's the case then the sell unit data would only need to be imported once.
• Sell Units need to be imported before Product, Product Price-Level Unit Pricing, Price-Level Quantity Pricing and Customer Account Pricing data to ensure that products and their pricing can be assigned to sell units.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of supplier accounts into the SQUIZZ.com platform. Each supplier account represents an organisation or person who the organisation purchases goods and services from. Each supplier accounts defines the payment terms, payment methods, and pricing that the supplier is allowed to buy goods and services off the organisation for. A supplier account is also known as a "creditor", which is used within accounting business systems to track the money that has been transferred between the organisation and its supplier. A supplier account may also be known as a "Business Partner" or "Supplier", depending on the software an organisation uses. Each supplier account may have a number of records associated to it, including invoices, purchase orders, payments and credits. It may also have purchasers associated to supplier account to denote which people are allowed to make purchases against the supplier. Once supplier accounts are imported into the SQUIZZ.com platform, this can provide a link back to the associated supplier account in the organisation's business system, from which purchase orders and invoices can be imported against, and queried by purchasers in real-time using the platform's Order procurement feature. Supplier Accounts must be imported into the platform to allow an organisation to buy on the platform with one or more suppliers.

The endpoint needs to POST a list of supplier account records in the Supplier Account Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the supplier accounts were successfully imported or not. Supplier Accounts can only be imported by an organisation if it has enough trading tokens to cover the costs of the supplier accounts data import. See Trading Tokens and Pricing for more details.

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

HTTP Request Raw Example:

Below is an example Supplier Accounts Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the sales representative data. See API Native Programming Libraries.
• Purchaser records may need to be imported before supplier account records to ensure that supplier accounts can be assigned to purchasers, if purchasers are required to be used.
• Assign people (employees, people who purchaser) to Purchaser records to allow them to procure and create purchase orders against the supplier accounts, as well as approve these orders being procured against supplier organisations.
• Price Level records will need to be imported before supplier account records to price levels to be assigned to the supplier accounts. A price level may specify where its pricing was determined based on cost of purchasing from a supplier.
• Supplier accounts must be imported to be able to use the Order Procurement processes in the platform to allow the organisation's purchase orders to be sent to the connected supplier organisation and turned turned into the supplier's sales orders.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import data. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of surcharges into the SQUIZZ.com platform. Each surcharge defines an extra charge that may be applied to sales orders and invoices, based on certain rules being met by the customer when buying products. For example an organisation may define a "Credit Card" surcharge that gets applied when a customer buys products off the organisation and pays for the order with a credit card. Another example is that an organisation may define a "Freight" surcharge that gets calculated at different prices depending on where a customer wants ordered goods to be delivered to. Once surcharges are imported by an organisation into the platform they can be then be set within sales order rules to control when they should be applied to sales orders based on specified conditions being met. Additionally surcharges can be applied to invoice payments being made to cover costs for credit card payments.

The endpoint needs to POST a list of surcharge records in the Surcharge Ecommerce Standards Document(ESD) JSON data format. The endpoint will return an general Ecommerce Standards Document in the JSON data format that indicates if the surcharges were successfully imported or not. Surcharges can only be imported by an organisation if it has enough trading tokens to covert the costs of the surcharge data import. See Trading Tokens and Pricing for more details.

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

HTTP Request Raw Example:

Below is an example Surcharge Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the payment type data. See API Native Programming Libraries.
• Typically surcharge data only needs to be imported by organisations when a new type of surcharge needs to be applied by an organisation.
• Surcharges need to be imported before any Sales Order Rules can be set up that apply a surcharge.
• Surcharges need to be imported before any invoice credit card payments can be set up where a credit card surcharge needs to be applied.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.

The Import Organisation Data endpoint can be called by an organisation to import a list of taxcodes into the SQUIZZ.com platform. Each taxcode record specifies one kind of tax (such as Goods and Services (GST), Value Added Tax (VAT), Sales Tax, and many others) and the percentage amount that the tax may apply to products being sold or purchased. Taxcodes are required to be imported against an organisation before any product data to ensure that products have the correct taxcode assigned to them. Taxcodes may also be required to be imported when importing invoices from suppliers back into an organisation's own business system. Note that multiple taxcodes may be applied to single order/invoice lines (such as for countries like USA where both federal and state based taxes apply).

The endpoint needs to POST a list of taxcode records in the Taxcode Ecommerce Standards Document(ESD) JSON data format. The endpoint will return a general Ecommerce Standards Document in the JSON data format that indicates if the taxcodes were successfully imported or not. Taxcodes can only be imported by an organisation if it has enough trading tokens to covert the costs of the taxcodes data import. See Trading Tokens and Pricing for more details.

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

HTTP Request Raw Example:

Below is an example Taxcode Document being imported by the API endpoint.

HTTP Response Example:

Below is an example Document returned by the API endpoint. resultStatus 1 indicates a successful response

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 import the taxcode data. See API Native Programming Libraries.
• Typically taxcode data only needs to be imported by organisations at the start of a new financial year, or when governments change tax laws and regulations.
• In the request use the config object's dataFields attribute to list the fields that should be updated for existing records previously imported. Any fields not in this list will be ignored from being updated, or have data saved against.
• Look at the list of result_codes at the top of this document to see how the different errors could be returned by this endpoint.
• Note that there are trading token costs to call the endpoint and import. For more details on costs see Trading Tokens and Pricing for more details.