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.