HTTPError: 422 Client Error: Unprocessable Content for url

Libraries RequestsLibrary
1

Anyone familiar with the 422 error below? This POST request is working via Postman.

422
4221337Ă—735 102 KB

2

Hi Gian,

HTTP 422 UNPROCESSABLE ENTITY just means you sent a valid request to the server but the server was not able to process it for some reason.

You mentioned it worked for you in Postman, did you try posting it several times in Postman or just once? the reason I ask is I noticed you create a list with rewards and a value, does this reward number get consumed on the server, i.e. once it’s been used once (by postman) it’s no longer available to use?

Also can you show the request and response from postman? or can you compare the request/response body from postman to what RequestsLibrary requested and got as a response, the smallest differences can cause unexpected responses e.g. %3D instead of =

Dave.

3

Hi Dave,

Thanks for your response. the list that I’ve created (rewards) is for the basic authentication.

Here’s the request response from postman:
{
“providerId” : “2C8X87BYLORZXRVC”,
“userId” : “a12cddad8b515005dfa72a9875c76ad5”,
“statementAccountNumber” : “LS123”,
“payeeId” : “LSL50MYYMHSTAHSN”,
“statementDate” : “2022-10-30”,
“statementDueDate” : “2022-10-30”,
“subtotal”: “250.95”,
“discount” : “50.15”,
“total”: “200.80”
}

Response:
“data”: {
“providerId”: “2C8X87BYLORZXRVC”,
“userId”: “a12cddad8b515005dfa72a9875c76ad5”,
“userStatementAccountNumber”: “JM123”,
“payeeId”: “LSL50MYYMHSTAHSN”,
“statementDate”: “2022-10-30T00:00:00.000000+11:00”,
“statementDueDate”: “2022-10-30T00:00:00.000000+11:00”,
“statementProcessingDueDate”: “2022-10-29T00:00:00.000000+11:00”,
“subtotal”: “250.95”,
“discount”: “50.15”,
“total”: “200.80”,
“status”: “new”,
“active”: true,
“createdAt”: “2022-11-14T12:49:18.000000+11:00”,
“updatedAt”: “2022-11-14T12:49:18.000000+11:00”
}
}

4

Hi Gian,

  1. You only provided the request and response bodies not the headers, HTTP headers can be really important especially with API calls

  2. in Postman your dates are YYYY-MM-DD format, in your robot test they are DD/MM/YYYY does the server accept both formats interchangeably? (You may need to check with the Devs if this is ok) I’d suggest at least initially till you get it working keep all the data in the same format as you used in Postman. Same applied for Total where you used a float (200.80) in postman and an int (100) in robot (you could try 100.00).

GMT+11? are you in NSW/VIC? (I’m in QLD)

Dave.

1 Like
5
  1. Here are the headers:
  1. Would the date format matter in the response? Tried updating the total, still now working.

I’m from Manila, just working on a project there in Australia.

6

Hi Gian,

No only in the request, I wouldn’t worry about the response at all till you get it working and need to test the contents of the response.

The reason it’s not working will be something to do with how you constructed the request, it could be the request body or the request headers, but it must be something different in the request.

You’ll just need to compare the request headers and body from postman and RequestsLibrary making adjustments to make them the same till it works. Things to check:

  • Authorization: check that RequestsLibrary generated the exact same Base64 encoded value you have there in psotman
  • Cookies: check that you have all the same cookies, if your robot log is missing any, add them. (I couldn’t see that you added cookies to the session?)
  • Other Headers: I couldn’t see that you headers to you session, headers such as content-type, accept, accept-encoding are often required, you may need to add them
  • Request Body: Save the request body from postman and RequestsLibrary to text files (one for each) and then use a diff tool to compare them, anything thats different on the RequestsLibrary request body, make it the same as postman’s

Failing all that, if your request headers and bodies are identical, see if the dev’s can give you access to the application logs/web server logs, something in there might give you a clue to what the problem is.

Hope that helps,

Dave.

7

Hey Dave,

You’re right it’s the date format from request is the culprit.
Thank you so much.

1 Like
8

Hi Gian,

Thats great you found it, Keep this thread bookmarked as next time you have an issue like this it’ll provide a good troubleshooting guide for you.

Dave.

1 Like