Migration Considerations

Before you begin, Check Feature Compatibility for using the standard cart APIs.

Interfaces and Implementations

Following table lists supported interfaces and implementation class names.

Interface Name (in Cart APIs)	Supported in Cart APIs	Supported with Standard Cart APIs	Interface Name (when Standard Cart APIs are enabled)	Active Implementation Class Name
PricingInterface	Y	Y	CpqPricing	CpqPricingOrchestratorService
ProductValidationInterface	Y	Y	CpqValidation	CpqValidationService
TightestMatchInterface	Y	Y	CpqTightestMatch	CpqTightestMatchPLEService
TimePolicyInterface	Y	Y	CpqTimePolicy	CpqTimePolicyService
CpqAppHandlerHook	Y	Y	CpqAppHandlerHook
PricingElementServiceImplementationH PricingPlanServiceHook CustomPricingElementServiceImplHook	Y	Y	CpqPricingHook	Custom Hook Implementation Name
ContextRuleService	Y	Y	CpqContextRule	CpqContextRuleService
DefaultPricingVariableCalcImplementaInterface	Y	Y	CpqPricingVariableCalc	CpqPricingVariableCalcService
			CartResponse	CartResponseService
PricingSelector	Y	N
CtxRulesPriceListsOpen	Y	Y	CpqPricingEligibility	CpqPricingEligibilityService

If a product is marked as IsOrderable__c=false, Advanced rules and PCPs will not work correctly in Standard Cart APIs. Instead, configure the Product with IsOrderable__c=true and filter the Products in Availability and Eligibility Interface Implementations.
When EPC job is run without selecting any PriceList, it caches the PCP data for products marked IsOrderable__c=false. Then PCP rules will work for all the products.
To return a custom field in a Cart API response, the field must be explicitly included in the fields parameter, either in the API URL parameters or the request body. The CPQV2 field settings approach for controlling response fields is only supported in the getCarts API. It does not apply to other Standard Cart APIs.
Standard Cart APIs enforce Double as the required data type for the pricing or currency-related fields. Users must update such Integer values in their custom code to Double type (for example, 0 → 0.0) as Integer types might cause type mismatch exceptions at the runtime. All future implementations must use Double type for the currency related fields.

Important

Cart Documents

To learn how to use cart documents, see Use Cart Documents.

Attribute-Based Pricing

To learn how to use Attribute-Based Pricing, see Set up Attribute-Based Pricing. For more information, see Attribute-Based Pricing

Context Mappings

Context Rules with context mappings having Initialisation Type as Type In and Scope SObject are not supported in Standard DC and Cart APIs.

Changes to Response

Messages Node in postCartItems API (Standard Cart API)

When a postCartItems API adds a product with configuration issues to the cart, the messages node in the Standard Cart API response shows both success and error messages. For example, if a required attribute lacks a default value and the product is still added, the messages node in response includes both the success and the error messages. Here’s a sample messages node in the postCartItems API response:

1{"severity": "INFO","message": "Successfully added.","code": "150"}
2{"severity":"ERROR","message":"Required attribute missing for ProdWithTextAttr.", "code":"204","messageId":"...","bundleId":"..."}

The GetCartItems API still has the same behavior in Standard CPQ as in Classic CPQ for backward compatibility.

Note

Actions Node

The actions node consists of two main protocols to invoke CPQ APIs, and there are separate nodes for each protocol: remote and rest.

In Classic CPQ, whether the API is invoked via REST or as a Remote call, it populates both remote and rest nodes.

In Standard CPQ, the API populates actions node based on the protocol.

If a REST call is made, the API populates the rest action node in the response.
If a Remote call is made, the API populates the remote action node in response.