What’s the difference between Traditional and DXAPI-as i am seeing a lot of articles but they don’t make any sense.
A traditional API is intended a business/service API that exchanges business data and triggers processing, while DX API is intended as a UI experience API that exposes case and assignment state so an external front end can render and drive the Pega experience.
- Traditional API: transaction-oriented, usually focused on doing an action or moving data between systems.
- DX API: experience-oriented, focused on presenting the current case/assignment state, actions, views, and data needed for the UI
Traditional APIs (Service / Integration APIs)
-
Transaction-oriented
-
Designed for system-to-system interaction
-
You explicitly call an action (create case, update data, trigger a process)
-
Payloads are business-data-centric
-
You control the flow from the client side
Think: “Do this operation.”
DX API (Digital Experience API)
-
Experience-oriented
-
Designed for UI/channel integration (React, Angular, mobile apps, portals)
-
Returns case + assignment state, UI metadata (views, fields, actions)
-
Drives the UI dynamically based on Pega’s configuration
-
Client acts more like a renderer of Pega-driven experienceThe key conceptual difference
-
Traditional API → You orchestrate Pega
-
DX API → Pega orchestrates the experience, you render it
-
Please check the article which we have published it will show the key difference between v1 and v2 api.
Please find the details below,
| Feature | DX API V1 | DX API V2 |
|---|---|---|
| UI Architecture | Section & Harness-based (traditional UI) | View-based authoring (React-powered Constellation) |
| Response Data | All values returned as strings | Returns type values (Boolean, Integer, Date, etc.) |
| Chattiness | High – multiple API calls needed for screen flows (Create case → Get assignment → Action → Submit) | Low – reduced calls; e.g., PATCH response includes next view, minimizing round trips |
| Performance | Slower response; more HTTP overhead | Improved rendering speed and fewer HTTP requests |
| Supported Rules | Harness, Sections (must be autogenerated) | Views (Constellation UI), modular UI components |
| UI Technology | Works with Theme-Cosmos & traditional UI | Designed for Constellation (React-based fully modern architecture) |
| Metadata Support | Limited | Rich metadata for custom front-end rendering and channel independence |
| Sessions | Requires sticky session in some scenarios | Stateless → No sticky session required |
| Extensibility | Limited for custom components | Easier extensibility; supports personalization, enhanced social collaboration features (Followers, Pulse) |
| End-point Categories | Case, Assignment basic calls | Expanded endpoints: Data Views, Social (mentions, messages), Attachments, Personalization, Audit |
| Best Practice Direction | Deprecated for new builds; only for legacy apps | Recommended for all new apps for future-proofing |