GET v3/stockmutations
GET/v3/stockMutations
List stock mutations, oldest first, with filters and pagination.
This endpoint allows you to retrieve a list of up to 100 stock mutations at a time, sorted in ascending order by the createdOn attribute. However, this endpoint will only return stock mutations that are less than 7 days old¹. Note that any stock mutations related to shipments or damaged eturns cannot be accessed through this endpoint. Instead, mutations related to shipments must be inferred from the GET v3/shipments endpoint.
Pagination
The endpoint supports pagination to split the large collection of resources into smaller, more manageable chunks or pages. This helps to reduce the response size and to improve performance. The endpoint supports both cursor-based and number-based techniques for pagination, but it is recommended to use cursor-based as this is more performant and reliable due to page-shifting.
- See also this article on pagination.
Filters
The GET v3/stockmutations endpoint supports filtering on the following attributes: createdOn, type and synced. Each of these are explained below. Filters can be used in combination with eachother and with pagination as to allow full access to the desired subset of stockmutations.
Filtering on createdOn
The results returned by this service can be filtered based on the creation date of the stockmutation. To do so make use of the filter[createdOn] parameter in the following manner:
GET {host}/v3/stockmutations?filter[createdOn][lt]={date}will return stockmutations that have been created before the provided date. Stockmutations that have been created on that date are not included in the results.GET {host}/v3/stockmutations?filter[createdOn][gt]={date}will return stockmutations that have been created after the provided date. Stockmutations that were created on that date are not included in the results.GET {host}/v3/stockmutations?filter[createdOn][gt]={date_1}&filter[createdOn][lt]={date_2}will return stockmutations that have created between dates {date_1} and {date_1}. Stockmutations that were created on either date are not included in the results.
Filtering on type
The endpoint allows filtering on one or more stockmutationType values. To filter on stockmutationType use the filter[type] query parameter as follows:
GET {host}/v3/stockmutations?filter[type][in]=RETURNwill return all stockmutations that relate to aRETURN.GET {host}/v3/stockmutations?filter[type][in]=RETURN,PRODUCTIONwill return all stockmutations that belong toRETURNorPRODUCTION.
Filtering on synced (obsolete)
To support legacy stockmutation synchronization, the endpoint allows users to request unsynced or synced stockmutations. Internally a stockmutation is marked as unsynced whenever it is created. To fetch the stockmutations that require synchronization invoke the endpoint as follows:
GET {host}/v3/stockmutations?filter[synced]=falsewill return all stockmutations that have changed since last time these were 'synchronized'. To mark them as synced use the old v2 endpoint.
Example invocations
GET {host}/v3/stockmutationsReturns the 100 oldest stockmutations up to 7 days back. Note that the service has a limit of 7 days. This invokation is equivalent toGET {host}/v3/stockmutations?page[size]=100&page[cursor]=0andGET {host}/v3/stockmutations?page[size]=100&page[number]=1GET {host}/v3/stockmutations?filter[createdOn][gt]=2023-01-01Returns up to 100 stockmutations that were created after 2023-01-01. The stockmutations returned are never older than 7 days, regardless of the date provided in the request.GET {host}/v3/stockmutations?filter[type][in]=INBOUND,PRODUCTIONReturns only stockmutations that are related to inbounds or productionsGET {host}/v3/stockmutations?filter[synced]=falseReturns all stockmutations that haven't been synchronized. This corresponds to the old way of synchronizing information. Note that this feature will be removed when stockmutation WebHooks become available.
Limitations of the GET v3/stockmutations
- No
stockmutationolder than 7 days¹ are returned. - At most 100
stockmutationresources are returned per request, regardless of the value provided in thepage[size]query parameter. - Ordering is by
idof thestockmutationin ascending order. - Users are rate-limited to 1000 requests per hour on this service.
Request
Responses
- 200
- 401
- 403
- 406
- 415
- 429
OK
401 Unauthorized
A 401 Unauthorized response occurs when attempting to access a resource or perform an action that requires authentication, but no valid credentials have been provided. It indicates that the requester is unauthorized to access the requested resource.
The following are common scenarios that may lead to a 401 Unauthorized response:
- Attempting to access a protected API endpoint without providing authentication credentials.
- Providing an invalid or expired authentication token.
- Providing valid authentication credentials, but lacking sufficient privileges to access the requested resource.
- Providing authentication credentials that are valid for a different resource or API endpoint than the one being requested.
403 Forbidden
The HTTP 403 Forbidden client error response status code indicates that the server understood the request but refused to process it. This status is similar to 401 Unauthorized, except that for 403 Forbidden responses, authenticating or re-authenticating makes no difference. The request failure is tied to application logic, such as insufficient permissions to a resource or action.
406 Not Acceptable
A 406 Not Acceptable response occurs when the server cannot provide a response that matches the client's requested format or content language for the requested resource. For instance, if a client sends an Accept header of text/html to an API endpoint that only supports application/json responses, the server would respond with a 406 Not Acceptable status code. This type of response is a required response for JSON:API compatible endpoints.
415 Unsupported Media Type
A 415 Unsupported Media Type response occurs when the server cannot process the request because the media type specified in the request is not supported for the requested resource. For example, if a client sends a request with a Content-Type header of application/pdf to an API endpoint that only supports application/json (the only valid media type for JSON:API), the server would respond with a 415 Unsupported Media Type status code. This type of error-response is a required for JSON:API compatible endpoints.
429 Too Many Requests
The request could not be completed because of a rate limit violation.