POST v3/inboundPackingSlips

POST 
/v3/inboundPackingSlips

Announce goods that are on their way to a Paxon warehouse.

Using this endpoint it is possible to create a new inboundPackingSlip for an inbound that is to be expected in one of the warehouses of Paxon. Note that an inboundPackingSlip and its related inboundPackingSlipItems can be created in one invocation by making use of the included relationship as shown in the example request body.

Limitations of POST /v3/inboundPackingSlips

• Each inboundPackingSlip must have a unique reference not used before.
• Each sku must be of a product that exists prior to creating the inboundPackingSlip.
• Each sku can occur only once on an inboundPackingSlip, adding multiple inboundPackingSlipItems for the same sku will result in a single inboundPackingSlipItem with the sum of the quantities.
• The quantity must be 1 or larger.
• The warehouseCode provided in the expectedIn must exist and must be a valid warehouse to receive goods in. (For more information contact your account manager).

Request

Responses

201

Upon successful creation of the inboundPackingSlip in the systems, the endpoint returns the inboundPackingSlip with all the IDs set to the assigned values.

400

400 Bad Request

A 400 Bad Request response indicates that the server cannot or will not process the request due to something that is perceived to be a client error (for example, malformed request syntax, invalid request message framing, or deceptive request routing).

The following are common scenarios that may lead to a 400 Bad Request response:

• Malformed syntax, for example when the request does not follow the expected syntax or structure.
• Invalid parameters included or unsupported parameters in the request.
• Missing or incomplete information that is required by the server to process the request successfully
• Request size limitations when the message exceeds the size limits set by the server.
• URL encoding issues, usually for query parameters in the request that contain characters that are not properly encoded.
• Server-side validation failures when the server determines that the request is invalid based on its business logic and business rules. In such cases, the server responds with a 400 error along with additional information explaining the validation failure.

401

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

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

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.

409

409 Conflict

A 409 Conflict response occurs when attempting to perform an action that conflicts with the current state of a resource on the server. It indicates that the requested action cannot be completed due to a conflict between the provided information and the current state of the resource.

415

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.