Migration Considerations
Before you begin, Check Feature Compatibility for using the standard cart APIs.
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 |
To learn how to use cart documents, see Use Cart Documents.
To learn how to use Attribute-Based Pricing, see Set up Attribute-Based Pricing. For more information, see Attribute-Based Pricing
Context Rules with context mappings having Initialisation Type as Type In and Scope SObject are not supported in Standard DC and Cart APIs.
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:
The GetCartItems API still has the same behavior in Standard CPQ as in Classic CPQ for backward compatibility.
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.