To use the Configure, Price, Quote (CPQ) functionality through APIs, you may choose to implement either the Cart APIs or Standard Cart APIs.
Cart APIs
Industries CPQ's Cart-based APIs enable client application users to shop for and order products and services. The Cart-Based APIs and their remote methods provide a layer of abstraction between client application development and the configuration of the underlying CPQ logic. Users can access and manipulate the quote, order, and cart data using the industries Configure, Price, Quote (CPQ) APIs.
For Cart-based REST API reference information, see Industries Configure, Price, Quote Web APIs v2 Documentation.
Standard Cart APIs
Standard cart APIs are the next-generation version of the cart-based APIs introduced in Summer '23. These APIs use standard Salesforce libraries, Scale Cache for optimized processing, and revamped pricing and validation methods to reduce the number of SOQL queries and DML operations. These improvements have significantly enhanced API performance.
See Standard Cart APIs.
Factors for Considering Cart APIs and Standard Cart APIs
You are required to consider various factors when choosing between Cart APIs and Standard Cart APIs.
New customers can review the list of APIs supported on Cart APIs and Standard Cart APIs to determine the best fit for their use cases.
Existing customers can:
-
Review the list of APIs supported on Cart APIs and Standard Cart APIs to determine the best fit for their use cases.
-
Check if the APIs you are looking to use are available on your current version. Else, you need to upgrade to the latest version. See Standard Cart APIs.
-
Review the documentation on how to enable Standard Cart APIs and start using it. See Enable the Standard Cart APIs.
-
Review the documentation on the migration consideration required to adopt Standard Cart APIs. See Migration Considerations.
-
Review the migration scenarios section to better understand the benefits of using Standard Cart APIs for your use case.
Cart APIs vs Standard Cart APIs
Standard Cart APIs use the same REST resource family and remote method names as Cart APIs (Classic). Enabling Standard Cart APIs changes the execution path for the APIs listed in Standard Cart APIs. Those APIs run on Salesforce core with Scale Cache. Cart APIs that are not on that list continue to run on managed-package Apex.
| Area | Cart APIs (Classic) | Standard Cart APIs |
|---|---|---|
| Engine | Managed-package Apex libraries, Platform Cache | Salesforce core libraries, Scale Cache, and CachedAPIResponse__c compiled data |
| Governor limits | CPU time, SOQL (100 synchronous / 200 asynchronous), and heap size (6 MB synchronous / 12 MB asynchronous) apply to cart processing | Heavy pricing, validation, and cart logic runs on core, which reduces Apex CPU, SOQL, and heap pressure for supported APIs |
| Bundle and line-item capacity | Smaller out-of-the-box bundle sizes | Larger bundle sizes and higher line-item counts for supported transactions. See Application Constraints |
| Customization model | Line-item sObjects and PricingPlanService context |
CpqCartDocument in the input map, Cpq interfaces, and field mappers for custom fields. See Use CpqCartDocument |
| JSONAttribute v2 | Optional | Required. See Enable the JSONAttribute V2 Schema |
Response actions node |
Populates both remote and rest nodes |
Populates only the protocol you invoked |
| Custom fields in the response | Field Settings / CPQV2 field settings | Pass the fields parameter. Field Settings apply only to getCarts and GetCartsItems |
| Currency and pricing values | Integer values are often accepted | Double is required (for example, 0 must be 0.0) |
Not every Classic Cart API is a Standard Cart API. Review Standard Cart APIs for the supported list, and Known Limitations before you enable the feature.
Benefits of Standard Cart APIs
Here's the table that highlights benefits of transitioning from Cart APIs to Standard APIs.
| Scenario | Standard Cart APIs vs Cart APIs |
|---|---|
| Your typical cart operations involve creating Quotes or Orders with large line items | Standard Cart APIs can support larger Bundle Sizes ( Number of OLI) compared to Cart APIs. Review the Application Constraints for more details. |
| Time taken to perform cart operations | Standard Cart APIs are faster for cart based operations such as config, price, add, update as compared to Cart APIs. <br>Standard cart-based APIs use standard Salesforce libraries to process the cart operation logic, which reduces the time taken for each call. <br>Performance / response time is based on complexity of the Product Catalog, results may vary based on factors such as customizations, rules, and so on. |
| Complex rules and pricing hit Apex CPU, SOQL, or heap limits | Standard Cart APIs move pricing and validation onto core and Scale Cache, which reduces JSON serialize/deserialize cost and database round trips on supported APIs. Custom hooks, rules, and catalog complexity still affect response time. |
| You need Multi-Edit, Cart Document, or Relies On attribute propagation | Multi-Edit Cart Line Items, CpqCartDocument, and out-of-the-box Relies On attribute propagation are available when Standard Cart APIs are enabled. Relies On attribute propagation does not run if Standard Cart APIs are disabled. |
Base URI Structure and Namespaces
All Cart-Based API requests use the following base URI:
https://{instance}.salesforce.com/services/apexrest/{namespace}
Where:
-
instance identifies the Salesforce instance that hosts your Salesforce organization (org)
-
namespace identifies the app package, such as vlocity_cmt
API Authentication and Security
Apex REST supports two authentication mechanisms: OAuth 2.0 or Session ID. Usually, you use Session ID authentication only for testing purposes during development. OAuth 2.0 is recommended. For more information, see the following topics in the Force.com REST API Developer Guide:
API Limits
To maintain optimum performance and ensure that the Force.com API is available to all customers, Salesforce imposes two types of API limits: concurrent API request limits and total API request limits. When a call exceeds a request limit, an error is returned. The actual limit depends on the type of Salesforce edition org you are using, the number of user licenses you have purchased, and the number of additional API calls you may have purchased.
Total API request limits govern the total API requests (or calls) per 24-hour period for an org. Vlocity Omnichannel Web APIs are designed to provide more functionality and data with each request to minimize the number of calls required per user per hour. However, the client application determines the number of API calls.
For more information about API limits, see API Limits in the Salesforce Developer Limits Quick Reference.
Other limits apply. Vlocity Omnichannel Web APIs are based on Apex REST. Calls to these APIs count against the deploying company’s API governor limits. All standard Apex governor limits apply to Apex REST classes. For example, the maximum request or response size is 6 MB for synchronous Apex or 12 MB for asynchronous Apex. For more information, see Execution Governors and Limits in the Force.com Apex Code Developer Guide.
API Response Status Codes
Apex REST APIs return the standard HTTP response status codes. For more information, see Apex Rest Methods, “Response Status Codes,” in the Force.com Apex Code Developer Guide.