My Products

Migration from v2/SalesOrder to v3/SalesOrders Questions

by erik-kle


Upon a first glance of the POST v3/SalesOrders i find that ShipVia and ShippingTerms is missing. Will the NewSalesOrderCommand be extended with more fields in the coming months? 

Joni Wolff

by Joni Wolff

Hi! We will start working with the shipping and freight fields(ShipVia and ShippingTerms included) the coming weeks, we plan to have this available in start of February.


by erik-kle

Why do you have a fauna of different SalesOrder objects for different endpoints? Isnt it possible to define a domain SalesOrder object, that are used for GET, POST, PUT, instead of NewSalesOrderCommand, SalesOrderDto, SalesOrderListDto etc, that are all a bit different.

Joni Wolff

by Joni Wolff

Hi! We have tried to use the same objects in the places where the request or response are the same.

For example, in GET we have totals on order, which cannot be provided in POST or PATCH, so we want to response only with data which is needed.


by Snuffsis

Would it not make sense that the data that is returned at least looking the same?


A simple example (Endpoint for single SalesOrder):

GET /salesorders/SO/000100

In this request, the Status field is an object that looks like this:

 "status": { 
  "description": "string", 
  "cancelled": true, 
  "hold": true 


But in the request (Endpoint for list of salesOrders):

GET /salesorders

here the status field is a simple string:

 "status": "string", 


I would have assumed that, at the very least, since it's both a GET that the data that is returned looks the same in both endpoints, even if they don't return the exact same amount of data for the whole salesorder


An option to "expand" on attributes, as is possible for the endpoint for a specific salesorder, seems like something that should exist for the list endpoint as well.