Expose Data Page to External Consumers – Recommended Approach?
Hello Community,
I need to expose a Pega service that allows external consumers to fetch information from a data table. I already have Data Pages configured that retrieve the data based on input parameters, so I’m looking for the most efficient and future-proof way to expose this for external use.
Approach I’m Considering
-
Using Pega’s API (DX API) to expose the Data Page directly, as the retrieval logic already exists.
-
creating a wrapper class/activity to centralize access control and whitelisting logic,so that only specific Data Pages can be accessed and not all datapages from the application, returning controlled error messages for unauthorized calls.
My Concerns
-
API choice: For this type of use case, is it recommended to use DX API ?
-
Rule stability: Since many Pega API rules (including DX API) are internal/final, there’s a risk that future Pega updates could change request/response structures and break consumer integrations.
-
Best practice: Is it good practice to expose Data Pages directly, or should I build a dedicated service layer for consumers?
Questions for the Community
-
Has anyone implemented a similar pattern in a production environment?
Hello Community,
I need to expose a Pega service that allows external consumers to fetch information from a data table. I already have Data Pages configured that retrieve the data based on input parameters, so I’m looking for the most efficient and future-proof way to expose this for external use.
Approach I’m Considering
-
Using Pega’s API (DX API) to expose the Data Page directly, as the retrieval logic already exists.
-
creating a wrapper class/activity to centralize access control and whitelisting logic,so that only specific Data Pages can be accessed and not all datapages from the application, returning controlled error messages for unauthorized calls.
My Concerns
-
API choice: For this type of use case, is it recommended to use DX API ?
-
Rule stability: Since many Pega API rules (including DX API) are internal/final, there’s a risk that future Pega updates could change request/response structures and break consumer integrations.
-
Best practice: Is it good practice to expose Data Pages directly, or should I build a dedicated service layer for consumers?
Questions for the Community
-
Has anyone implemented a similar pattern in a production environment?
-
Are there any upgrade or compatibility risks when exposing Data Pages directly via Pega API?
-
Would creating a custom REST service with explicit request/response be a more stable long-term solution, even though it requires additional effort?
Any guidance, best practices, or real-world experience would be greatly appreciated.
HCA Healthcare
US
@Sourabh
You generally should not expose a Data Page directly via DX API for this, even if it looks convenient, because DX APIs are meant for UI/channel rendering and their contracts can change between Pega versions. A better pattern is to create a dedicated REST service (or service case API) that takes clear input parameters and calls your existing Data Page or a small wrapper activity. In that wrapper, centralize your security, whitelisting of which Data Pages can be used, and any business validation so consumers never see internal class names or technical errors. Design a simple, versioned response structure (v1, v2, etc.) so you can upgrade Pega or change internals without breaking external clients. Keep the Data Page as your internal “single source of truth” for the query logic, and let the REST layer just translate request → Data Page parameters → response. Use standard Pega auth (OAuth2/JWT/basic as allowed) plus role-based access to lock down the service. Document allowed parameters, limits, and error codes so consumers don’t rely on internal Pega messages. This approach is slightly more work up front, but is safer for upgrades, easier to test, and much more stable in production.