You are viewing limited content. For full access, please sign in.

Question

Question

API call behavior difference between Cloud and On Prem

asked on May 7 Show version history

Solved:

In on prem you seem to need an escape character ahead of any tokens.  The following seems to work

 

 

I have a few API calls/Web Service requests that work in our Cloud system.  I am trying to re-create them in a on prem system and running into errors.  I am wondering what the difference is between on prem workflow and Cloud as I can't seem to figure it out.  Its a larger process but the first few steps are enough to hit the issues.

1. Hit Office 365 Login to get a bearer token

2. Find a user in our Office 365 environment.

 

#1 works fine in both environments.  I make the post and get back a bearer token.

For #2 here is the Cloud call:

I am passing in the authtoken as well as the email address from the process and I get success.  It finds the user and returns the various attributes.

In on prem it looks like this:

Here is the header info as well:

I get a valid token and I can authenticate.

 

However when I run the workflow I get the following error:

{"error":{"code":"BadRequest","message":"Resource not found for the segment 'users%'.","innerError":{"date":"2025-05-07T16:44:39","request-id":"9f8b123e-8803-4021-ae0e-9e012c578f96","client-request-id":"9f8b123e-8803-4021-ae0e-9e012c578f96"}}}

 

I have tried hard coding the email, using various quotes, etc and I dont know why on prem workflow would error out while Cloud would work using the same exact API call.

 

Thanks,

Chris

 

1 0

Replies

replied on May 7

Hi Chris. "users//%(useremail)" should work. '/' is a special character in workflow token string. When a single '/' is followed by a '%', the ‘%’ will become a regular character instead of the start of a token.

0 0
replied two days ago

Actually I did try that before and still an issue.  However, its a backslash that seems to be the escape character.  Cloud seems to recognize it, on prem seems to need it.

 

0 0
replied two days ago Show version history

Actually, the forward slash is the escape character, not backslash, and it only escape the '/' or '%' following it. In this case, "users//%(useremail)" will finally become "users/xxx@xxx.com" while "users/\%(useremail)" will become "users/\xxx@xxx.com". They seem to be both accepted as valid url segments. Both of them work for me.

Use "users//%(useremail)":

Use "users/\%(useremail)":

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.