API reference for endpoints that perform package optimization

This section contains all of the API references for endpoints that operate with package optimization.
These are endpoints that will perform package optimization and return recommended package(s) if possible.
We have split it into several sub-pages which provide some grouping of the endpoints.
If you have any questions, don't hesitate to reach out to .

Endpoints

Pre- and Post-Payment Optimization API reference

Here you can find information about the pre- or post-payment endpoints.


Pre-payment
Post-payment



Process
The pre-payment endpoint always checks and validates that the provided product data is correct and usable
before continuing.
Incase the validation fails, the endpoint returns a 400 for failing
product validation or a 500 for any internal error that may have occurred.
Using the product data Skrym optimizes the packing of the products and splits the products into multiple packages if needed.



Basic
The post-payment endpoint always checks and validates that the provided order and product data is correct and usable
before continuing.
Incase the validation fails, the endpoint returns a 400 for failing
product validation or a 500 for any internal error that may have occurred.
Using the product data Skrym optimizes the packing of the products and splits the products into multiple packages if needed.

  You can re-trigger the optimization by using the same ID. This will override
  the old result which will affect some statistics and analytics.

Advanced
Skrym fetches the available transport methods and matches them to the chosen transport method for
the calling retailer. Skrym then calculates a route between the given sender and receiver using the transport terminals available, resulting in a route and a transportation distance.
If the call fails at this point Skrym replies with a partially successful result containing just the package recommendation.
The transport distance, optimized package(s) and vehicle selection data are used to calculate the emissions of
the given route for each package(s) in the order.
Using the transport agreement, package information and the chosen transport method, shipping cost including additional fees and penalty fees are calculated.
The transport method is validated to ensure that delivery is possible through the chosen means.





Pre- vs Post-payment

API reference for endpoints that can handle plastic bags

The endpoints on this page can handle a plastic bag package, which we have flagged as slightly special due to the difficulty of handling it.
Optimizing regular and bagable products together
While working with a company involved with pharmaceutical products, we have discovered a need to pack certain products into plastic bags.
If you find yourself in similar situation, you can use the following endpoint:

This endpoint will perform 2-phased optimization, where it will firstly pack the pharmaceutical (or rxProducts) products into plastic bags, and then pack those plastic bags together with any remaining regularProducts into the most optimal package.
Optimizing only baggable products
In case you only need to pack products into a plastic bag, you can use the following endpoint.
Calling core.CalculateOptimalPharmacyPackage will also work, but this endpoint is simpler in the sense that it will not register the call as an order nor will it store the optimization result on our side.


Plastic bags

For various use-cases, we have developed several endpoints that you can freely use.
Optimizing with dimensions
If you have onboarded your products with us, and you find that either their dimensions are changing, you can optimize with the following endpoint which will automatically update the dimensions of the products according to what you have entered in the request.

This endpoint should be used with caution as it will affect the product data on our side, but it can be a powerfull tool for some use-cases.