To be sure, when you update the url through GUI, it applies to all pega instances for that environment (defined by a single database). How many environments are we talking about here? Seems like a over kill to try to automate unless you have hundreds of environments. BTW, the DASS setting is: pdcconfig/altsoapurl.

You could leverage the /data endpoint of the Pega API, and wire this into your Deployment Manager, Jenkins or other Continuous Deployment pipeline.

The /data API is ultimately a wrapper for running a Data Page. Its intent is for data retrievals, e.g.

/prweb/api/v1/data/D_StartingFlows

... but so long as the Access Group of the user your authenticate to Pega API with has Open and Modify access to the class you were looking to update, you could create a new Data Page that should be able to run an Activity that does an Obj-Open, Obj-Save and Commit on the Dynamic System Setting instance. Then you reference the Data Page in the /data API like the above example. See the Pega API help docs from Dev Studio for examples on how to pass parameters to the Data Page via the /data API.

Assuming you go down this path, you need to be very careful about the access control you grant to this channel. Only your Continuous Deployment orchestrator should be authorized to run this particular Data Page:

1. Apply a Privilege to the Activity of the Data Page;
2. Grant the Privilege to a new Access Role;
3. Add that Access Role to a new Access Group;
4. Create an Operator specific for this privileged operation which is the only Operator configured to use this Access Group.

This Data Page could then be leveraged by your CD pipeline to perform privileged updates to other Dynamic System Settings that hold environment-specific values that your pipeline is best placed to apply.

Please report back your findings if you choose to adopt this.