mikcanf

400 Bad Request error using POSTMAN

0 votes

Canada SBX = sandbox.e-signlive.ca

API = /apitoken/clientApp/accessToken

https://sandbox.e-signlive.ca/apitoken/clientApp/accessToken

header fields Accept + Content-Type  ( both set to application/json )

Body below  with "?" instead of actual values

{

  "clientId""???????????????????",

  "secret""?????????????????????????????????????????????????????",

  "type""OWNER"

}

 


Reply to: 400 Bad Request error using POSTMAN

0 votes

Hi Mike,

 

With some quick tests, I found below error codes and the underlying cause of each error:
403 - wrong client ID + Secret pair

400 - if you choice type as "OWNER" and provide a wrong "email" (if "OWNER", no need to put email though)

401 - if you choice type as "SENDER" and provide a wrong "email"

However from the details listed above, can't really find something obvious , and I can't reproduce the 400 error with the same payload. Could you have a quick try and recreate a new pair? Or do you happen to have any sandbox account under other environment and try from there?

 

Duo

 

Duo Liang OneSpan Evangelism and Partner Integrations Developer


Reply to: 400 Bad Request error using POSTMAN

0 votes

I went back to try a new clientId and secret via US sandbox. POSTMAN allows you to indicate "Auth" TYPE but I'm not sure which I s/b using, perhaps Bearer Token, or OAuth 2.0, or No Auth.  I tried various options but still got 400 error. I notice POSTMAN has it's own Token in it's own header field

08:01:31.984 (Vancouver Time PST) 03Jul2020 

POST https://sandbox.esignlive.com/apitoken/clientApp/accessToken
400
344 ms
Network
Request Headers
Accept: application/json
Content-Type: application/json
Postman-Token: 8d2211fe-9b1a-4048-8ff0-0139a0944975
Request Body
{
  "clientId": "173??????????????88120d007e",
  "secret": "6879??????????????????????????????????????????????????????????????????8480",
  "type": "OWNER"
}
Response Headers
Server: nginx
Date: Fri, 03 Jul 2020 15:01:32 GMT
Content-Type: text/html
Content-Length: 150
Connection: close
Allow: GET, POST, HEAD, PUT, PATCH, DELETE
Response Body
<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>


Reply to: 400 Bad Request error using POSTMAN

0 votes

Hi Mike,

 

(1)For this API - retrieve temporary access token by client ID + Secret, you don't need to specify Authorization in request header, information in request body is enough

(2)"POSTMAN-TOKEN" should be acceptable, my call can pass with this header carried

(3)The 400 error you hit is in type of text/html, I am surprised that it didn't follow the accept header. So I am wondering are you connecting through a proxy / web debugger and could this error didn't come from OSS system but a middleware?

 

Duo

 

Duo Liang OneSpan Evangelism and Partner Integrations Developer


Reply to: 400 Bad Request error using POSTMAN

0 votes

Duo, can you confirm your results are using POSTMAN with auth = "No Auth"  (and clientId, secret in Body/Payload).  Do you get a new token in the response body?


Reply to: 400 Bad Request error using POSTMAN

0 votes

Hi Mike,

 

I can confirm, see the screenshot:

7-3-1

 

Duo

Duo Liang OneSpan Evangelism and Partner Integrations Developer


Reply to: 400 Bad Request error using POSTMAN

0 votes

Looking at what you have, I see a green dot beside Params.   As this is a POST I have no Params, what/why do you seem to have Params?  Mike


Reply to: 400 Bad Request error using POSTMAN

0 votes

The parameter was toggled off in my example (don't know why it was there), and it's the same result if I completely removed it.

 

Duo

Duo Liang OneSpan Evangelism and Partner Integrations Developer


Reply to: 400 Bad Request error using POSTMAN

1 votes

I had this same issue. For anyone still running into this, the problem for me was the type parameter being set to "Owner" instead of "OWNER".

 

Here is an example cURL request that should work if you use an appropriate client ID and secret.

 

curl -d '{"clientId":"yourClientId","secret":"yourSecret","type":"OWNER"}' -H "Content-Type: application/json" https://sandbox.esignlive.com/apitoken/clientApp/accessToken -i

 

The original post shows "OWNER" so I'm not sure if it would resolve their issue. A potential resolution for the issue if you are using "OWNER" and still getting this error could be that you're using the wrong sandbox URL. For example, "https://sandbox.esignlive.com" vs "https://sandbox.e-signlive.com". The correct one is the one that displays when you sign into the sandbox account in the browser.

 

 


Hello! Looks like you're enjoying the discussion, but haven't signed up for an account.

When you create an account, we remember exactly what you've read, so you always come right back where you left off