400 Bad Request error using POSTMAN
Thursday, July 2, 2020 at 01:54pmCanada 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
Thursday, July 2, 2020 at 03:19pmHi 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
Reply to: 400 Bad Request error using POSTMAN
Friday, July 3, 2020 at 10:21amI 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
Friday, July 3, 2020 at 12:43pmHi 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
Reply to: 400 Bad Request error using POSTMAN
Friday, July 3, 2020 at 03:07pmDuo, 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
Friday, July 3, 2020 at 03:43pmHi Mike,
I can confirm, see the screenshot:
Duo
Reply to: 400 Bad Request error using POSTMAN
Friday, July 3, 2020 at 05:00pmLooking 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
Monday, July 6, 2020 at 08:44amThe 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
Reply to: 400 Bad Request error using POSTMAN
Friday, June 23, 2023 at 03:54pmI 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.