WebSerivce Context Url Issue

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Share all details about your problem, including any error messages you may have received.

I’m working with the SailPoint Web Services connector and facing an issue when handling removal of multi valued entitlements using a $ref with query parameters.

Context URL : DELETE /users($getObject.nativeIdentity$)/entitlements/$ref?$id=https://api/.../rights($plan.rights$)

So the URL contains:

  • $ref
  • $id=`query parameter
  • nested URL with parentheses
  • special characters ($, (), etc.)

When executing the remove entitlements operation the $plan.entitlements$ not resolved properly , as when logging we see a malformed URLs like:

users(123455666)/entitlements/$refplan.rights$)

Question :
Is there any supported way in the Web Services connector Context URL to properly escape or handle special characters when using a $ref?$id= pattern or is it required to construct the full endpoint dynamically in a BeforeOperationRule (for example, building a separate URL per entitlement before each operation execution) an how to do that when it’s multi-valued entitlements ?

Thanks,

Best regards

2

Hello Alshahim,

This looks like the Web Services connector is treating the literal OData $ref / $id values as unresolved SailPoint $...$ placeholders. When a placeholder in the context URL doesn’t match anything in the provisioning plan, response, or application, the connector strips it, which is why the URL ends up as:

users(123455666)/entitlements/$refplan.rights$)

Start by encoding only the literal OData $ values and leaving the SailPoint tokens untouched:

DELETE /users($getObject.nativeIdentity$)/entitlements/%24ref?%24id=https://api/.../rights($plan.rights$)

So:

  • $ref → %24ref

  • $id → %24id

Keep these as connector tokens:

  • $getObject.nativeIdentity$

  • $plan.rights$

Also plz check your Application XML for this setting:

<entry key="skipEncodingDecodingUrl" value="true"/>

SailPoint documents this for Context URLs that contain special characters like parentheses, brackets, or encoded values, which covers your case. Worth adding it alongside the encoding fix. Operation-Specific Configuration Parameters

If the URL still doesn’t resolve correctly, the reliable fallback is a Web Services Before Operation rule where you build the full DELETE URL manually. That’s also the right approach if the plan has multiple removed entitlement values and the target API requires one DELETE per value. This thread has a confirmed working pattern using WebServicesClient for that scenario.

One more thing worth checking that you mentioned both $plan.rights$ and $plan.entitlements$. Make sure the token name matches the actual entitlement attribute name in the provisioning plan, otherwise it won’t resolve regardless of the encoding fix.

3

hi @alshahim04

The connector doesn’t reliably handle special characters or nested query parameters ($ref, $id=, $, (), encoded URLs) in the Context URL. Token resolution (like $plan.rights$) happens before proper URL encoding, so complex $ref?$id= patterns often end up malformed—exactly what you’re seeing in the logs.

There’s no supported way to escape this directly in the Context URL.

I would try:
Using a BeforeOperationRule to dynamically build the full, encoded endpoint. For multi‑valued entitlements, loop through each value and execute one DELETE call per entitlement with a properly encoded $ref?$id= URL.

Not ideal, but today it’s the only stable solution for this pattern in IIQ.