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<br>PricingPlanServiceHook<br>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 |
important: - 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 supported for the getCarts and GetCartsItems APIs. 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.
Cart Documents
To learn how to use cart documents, see Use Cart Documents.
Product Configuration Procedure (PCP) Execution Order
Product configuration procedure (PCP) rules must run before validation and pricing so that any attribute or line-item changes they make are included in those steps. Treat Standard Cart API behavior as the correct reference implementation.
Standard Cart APIs
In Standard Cart APIs, PCP rules run once, before validation and pricing. Attribute values that PCP rules change are therefore available to the pricing engine.
When you set attribute values from custom code, use setItemAttributes so that PCP rules pick up the new values. See Use CpqCartDocument.
Do not update attributes or line items during the pricing step. Pricing must operate on a stable, finalized set of line-item data.
Classic Cart APIs
In Classic Cart APIs, PCP rules currently execute twice during Add Line Item (postCartItems) operations:
- Once before validation and pricing
- Once during the post-execute hook (after pricing)
The second execution is not the intended behavior:
- Changes made during the post-execute hook are not persisted.
- Modifying line items after pricing has started is not recommended, because pricing should operate on a stable, finalized set of line-item data.
To stop PCP rules from running in the post-execute hook, set both of these values to False in Vlocity CMT Administration → CPQ Configuration Setup:
RunPCPInAddPostExecuteMethodRunPCPInUpdatePostExecuteMethod
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:
{"severity": "INFO","message": "Successfully added.","code": "150"}
{"severity":"ERROR","message":"Required attribute missing for ProdWithTextAttr.", "code":"204","messageId":"...","bundleId":"..."}
note: The GetCartItems API still has the same behavior in Standard CPQ as in Classic CPQ for backward compatibility.
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.