We’ve run into an issue with one of our connectors in which our oauth token request API calls are getting a 400 error.
After talking to dev support from the application, I was informed it’s because the request is getting mangled by URL encoding before hitting the endpoint. Is there a way to not have this applied to the outgoing request?
Our Zendesk integration cannot aggregate accounts anymore because the account filter field is also getting URL encoded since the 8th of August role[]=admin&role[]=agent ends up as role%5B%5D%3Dadmin%26role%5B%5D%3Dagent - you can see the outgoing call from cgg.log
I’ve opened a support ticket as well but no luck with that yet (albeit it’s been just 2 days since I reported it)
Is your integration using a Sailpoint provided connector as well or is it web services?
Good news though I actually just solved this one yesterday, you can add this filterString:
“!((role == "agent" || role == "admin"))”
to your connector and it will still filter the end-user accounts out.
Bad news is that since it’s being filtered on the IdentityNow side versus the Zendesk side it takes MUCH longer to filter.
Thank you for the suggestion - seems to work, aggregation’s been running for 14 minutes now. Which is considerable longer than it should take, like you suggested. @colin_mckibben is there any way we could… highlight this issue? It seems to me that this might have a pretty big negative impact
I’d like to follow up that this can also be fixed by migrating the Zendesk filtering to the query parameters versus wherever IdentityNow puts it now. Unfortunately since we can’t edit the calls that OOB connectors use we can’t implement this fix ourselves.
Hi @colin_mckibben , I am also Facing same issue with Ventiv Application, when I set Skipencoding variable as true, then I am unable to aggregate the Data, its only give Success result and not giving any Account Details, Even the same Thing working fine in Sailpoint IIQ. Raised a ticket but no inputs yet .