Webservice Connector calling the endpoint more than it supposed to

We are integrating IIQ with a target application via an API. We are using OOTB Sailpoint Webservices connector to do the integration. The API structure is in such a way that if a user selects multiple roles, all of them are created as individual access requests. Of these, only the first request that is getting approved need to call the “Create Account” API and the rest all requests should call the “Add Entitlement” API. We are able to achieve this. But we have observed that the connector is calling the “Add Entitlement” API a couple more times than the number of groups requested.

I.e If User A requests access to 4 roles and user B requests access to 3 roles, the “Add Entitlement” should be triggered 5 times since two of them will be calling the “Create Account” API. Instead, in the logs, when we are printing the request end points in the before operation rule, we are seeing that the “Add entitlement” is being called 10 times. In few of them, the body is getting passed as expected, and in some of others, the body is missing a specific attribute. Please find below two types of requestEndPoints that we are seeing in the logs:

Request Endpoint in add group before operation is:EndPoint [_afterRule=Test Add Ent After Rule, _beforeRule=Rule_AddEnt_BeforeOperation, _contextUrl=, _fullUrl=, _httpMethodType=POST, _operationType=Add Entitlement, _rootPath=user, _uniqueNameForEndPoint=Add Groups, paginationSteps=null, pagingInitialOffset=0, pagingSize=50, _resMappingObj={id=id}, _header={authorizationToken=, Accept=application/json, Content-Type=application/json}, _body={jsonBody={
“environment”: “Dev”,
“action”: “Add Group”,
“user_name”: “MCH_TMCHUserOne”,
“site_name”: “MCH-Dev”,
“group”: “TBLGRP_MCH_FACULTY_TXAIM_HTN”
}, bodyFormat=raw}, _responseCode=[2**], _sequenceNumberForEndpoint=9, xpathNamespaces={}, possibleHttpErrors={}]

Other type of request end point that is visible in the logs:
2025-06-05T13:29:57,723 ERROR https-jsse-nio-8443-exec-8 connector.webservices.v2.RequestOrchestratorV2:166 - Request Endpoint in add group before operation is:EndPoint [_afterRule=Test MCH Add Ent After Rule, _beforeRule=Rule_AddEnt_BeforeOperation, _contextUrl=, _fullUrl= _httpMethodType=POST, _operationType=Add Entitlement, _rootPath=user, _uniqueNameForEndPoint=Add Groups, paginationSteps=null, pagingInitialOffset=0, pagingSize=50, _resMappingObj={id=id}, _header={authorizationToken=, Accept=application/json, Content-Type=application/json}, _body={jsonBody={“environment”:“Dev”,“action”:“Add Group”,“user_name”:“MCH_TMCHUserOne”,“site_name”:“MCH-Dev”}, bodyFormat=raw}, _responseCode=[2**], _sequenceNumberForEndpoint=9, xpathNamespaces={}, possibleHttpErrors={}]

Plan inside before provisioning rule:

2

Also, the before provisioning rule and after provisioning rules are getting triggered equal to the number of times that the users have requested the roles, which is as expected.

We are not triggering the webservice connector any where in the workflow. We are not sure why this extra trigger of the end point is happening. Any thoughts or ideas on why this might happen are really appreciated.

Hi @mbommakanti3298

I’m assuming the extra “Add Entitlement” API calls are happening because some provisioning instructions are missing required attributes like the group name. When these incomplete entries are processed, the connector treats them as separate calls, leading to more API hits than expected.

To fix this, you can add a check in the beforeOperation rule to skip calls where essential attributes are missing. Also, review the provisioning plan to ensure it doesn’t include duplicate or incomplete entitlements. This should help prevent the unnecessary API calls.

Hello ,

Thanks for your reply. I was also thinking on same lines to add a check in before operation rule, but is there any standard way to skip the api call in the before operation rule if the group is missing? For time being, I have converted the request to a google API that returns 200 everytime as a GET call, and making sure no data like body or header is sent. But, wanted to know if there is any option to just skip it

Thanks,
Maneesh.B

Yes, you’re on the right track. In the beforeOperation rule, you can indeed program logic to skip provisioning when key attributes (like group name) are missing. There’s no built-in “skip” flag, but you can achieve this by returning null from the rule when your condition isn’t met. This effectively stops the provisioning instruction from going through.

Your workaround with the dummy API is clever for testing, but returning null or modifying the plan directly in the rule is a cleaner long-term approach.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.