Hey @TanyaS58
And that makes it three questions answered today—clearly we’re on a Pega Q&A sprint 
The short answer would be No, I don’t think we can add or dynamically change additional resource path parameters of a Connect‑REST rule using a DSS via Global Resource Settings. Global Resource Settings + DSS are used to externalize environment‑specific values such as:
Base URL / endpoint override
Authentication details
Request headers
Timeouts, keystore references
The resource path itself is part of the Connect‑REST rule definition and is not dynamically extendable via DSS. To explain in simple words: DSS can override where the service is called, but not how the resource path is structured.
/appointments/{appointmentId}/v1/... vs /v2/...), define separate rules and select them conditionally.DSS cannot add or alter Connect‑REST resource path segments
DSS can externalize endpoint/base URL and related settings
Dynamic parts of the path must be handled via rule parameters, not DSS
This is expected behavior by design in Pega.
Thanks,
Roshan Raj A K
Thanks for such a detailed explaination @RoshanRajAK1 ,so if we just add the resource path as a parameter in the url itself then we can use DSS and provide the entire url right?cause in production how come we will add more resource paths,if the requirement comes up suddenly to do so.
The best practice is to leverage Application Settings for Connector rule. Application Settings for Connect REST rules enable managing environment-specific configurations—like endpoint URLs, authentication profiles, or timeouts—without updating rules during migration. They act as a robust alternative to Dynamic System Settings (DSS), allowing different values for sandbox, staging, and production within a single application.
Hey @TanyaS58 - If the concern is around multiple resource path parameters that keep changing across environments, Use of Application Setting will be the best choice.
Instead of hardcoding your URL within the Connect-REST Rule configuration, define an Application setting rule and pass the different Resource URLs configured for each environment within the rule.
Else, If you have multiple resource URLs for a single Connect-REST that might change in the future only in production, Just define it as a Query Parameter at runtime instead, This allows you to just include the additional resource path while keep the Base URL consistent across all environment.
This keeps the Connect‑REST configuration generic while allowing flexibility to add or change resource paths dynamically as new requirements arise.
So in short:
Frequent or unpredictable URL changes → Use Application Settings
Stable base URL with variable resource paths → Pass dynamically at runtime as Query String Parameters
Let me know if this helps
Thanks,
Roshan Raj A K
Hi @RameshSangili and @RoshanRajAK1 actually how can we add 100’s of such resource path parameters,like app settings and DSS wont be able to coupe up with so many of them right?
Sorry, I don’t understand your question.
Hi @RameshSangili Attaching a screenshot:now here you can see we have resource parameter added now suppose in prod we need to add 100’s of such resource path so any DSS or app setting will not suffice right so how to do that in prod?
Hi @TanyaS58 : Lets take a step back to understand the use case itself. You are connecting to another system using REST Protocol. In this case, does the external system API contract has hundreds of path segments? If yes, i would generally say that the API design is poor.
Back to your question on how to add these in PROD. This is a invalid scenario because any change in the API contract including the resource path should be considered as a change and the corresponding change should start from DEV. If this is only for the values passed to the pre-defined resource paths, then you should define the resource path initially and map the values dynamically.
If you really want to make it dynamic. Try the frame the End point URL dynamically and pass it in the end point URL parameter in the connect rest method call ( i haven’t tried this. just sharing to try out). Please note this is not recommended to frame URL dynamically.
Thanks.
Hey @TanyaS58 - Based on the screenshot, I can see that the resource path includes a parameter ({TestServicePackage}), which is a good approach to avoid hardcoding values.
However, to address your main concern — managing 100+ resource paths in production — relying on DSS or static configuration alone will not scale well.
A better approach would be:
Parameterize the resource path as much as possible, similar to what is already done with {TestServicePackage}if you are passing query string parameters
Use a single Connect REST rule, and dynamically construct parts of the URL using clipboard/data page values
Externalize variable parts (like base URLs or service identifiers) using:
Data Pages (recommended) backed by a DB table or system of record
or Environment-specific configuration (Application setting) only for base-level differences
If you truly have completely different endpoints (not just parameters), then:
Maintain a configuration table (e.g., integration mapping)
Fetch the correct endpoint at runtime and set it dynamically in the Connect REST
Just to confirm the design direction —
Are these 100 resource paths variations of the same service (with different parameters), or completely different endpoints across multiple external systems?
That distinction will determine whether parameterization alone is sufficient or if a configuration-driven approach is required.
Let me know if this answers your query and do provide a confirmation on the query above to better understand the scenario
Thanks,
Roshan Raj A K
Hi @RoshanRajAK1 Are these 100 resource paths variations of the same service (with different parameters), or completely different endpoints across multiple external systems?-these resource path belongs to the same service
Hi @TanyaS58
Thanks for confirming — that helps. Since all resource paths belong to the same service, you don’t need to manage them separately.
Suggested Approach
Parameterize the resource path
Break it into dynamic parts (path/query params) and pass values at runtime (clipboard / data page / activity).
Example: /service/{entity}/{operation}?type={type}&status={status}
Use a single Connect REST rule
Dynamically populate path and query parameters instead of creating multiple rules.
Use Data Pages if variations are complex
Maintain a config table (entity, operation, defaults, etc.) and fetch values at runtime to drive the request.
Externalize only the base URL
Keep it in app settings; handle everything else dynamically.
Since these are variations of the same service, parameterization + (optional) config-driven approach is sufficient — no need for 100 separate resource paths.
Thanks,
Roshan Raj A K
Hi @RoshanRajAK1 you are saying that the URL I should pass should be calling a data page with parameters?and its source should be lookup so that at run time we can pass the parameters?
Hey @TanyaS58
Yes—what I mean is to store all your URLs in a data table configuration and create a parameterized data page. You can then invoke this parameterized data page within your request data transform of your Connect-REST rule to dynamically construct the URL at runtime. This constructed URL can be used in your Connect-REST rule, which will return the response based on the specific service being invoked during execution. This approach will work in the case of complex Variations
We had a similar usecase where we worked on using this approach, Let me know if this works for you
Thanks,
Roshan Raj A K
