Your requests are probably missing the login (Bearer)tokens. Or the token you are sending is expired. Use the OAuth2-endpoint /connect/token with you client credentials to generate a (new) token

Double check the Id's and storeId. The requested object might only be available for different stores. Your API key is also linked to a store, so you can't access stores which are on a higher store-level.

In some cases error details are provided which you can use to prevent the error. Otherwise contact us, and sent us the errorId which is in the response and the request body if it is a PUT, PATCH or POST request.

ASPOS has a store tree structure which is used for many different resources. This tree structure has at least 2 levels and determines which data is used when executing requests. An example store tree looks like:

• M001 (Headquarter)
  • M010
    • M011 (Physical Store A)
    • M012 (Physical Store B)
    • M013 (Physical Store C)
  • M020
    • M021 (Webshop A)
    • M022 (Webshop B)

Data, like the selling price on the product resource, could be different for all stores but if it's not set on a specific store it will take the value from the store above until it finds a value.
Example:
If the selling price is set to 10 on M001 and nowhere else. Retrieving product from M011 will return 10.
If the selling price is set to 10 on M001 and 15 on M010 and nowhere else. Retrieving product from M011 will return 15.
If the selling price is set to 10 on M001 and 15 on M010 and 20 on M012 and nowhere else. Retrieving product from M011 will still return 15, because M012 is on the same level and does not affect M011.

If M010 has a value and you would change the selling price only on M001 to 20, this will not affect M011. Because the first value it will find would be on M010. This is an important thing to keep in mind, especially when you change store level data. You should think about when you should overwrite the setting on all stores, and when you should only change a value on one specific store.

The 'additionalParameters' on some contracts are used in the POST and PATCH endpoints for that resource. They provide additional functions when creating or updating a resource. These parameters are only used there and cannot be expanded on a GET request. The documentation will give additional information about the different parameters and how they are used.

You should manage the content of a shoppingcard yourself, in a cookie/session/database. If a user changes the content of the shoppingcart do a request to POST api/carts/Calculate The body should contain all products(including kititems) with quantities. The response contains the given products with the current price, including discounts which can be used to display the totalprice and/or cart-lines.

If the customer collected all the products he/she wants you can create a PreOrder POST api/customer-orders This ensures that the prices the customer saw are saved, and can not change while the customer is still finishing the payment. To add payments use POST api/customer-order-payments If you need a list of available payment methods use GET api/payment-types After the customer completed the complete order amount, you can commit the order by using POST api/customer-orders/{id}/Commit If all succeeded, you can let the customer know the order is finished. Further processing happens in the backoffice system.

Coupons are discount codes that can be linked to a specific discount. CouponIds are actually productIds of products with type 'ProductVoucher', and optionally in the product group "Coupons". The ScanCode of the product can be used as a coupon-code, you should convert the ScanCode to productId in the client via GET api/products/scancode/{scancode} endpoint.

A product has multiple prices that can be retrieved, which are used for different purposes. Not all prices are always available.

• Product.PriceInclTax: Regular selling price including tax
• Product.PriceExclTax: Regular selling price excluding tax
• Product.ListPrice: Recommended selling price, usually given by supplier
• Product.DiscountPrice: Only used when specific productdiscount is active, other discounts could give a better price
• Product.PurchasePrice: Suppliers purchase price
• Product.Discount.PriceInclTax: Selling price including discounts including tax
• Product.Discount.PriceExclTax: Selling price including discounts excluding tax
• Product-pricings: Used for temporary price changes of different types

In most cases the Product.Discount.PriceInclTax is used for displaying in the webshop. Other prices are for example used to show the customer how much they can save when ordering products now.

A lot of resources can have store specific settings, like customers, brands, discounts, payment methods and product groups. This means a setting can have a different value for store X than for store Y. Updating a store specific setting might therefor not give the desired result, if you expect the new value to be active everywhere.
Before updating a store specific setting it would be best to check on which stores the setting is set first. You can do this with endpoints like: GET api/resource/{id}/store-settings. With the result you can determine on which stores you should change the value, with endpoints like PATCH api/resource/{id}/store-settings/{storeId}.
Some endpoints also support 'additionalParameters' with options to simplify this process. A parameter 'overwriteChildStores':true would result in all settings being overwritten for the given store and all stores on a lower level.

In most cases a specific product is used which represents the delivery costs. This product should be added as an orderline when creating the order. The QuantityDelivered property can be set to make sure this product will not be added to a pickorder later in the order-process.
If the delivery cost amount is variable, you can set the price manually on the orderline. Or multiple products can be created with different costs.

Stock information for a product can be retrieved through GET products/{id}/stock-info or expanding a product with 'StockInfo'.
In some cases, and on test and acceptance environments in most cases, a product does not have stock. In these cases the response is (mostly) empty because default values are not returned.
If you expect the product to have available stock, please have a look in the ASPOS backoffice.
Log in with an account which has access to the store you want to check. Go to 'Producten' -> 'Productbeheer', search for the product you want to check. In the overview you can click the column 'Voorraad'. In the pop-up you can see which stock is available on which store.

The are multiple ways to retrieve products through the REST API.
When you already know the product ids or scan codes you can use the following endpoints: GET products/{id} or based on scancode GET products/scancode/{scancode}
But in most cases, ids or scan codes are not known beforehand. In that case the products you need on your webshop (or other app) should be linked to web nodes.
Web nodes are containers for products. They can be used to categorize your products, or you can simply use 1 web nodes to link all the products you need. Products can be added to multiple web-nodes. They can be managed in the ASPOS backoffice, under 'Instellingen' -> 'Webknopen'.
Products can be added/removed under 'Producten' -> 'Productbeheer', than selecting the products and choosing 'Bulkopties' -> 'Webknopen'
Once linked to web nodes, you can use the following endponts:

• POST api/web-nodes/ProductsSearch Get a list of products based on a search term
• GET api/web-nodes/{id}/products Get a list of all products within a specific web node
• POST api/sync/web-products Get all changes in products since a specific token, so you can store productinformation in your own database.

See the documentation for details about these endpoints.

Email templates are created and managed in the backoffice, under 'Instellingen' -> 'Templates'. They contain the content of an email you can send. In these templates different kind of tags can be used to fill in variable data:

• Table tags are filled in for every record provided, the section is repeated as often as needed.
• Simple tags are only appearing once and are filled in on the spot.

Table tags can be added by using: <!--[BEGINXX]--> and <!--[ENDXX]--> where XX is the name of the tag. Everything between these tags will be repeated for every row provided when creating the email.
Simple tags appear both in table section and individually. For this use <!--[%XX%]--> Where XX is the name of the tag.

Providing data is done with the Mail Create request by filling in TemplateParameters with a key value collection with the name and value. Like {"Firstname":"John", "Lastname":"Doe"}.
This will convert a template like this: Hello <!--[%Firstname%]--> <!--[%Lastname%]--> to Hello John Doe

For TableTags you need to fill in TemplateTableParameters with a object that lists the tags and has a collection of key value object. Like {"ProductLine":[{"ProductNumber":"0000123","Description":"Hammer"},{"ProductNumber":"0000777",""Description":"Screwdriver"}]}
This will convert a template like this: <!--[BEGINProductLine]--> <!--[%ProductNumber%]--> <!--[%Description%]--> <br /> <!--[ENDProductLine]--> to 0000123 Hammer <br />0000777 Screwdriver You can use multiple simple tags and table tags within the same template.

For validating a groupuser you have two options. One is to validate the pincode and retrieve the user object through a POST to api/group-users/ValidatePinCode. The other options is to do a login call and get a token through api/group-users/Login.
With the retrieved token with the groupuser you can do calls that require the groupuser like the StoreJobSession operations. The tokens with groupusers are valid for other services beside this one. The token without the groupuser might not be valid.

Bonus points can be calculated through POST api/carts/Calculate or will be given to a customer when commiting an order: POST api/customer-orders/{id}/Commit
If no bonus points are returned or given to the customer, please check the following things first:

• For POST api/carts/Calculate includeBonusPoints parameter is set to true
• For POST api/customer-orders/{id}/Commit SkipBonusPointMutations parameter is not set to true
• A customerId is given in the request
• The given customer has a valid customer card
• The given customer is linked to a customer group
• The customer group has a bonus program type set
• The given customer has AllowBonusPoints set to true
• The products included in the cart or order are allowed to give bonus points. This can be managed on the product, brand, group or subgroup

The amount ordered is shown in the extensions from the TransactionRecord. In order to get it do the following:
Retrieve the transaction through GET api/transactions/{id} with a expand on Records and a sub expand on Extensions.