The API guides in this section only apply to implementations being upgraded from a previous version of Kibo Order Management. Clients who do not have an existing instance of OMS should not use these guides.
Clients upgrading from an existing instance should only use the below guides and not those listed in the left-hand navigation menu, which are different APIs for new clients.
To support backwards compatibility, a translation layer exists within the Unified Commerce Platform (UCP) to accept API requests that were used for a previous version of OMS. This translation converts any applicable parameter names and data to the Unified Commerce format, allowing existing OMS API requests to be successful with minimal changes on the client’s end. The only changes that are always required are new authentication headers and base API endpoints, which must be updated in order to send the calls to the new platform.
Refer to the other guides in this section if you are upgrading to the Unified Commerce Platform, as they detail new authentication steps, request endpoints, and the request parameters that you should be familiar with from the previous version of OMS.
Making Changes to Your Integration
The translation layer has been tailored to match your implementation in the previous version of the OMS platform. Making changes to your integration, such as adding features that are supported by the UCP platform, will sometimes require Kibo Engineering to make code changes to the translation layer in order to support them.
Some changes are safe and possible for Kibo to make, while others are not. Contact your Kibo representative about any possible changes so that they may determine the scope before the changes are sent to Engineering to be approved and prioritized against existing commitments. Changes that are not possible or safe to make in the translation layer must be developed outside of it, meaning you will need to switch to the native UCP APIs and forgo all of the translated APIs, notifications, and transaction logs (TLogs).
Kibo recommends moving to the native UCP APIs and events as your roadmap allows, in order to take advantage of the features that UCP has to offer. This includes moving to API-based transactional data gathering and away from TLogs, as new UCP features are not compatible with the previous version of TLogs.
Changes That Do Not Require Kibo Engineering
The following changes do not require development by Kibo Engineering:
- Removal or discontinued use of a payment method, fulfillment method, or shipping carrier integration
- Changes to general, location, or location group settings
- Adding a location to an existing location group (if done via API)
- Adding a shipping carrier already supported by UCP
- Adding or modifying Order Routing settings
- Changes to FTP settings (such as inventory and TLogs)
- Changing the order in which payment methods are captured or refunded
- Modifying email templates, packing slips, or fulfiller customizations via theme
Changes That Require Kibo Engineering
The following application code changes require development by Kibo Engineering:
- Adding a credit card, no-operation, or gift card payment method not already supported by your integration
- Adding a carrier not already supported by Kibo UCP
The following changes cannot be made in the translation layer. To use these features, you must switch to the native UCP APIs and events:
- Adding a fulfillment method not supported by the previous version of OMS (such as Curbside)
- Adding third-party payment methods not in the credit card, no-operation, or gift card categories
- New notifications not supported by the previous version of OMS
- New fulfillment steps in a BPM
- Most new fulfillment-related features added to UCP (such as splitting packages via API)
- Adding new catalogs, sites, or tenants that did not exist in the previous version of OMS
- Re-platforming your front-end ecommerce site