Migrating from previous version of Delivery Checkout API.
If you have already integrated with our old Delivery Checkout (known as SIW API as well), the new API can work as a drop-in replacement to a certain extent. Shipping selector embedded on your checkout page and all frontend-related integration parts remain the same.
Integration with Delivery Checkout API requires minor changes for handling the response bodies structure. The response payload resembles the payload from SIW API. Some new fields were introduced though and naming of top-level
result field was changed to
Benefits of migration
You should migrate to new Delivery Checkout API in order to benefit from new features, such as address form, split shipments handling or marketplaces handling.
The following checklist aims to simplify the process of migration to our new Delivery Checkout API.
- Get familiar with the new API (you will quickly notice that it is not different from the Swagger of SIW API).
- Decide whether you want to handle split shipments, if so - decide the split condition that should be applied to cart items.
- Contact Ingrid Support Team here. We will guide you through the process of setting up the split condition logic.
delivery_groupsfield from the response payloads in your integration - if you are using single cart setting, your
delivery_groupsfield will contain only one delivery group (a single delivery group is similar to result from SIW API).
- Decide when you want to fetch sessions with fresh shipping options and when session states with possibly stale shipping options (by expiration time slots) are acceptable. Depending on the decision, use
session.getrespectively. To learn more about differences between those two endpoints, consult the