Response code 400 or 403 for POST Restful APIs - web-services

Question

I am designing a POST Restful API, where I have a situation that I have to authorize a user based upon one of the element provided in the request body.
For eg.
{
division : "1",
name : "MyName",
address:{
no : 123,
street : "abc",
pincode : 222111
}
....
}
So the user making POST request should be authorized to work on division 1. I cannot authorize the user without getting request body.
Also to validate some of the attributes I have to make heavy DB calls in the DB , for eg, to check the above address has a valid value of pincode.
So My question is how should I return the error codes to the user -
[EDIT]If division is not valid(something that doesnt exist in system) in the request - 400 or 403 ?
If division is provided, but user is not authorized and pincode is invalid - 400 for invalid pincode or 403 ?
What should be the error code if pincode is mandatory attribute and is not provided in the request. Should I first check 403 and then 400 or reverse ?
Basically which error code to proceed the other ?
Also is it okay to do something like :
400 – request is bad, syntactically (division/pincode or other mandatory values not provided)
403 – authorize user
400 – request is bad, data specific validation (heavier operation, requiring to hit DB)
[EDIT] we preferred not to use 422 error code

Answer 1

When in doubt, just take a look at the RFC
400 Bad Request
The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.
403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated. If
the request method was not HEAD and the server wishes to make public
why the request has not been fulfilled, it SHOULD describe the reason
for the refusal in the entity. If the server does not wish to make
this information available to the client, the status code 404 (Not
Found) can be used instead.
If division is not provided in the request - 400 or 403?
I don't think either apply. The syntax -although it's missing some data- is not malformed.
Also 403 seems incorrect because of reasons mentioned above in the quote: authorization will not help etc.
How about 422 Unprocessable Entity?
422 Unprocessable Entity (WebDAV; RFC 4918)
The request was well-formed but was unable to be followed due to
semantic errors.
That is what I usually use in situations like this.
If division is provided, but user is not authorized and pincode is invalid - 400 for invalid pincode or 403?
Again, I don't think either 400 or 403 make a good case here. Specifically for this situation, 401 exists
401 Unauthorized
Similar to 403 Forbidden, but specifically for use when authentication
is required and has failed or has not yet been provided. The response
must include a WWW-Authenticate header field containing a challenge
applicable to the requested resource. See Basic access authentication
and Digest access authentication.

Answer 2

I think you're in the right track. Assuming that every request is being authenticated via (http authorization header)
Returning 400, on missing data is OK, and furthermore you can add error response body explaining what was the reason for the Client request not being accepted (in this case the missing division).
Returning 403, is OK if the client making the request is not authorized to interact with the resource (in this case the division).
You must validate first if the Client is authorized to interact with the resource, so 403 must be sent first, and if a required field is missing you can treat it as a 400 (with a proper explanation).
In case the Client is not authenticated, the correct response should be 401, but like I said before, 1) and 2) in my response are assuming that the Clients are authenticated against the server.
Hope it helps,
Jose Luis