How to make HTTP Request base URL dynamic in ISC workflows (external trigger)?

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

I have ISC workflows with HTTP Request actions that call ISC APIs. The Request URL is hardcoded, so updating it is painful. Is there any built‑in variable or action to get the current base URL automatically? If not, what’s the recommended pattern for external‑triggered workflows to pass or derive the base URL?

https://<tenant>.api.identitynow.com
2

ISC external triggers are designed to accept input JSON from outside the platform, and the workflow can reference that payload with JSONPath like $.trigger.baseUrl. The execute-external API explicitly says the caller sends the input data in the request body, so this is the cleanest supported pattern.

If the workflow is only ever used in one tenant, the simpler option is just a workflow variable like:

{
"name": "tenantBaseUrl",
"value": "https://acme.api.identitynow.com"
}

and then:


{{$.defineVariable.tenantBaseUrl}}/v3/identities

But that’s still effectively hardcoded, just centralized.

If you need this to work across multiple tenants/environments, don’t try to “discover” the base URL inside the workflow.

That part isn’t supported directly. Pass it in from the caller, or keep one constant per environment.

3

You need to pass the full URL as a variable to the workflow. But modifying or building the base Url within the workflow body is not supported. The URL must be fully formed before being passed.

Workflows: How to dynamically create request body in HTTP action .

4

Hi @BBR1
Although i am not really fully sure about your requirement but it is possible to dynamically form the URLs or body of the HTTP action. If you have desired variables values populated in above steps then you can use double curly brackets to retrive them, something like this

{{$.hTTPRequest.body.records[0].id}}

You will need to be able to just careful whether you have setting for the body as text or Enter Value in the step.

I hope this helps. If not, please provide your use-case in more detailed manner so we can have a look.

Regards

Vikas.

5

Yes, that works. But I was actually looking for some global variable type of thing. So I just need to upload the same JSON from tenant to tenant without adding an extra key in the request body.

In case that doesn’t work, then the last option is using it as a variable

{{$.trigger.baseUrl}}/v2025/roles
6

Making an API call to this URL

https://tenant.api.identitynow.com/oauth/info

returns the following body and you can read the base URL from here (say using tokenEndpoint) with a define variable to replace /oauth/token`` with ``/

{
    "tenantId": "0f31ab30-1312-4199-a91a-687d57e79541",
    "tenantName": "tenant",
    "authorizeEndpoint": "https://tenant.login.identitynow.com/oauth/authorize",
    "tokenEndpoint": "https://tenant.api.identitynow.com/oauth/token",
    "cloudDomainUrl": "https://tenant.identitynow.com",
    "logoutUrl": "https://tenant.identitynow.com/logout",
    "pod": "se01-useast1",
    "requestUrl": "https://tenant.api.identitynow.com/oauth/info",
    "userInfoEndpoint": "https://tenant.api.identitynow.com/oauth/userinfo",
    "claimsInfoEndpoint": "https://tenant.api.identitynow.com/oauth/claimsinfo",
    "issuer": "https://www.sailpoint.com",
    "jwks_uri": "https://tenant.api.identitynow.com/oauth/jwks"
}
7

This one is interresting for centralized storage and management of credentials and can be used in Workflows Enhancement: HTTP Request Action with Parameter Storage Credentials - Announcements / Product News - SailPoint Developer Community

This support only the centralization of credential .

What you can do also is at the begining of your workflow just after the trigger add define variable and defining there all parameters needed and then use those in others part. So if you have to update anything it should be updated at only this define variable level.