Additional Settings

Additional Settings has options for provisioning and common configuration for HTTP errors.

The Web Services SaaS connector supports the following provisioning features.


This is the companion discussion topic for the documentation at https://documentation.sailpoint.com/connectors/saas/web_services/help/saas_connectivity/web_services/additional_settings.html

The documentation in the connector settings in ISC itself links to https://documentation.sailpoint.com/connectors/saas/web_services/help/SaaS_Connectivity/Web_Services/Additional_Settings.html which does not resolve, it should come to this page.

Same with pretty much every other link in the connector…
There seems to have been a case conversion to lowercase which is not reflected in the connector itself.

Hi Remi! Thank you for your input. We’ve created a Jira issue to track the effort and we’ll update the comment thread when it’s been addressed: CONDOCS-4068

Hi Remi, I’m seeing all of the UI links as updated to all lowercase. I’ve closed out the Jira for this issue as all the links are now working.

It would be nice to see a couple of actual examples of what is required here


For example:

  • The Web Services source returns the HTTP status code: 200, but the response payload contains an error. Without the manually entered HTTP error, the source won’t know that it must fail the request.
  • During OAuth token generation, the source needs to regenerate a token to replace an invalid or expired token. You can configure an HTTP error code or message to specify an invalid/expiry token error in this event. The source regenerates and saves the token for OAuth2 authentication, then retries the operation with the newly generated access token.

e.g. do we need to put 200 with the error message returned or just the error message. I have found posts that imply only 1 or the other needed and others stating both.

Also some information about how Sailpoint would display\handle this e.g. would we see it has a failure or would it still show as a success? If it retries and fails\returns the error again will it retry or will it know not to? Will it beable to read the message and know not to retry if it is a format error.

Hi @chris_littleboy! Thank you for your input. We’ve created a Jira issue to track the effort and we’ll update the comment thread when it’s been addressed: CONDOCS-7279