What's the difference between Traditional and DXAPI

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.

(4) DX API: V1 vs V2 | LinkedIn

good @Gunasekaran_Baskaran

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